An HTML form, a php file and a text file.
The form has one input box, it sends the inputted string to the PHP file using GET or POST. The PHP file writes the string to the text file using fopen 'a', fwrite and fclose and does no sanitization at all.
The text file is set to permission 777 and is in the same folder as the other files.
Are there any security concerns here? Is it possible for someone to send something using the form that will do any damage? If yes, what?
What about if the txt file is set to 666?
Never execute
Depending on what the use of this file, there shouldn't be much risk involved. Just make sure the file is never executed.
This means, never eval() the content of this file, or change it into a .php or any other executable file.
However, if the content is ever to be written on a page, or viewable by the user, you will have security risks doing this.
I typically use 3 ways to improve security writing to files. 1) Move file out of webroot and into some folder with restricted access like cgi-bin. The path to the file and any passwords should also be saved outside of the webroot. 2) Then you include the sensitive data by including it on your page. So if PHP parser fails people only see a variable name and no details. 3) If your are doing a post or get to the file which is doing the writing you can also check the values carefully and stip out characters, script, etc. that could cause problems.
From a web-security point of view, I do not see any problems, as long as the path of the text file is hardcoded or secured in any other way. You haven't said anything though about what happens if the file is missing or read-only (yes, it can happen, for example if the file system is mounted read-only by the administrator).
That being said, this use case is also completely useless, as the text file serves only as a data sink. A data sink that is never read from is useless. The problems may arise when you want to read from the file.
Related
I want to be able to upload a CSV file to a Webpage, and then have PHP store that information to a array and do stuff with it WITHOUT saving the CSV file to the server. How is that possible?
Looking into it, there's the normal GET and POST, which upload the file to the server. There's also PUT, but it looks like it just saves on top of an already existing file on the server.
And from the looks of the process to extract data from a CSV, PHP needs to know the location of the file.
Is it possible to just have the PHP work with the CSV file without saving it to the server somewhere? That way I don't have to worry about security issues with uploading files to a server. I don't need to hold onto the CSV data afterwords, just manipulate it in the current session.
When a file is uploaded to the server from a form, the file is stored temporarily ( $_FILES['someinputname']['tmp_name'] ) . No one says you have to do anything with this file before you can use it. You can read directly from the temporary path and forget about it. This, of course, does not leave you free from harm. Validating the file type is what you expect and not of malicious nature MUST be done before doing anything with a file you don't trust.
No lazy way around being safe.
CSV is just a text file. So you can read the file using javascript from client side and get the text from the file.
Javascript - read local text file
And then send the text to server and then work with it.
I'm trying to write a script that allows the upload of php files for parsing. Most of the tutorials and security information I can find on Google and here assume you're only allowing the upload of images (so use getimagesize, etc).
How do I confirm a file uploaded is really a PHP file without relying on the headers? Also -- I don't plan on storing the file in any way, I just want to grab the contents, parse it, and dump the info -- is there a very secure way to just grab the contents without actually saving the file to temp? If I do have to save it to temp, if I just grab the contents and then quickly delete it, am I still facing security threats and, if so, how do I dampen them?
What sort of sanitization do I need to do to PHP file contents to prevent misuse of the system? Basically, is there a way for a malicious user to 'inject' running code if I'm just parsing the contents as text?
If you just want to get the content of the file, use file_get_contents(), you get the contents of the file as a string.
http://us1.php.net/manual/en/function.file-get-contents.php
And then just use regular expression or w/e you use to parse with strings.
I have used this step echo $_FILES["fileField"]["tmp_name"]; but result like this.
C:\xampp\tmp\phpA9EE.tmp
How can i get exact file path?
An uploaded file does not have a "full path", other than temporary location where PHP has stored it during the upload process.
For the security of users, the browser sends only a filename of where it came from on the remote computer; for your security, you should not blindly use this (security rule of thumb: anything sent by the user is suspect and could be used to attack your system). You might want to filter it through a whitelist (e.g. remove anything other than letters and numbers) and use it as a "friendly" upload name, or you might want to ignore it completely. The browser also sends a file type (e.g. image/jpeg); again, this should not be trusted - the only way to know the type of a file is to use a command that looks at the content and validates it.
As far as PHP is concerned, what has been uploaded is a chunk of binary data; it saves this to a randomly named file, which is the path you have echoed there. The PHP manual has an introduction to how this works.
With that path you can do one of two things:
validate with is_uploaded_file(), and read the data with file_get_contents() or similar
use move_uploaded_file() to put it in a permanent location of your choice
I have a system set up where, when the user registers, it creates a custom directory for them and then inside that directory it creates a file called index.html. I would like to write an entire HTML page of 100+ lines to that file. I was using fopen() fwrite($filepath, 'content');, but there are escape characters like '' and "" that mess up the PHP function.
Is there a better way to write large content to these files, or should I just have the file saved somewhere on my webserver and then just transfer it to each new registered user?
If you already have the file on disk, and it will not change for each user, then you should copy the file.
It is a waste of resources to read and then write the file with PHP..
PHP Manual - copy
Have a look at htmlentities($var);
http://php.net/manual/en/function.htmlentities.php
Well that means that where you say 'content' you have a hard coded html file in your script itself. It would be easier to just save a standard html file somewhere on the webserver and to something like this:
file_put_contents('/path/to/user/file', file_get_contents('/path/to/standard/index.html'));
Easier to maintain (no html in your code, but just in a testable html file) and no worries about escaping characters. Easy does it :)
Edit
Someone smarter than me proposed to just copy the file. Which is ofcourse a lot more sensible to do than reading and writing contents...
I want to allow registered users of a website (PHP) to upload files (documents), which are going to be publicly available for download.
In this context, is the fact that I keep the file's original name a vulnerability ?
If it is one, I would like to know why, and how to get rid of it.
While this is an old question, it's surprisingly high on the list of search results when looking for 'security file names', so I'd like to expand on the existing answers:
Yes, it's almost surely a vulnerability.
There are several possible problems you might encounter if you try to store a file using its original filename:
the filename could be a reserved or special file name. What happens if a user uploads a file called .htaccess that tells the webserver to parse all .gif files as PHP, then uploads a .gif file with a GIF comment of <?php /* ... */ ?>?
the filename could contain ../. What happens if a user uploads a file with the 'name' ../../../../../etc/cron.d/foo? (This particular example should be caught by system permissions, but do you know all locations that your system reads configuration files from?)
if the user the web server runs as (let's call it www-data) is misconfigured and has a shell, how about ../../../../../home/www-data/.ssh/authorized_keys? (Again, this particular example should be guarded against by SSH itself (and possibly the folder not existing), since the authorized_keys file needs very particular file permissions; but if your system is set up to give restrictive file permissions by default (tricky!), then that won't be the problem.)
the filename could contain the x00 byte, or control characters. System programs may not respond to these as expected - e.g. a simple ls -al | cat (not that I know why you'd want to execute that, but a more complex script might contain a sequence that ultimately boils down to this) might execute commands.
the filename could end in .php and be executed once someone tries to download the file. (Don't try blacklisting extensions.)
The way to handle this is to roll the filenames yourself (e.g. md5() on the file contents or the original filename). If you absolutely must allow the original filename to best of your ability, whitelist the file extension, mime-type check the file, and whitelist what characters can be used in the filename.
Alternatively, you can roll the filename yourself when you store the file and for use in the URL that people use to download the file (although if this is a file-serving script, you should avoid letting people specify filenames here, anyway, so no one downloads your ../../../../../etc/passwd or other files of interest), but keep the original filename stored in the database for display somewhere. In this case, you only have SQL injection and XSS to worry about, which is ground that the other answers have already covered.
That depends where you store the filename. If you store the name in a database, in strictly typed variable, then HTML encode before you display it on a web page, there won't be any issues.
The name of the files could reveal potentially sensitive information. Some companies/people use different naming conventions for documents, so you might end up with :
Author name ( court-order-john.smith.doc )
Company name ( sensitive-information-enterprisename.doc )
File creation date ( letter.2012-03-29.pdf )
I think you get the point, you can probably think of some other information people use in their filenames.
Depending on what your site is about this could become an issue (consider if wikileaks published leaked documents that had the original source somewhere inside the filename).
If you decide to hide the filename, you must consider the problem of somebody submitting an executable as a document, and how you make sure people know what they are downloading.