How would i generate a file of all of the following types:
.js
.css
.html
I would also need to be able to read the file and overwrite it somehow.
Is this possible in anyway?
All of these files are just text files with different file extensions so if I could maybe make a text file and change the file extension?
As all of those are simply text files, all you need to do is create/open the file with the desired name and write text into them.
Check out some of the PHP file IO commands:
fopen()
fread()
fwrite()
fclose()
PHP is usually (often?) used as a templating language, where HTML "files" are generated "on-the-fly" and output directly to the browser.
I could be wrong, but it sounds like you are talking about generating files and saving them to disk to be served statically to the browser later. If that's the case, you're right - they are just text-files - so writing them as text-files with the relevant file extension should work.
This seems like it would be logistically complicated to manage as a site scales though. Also - if you're creating an web-interface to edit files on the server, while some CMS-es do this (Wordpress for example), it does come with a lot of security issues (allowing PHP unrestricted write access to your server is rarely a good move).
Related
I would like to keep all config options for a webapp in one file. (pathes, passwords, options which are read by php, sass (during compilation), maybe grunt,..)
I like the JSON format since its very clear and almost anything can parse json. But by default .json files can be downloaded.
Can I safely prevent that by giving the file a .json.php extension?
What are the drawbacks? Better Approaches?
To prevent the file being downloaded, generally the way to go is to store it in a directory that is not served by the web server. I don't know what setup you're in, but assuming an Apache setup, if for example your .php files are served from a directory /home/user/htdocs, you could create a directory /home/user/config, ensure that it is readable by the webserver, and store the .json files there.
Another approach, again assuming Apache, would be to create an .htaccess file containing the following (inspired by this answer):
RedirectMatch 404 \.json$
This would not only prevent downloading any and all .json files in the directory, but hide their very existence.
It might just be possible to do it the way you suggested, by storing the file with a .json.php extension, although this would not be a recommended approach. For this to work, the file has to be valid PHP but it must obviously be valid JSON as well and we are hampered somewhat by the fact that JSON does not allow comments. Something like the following would stop the PHP interpreter soon after the start of the file, before spilling your secrets:
{
"<?php exit('Access denied'); ?>": null,
"password": "secret"
}
I've noticed that the .html and .php file extensions can be interchanged without apparent effect. Why would I want to use one file extension over the other?
A page ending in .php can include both HTML and/or PHP code (also javascript, css, etc inside their appropriate tags). Note that it is perfectly fine for a page without any PHP code to still have the .php extension.
However, if your page does include PHP code, the filename extension must be .php. Try it - on most web servers this won't work:
FILENAME: test.html
<?php
echo 'Hello there';
The above page will be blank. But if you rename it to test.php, you will see the hello message.
Filename extensions are also an indicator to yourself, or other programmers, as to what type of code the file contains. It is clear at a glance that a file ending in .HTML does not contain any PHP code (especially since any PHP code contained within won't work unless the webserver config is specifically modified to allow it).
One Final Note: these days it is pleasing to have web pages that do not end with an extension at all. Of course, you cannot leave off the extension of a .php or .html page... but you can hide the extension (including the period), making the page look like it was served by Flask or React or etc. You do this via a .htaccess file (yes, exactly like that, dot and all) that sits in the root folder of your website (same folder as the index.php or index.html). See:
https://code-boxx.com/hide-php-extension-url-htaccess/
https://tecadmin.net/remove-file-extension-from-url-using-htaccess/
Here is an interesting tool to help build .htaccess files
Use .html as a default.
If your page is running phpscripts then use .php
So, if you are communicating with server, use .php
.html and .php are file extensions but the more important question is how they are run.
A .php file can run server side script and take in mysql queries and open a connection etc...all of which are server-side functions.
Html is static and only displays static content but that has now changed with HTML 5.I suggest you do a simple search to learn more about php and html and their fundamental differences.
Files are handled depending on config and context. Shebangs, default programs, Apache Handler's, HTTP Headers, etc. describe handling files in various scenarios.
Executing Files In Terminal
The .php extension indicates that it is a PHP script, but the extension isn't necessary.
example-file.php
<?php
echo 'Hello World';
The script can be executed with PHP, which is clear because of the extension:
> php example-file.php
example2-file
#!/usr/bin/env php
<?php
echo 'Hello World';
With a shebang on the first line the OS can try to use the correct interpreter for the user so that the command is simplified to:
> ./example2-file
Some of the implementation details are hidden from the user by removing the file extension.
Packages often retain the extension on the source, but drop the extension during installation.
Default Programs
An extension can indicate to an OS which program to use to open a file.
Files ending in .php on my computer open in an IDE for editing whereas .html files open in a browser.
Servers and Headers
Web servers can send a file with any extension and content-type since many files don't actually exist, but are dynamically generated.
PHP web servers will serve .php files with the text/html content-type because the PHP is interpreted into text. Servers configured to return the raw PHP file as another content-type, i.e. servers not configured for PHP, will cause the web browser to download the source file rather than view the rendered file as HTML.
Since the resulting file after execution is HTML and web servers can dictate the extension, some developers decide to use .html in the URL and have them correlate to .php files to execute and return. Or the URL can not use an extension at all.
Using distinct extensions has the same purpose in PHP as it does in any language -- it makes it easier to determine the type of file you're using.
You may want to ease your web server's burden by having .html files not ran through the PHP processor, or you may want to have your PHP files not labeled .php to help hide what technology you're using server-side.
If i had a text file on my web server, which contains full PHP code, all properly formatted, could i use PHP fopen to read the text file and echo the output of the PHP to the browser. Ie. Run PHP code that is held in a text file rather than hard coded?
Thanks
It's perfectly possible to do this (it's just another file after all), although I'd be tempted to directly include it rather that messing around with fopen/eval, etc. (N.B.: The file would of course have to be "fully formed" and begin with "<?php", etc. for the include to work.)
However, I'd be very wary of naming the file with a .txt extension as this will mean that it'll be possible to browse the contents of this file directly from the browser if it exists in the public HTTP docs area. As such, why not simply write the data into a .php file - this will be no more difficult than a .txt file and offers the advantage that it always be parsed by the web server if someone attempts to access it.
You can read in the file as you suggested using fopen you can then execute the string that is read in using eval. I wouldn't recommend this. Try another solution to what ever the actual problem is.
I was reading about PDO and I came across the parse_ini_file function. A number of developers suggested using this function to parse in db settings rather than hard coding the db settings in code for security reasons.
My question to you is, does it make sense to do a file read for every load of your PHP application for this extra "security" ?
I wonder how expensive this file read is..
php 5.3
in the comments
http://www.php.net/manual/en/class.pdo.php
I don't really see how it's any more secure.
For example, if your DB settings are stored in defines within a "config.php" file outside of the main web root, they're just as secure as if they're were stored in a .ini file and there would be no per-page parsing overhead (other than having to include the config file as per normal).
Hard coding settings in PHP files is bad because those same PHP files will be sent around, copied, put into repositories, etc. The passwords should be treated with more privacy. Also, it's annoying to have to the source files overwrite your local copies.
Note that I'm referring specifically to embedding in regular PHP files in your project's codebase. If you place your config settings in a PHP file that sits external to all of that, then none of the above applies.
If you are worried about the overhead of parsing one config file, then you shouldn't be using PHP at all... However, you could limit file reads by parsing it only when a cached (e.g., memcache) copy cannot be found.
It makes sense if you have more than just db access stored in the ini file . It can act like a config for you're app so you don't have to open 10 files to change 3 hardcoded variables/constants/whatever . If you don't like reading a file each time you're app is requested then use a php file to store all you're config options ( keep them all in one place is realy good ) , and as sugested keep the ini/php config file out of you're web root .
Probably not. If its a .ini file then a browser can just visit it and download it. At least a .php has a decency of a blank screen.
I have an upload form created in php on my website where people are able to upload a zip file. The zip file is then extracted and all file locations are added to a database. The upload form is for people to upload pictures only, obviously, with the files being inside the zip folder I cant check what files are being uploaded until the file has been extracted. I need a piece of code which will delete all the files which aren't image formats (.png, .jpeg, etc). I'm really worried about people being able to upload malicious php files, big security risk! I also need to be aware of people changing the extensions of php files trying to get around this security feature.
This is the original script I used http://net.tutsplus.com/videos/screencasts/how-to-open-zip-files-with-php/
This is the code which actually extracts the .zip file:
function openZip($file_to_open) {
global $target;
$zip = new ZipArchive();
$x = $zip->open($file_to_open);
if($x === true) {
$zip->extractTo($target);
$zip->close();
unlink($file_to_open);
} else {
die("There was a problem. Please try again!");
}
}
Thanks, Ben.
Im really worried about people being able to upload malicious php files, big security risk!
Tip of the iceberg!
i also need to be aware of people changing the extensions of php files trying to get around this security feature.
Generally changing the extensions will stop PHP from interpreting those files as scripts. But that's not the only problem. There are more things than ‘...php’ that can damage the server-side; ‘.htaccess’ and files with the X bit set are the obvious ones, but by no means all you have to worry about. Even ignoring the server-side stuff, there's a huge client-side problem.
For example if someone can upload an ‘.html’ file, they can include a <script> tag in it that hijacks a third-party user's session, and deletes all their uploaded files or changes their password or something. This is a classic cross-site-scripting (XSS) attack.
Plus, thanks to the ‘content-sniffing’ behaviours of some browsers (primarily IE), a file that is uploaded as ‘.gif’ can actually contain malicious HTML such as this. If IE sees telltales like (but not limited to) ‘<html>’ near the start of the file it can ignore the served ‘Content-Type’ and display as HTML, resulting in XSS.
Plus, it's possible to craft a file that is both a valid image your image parser will accept, and contains embedded HTML. There are various possible outcomes depending on the exact version of the user's browser and the exact format of the image file (JPEGs in particular have a very variable set of possible header formats). There are mitigations coming in IE8, but that's no use for now, and you have to wonder why they can't simply stop doing content-sniffing, you idiots MS instead of burdening us with shonky non-standard extensions to HTTP headers that should have Just Worked in the first place.
I'm falling into a rant again. I'll stop. Tactics for serving user-supplied images securely:
1: Never store a file on your server's filesystem using a filename taken from user input. This prevents bugs as well as attacks: different filesystems have different rules about what characters are allowable where in a filename, and it's much more difficult than you might think to ‘sanitise’ filenames.
Even if you took something very restrictive like “only ASCII letters”, you still have to worry about too-long, too-short, and reserved names: try to save a file with as innocuous a name as “com.txt” on a Windows server and watch your app go down. Think you know all the weird foibles of path names of every filesystem on which your app might run? Confident?
Instead, store file details (such as name and media-type) in the database, and use the primary key as a name in your filestore (eg. “74293.dat”). You then need a way to serve them with different apparent filenames, such as a downloader script spitting the file out, a downloader script doing a web server internal redirect, or URL rewriting.
2: Be very, very careful using ZipArchive. There have been traversal vulnerabilities in extractTo of the same sort that have affected most naive path-based ZIP extractors. In addition, you lay yourself open to attack from ZIP bombs. Best to avoid any danger of bad filenames, by stepping through each file entry in the archive (eg. using zip_read/zip_entry_*) and checking its details before manually unpacking its stream to a file with known-good name and mode flags, that you generated without the archive's help. Ignore the folder paths inside the ZIP.
3: If you can load an image file and save it back out again, especially if you process it in some way in between (such as to resize/thumbnail it, or add a watermark) you can be reasonably certain that the results will be clean. Theoretically it might be possible to make an image that targeted a particular image compressor, so that when it was compressed the results would also look like HTML, but that seems like a very difficult attack to me.
4: If you can get away with serving all your images as downloads (ie. using ‘Content-Disposition: attachment’ in a downloader script), you're probably safe. But that might be too much of an inconvenience for users. This can work in tandem with (3), though, serving smaller, processed images inline and having the original higher-quality images available as a download only.
5: If you must serve unaltered images inline, you can remove the cross-site-scripting risk by serving them from a different domain. For example use ‘images.example.com’ for untrusted images and ‘www.example.com’ for the main site that holds all the logic. Make sure that cookies are limited to only the correct virtual host, and that the virtual hosts are set up so they cannot respond on anything but their proper names (see also: DNS rebinding attacks). This is what many webmail services do.
In summary, user-submitted media content is a problem.
In summary of the summary, AAAARRRRRRRGGGGHHH.
ETA re comment:
at the top you mentioned about 'files with the X bit set', what do you mean by that?
I can't speak for ZipArchive.extractTo() as I haven't tested it, but many extractors, when asked to dump files out of an archive, will recreate [some of] the Unix file mode flags associated with each file (if the archive was created on a Unix and so actually has mode flags). This can cause you permissions problems if, say, owner read permission is missing. But it can also be a security problem if your server is CGI-enabled: an X bit can allow the file to be interpreted as a script and passed to any script interpreter listed in the hashbang on the first line.
i thought .htaccess had to be in the main root directory, is this not the case?
Depends how Apache is set up, in particular the AllowOverride directive. It is common for general-purpose hosts to AllowOverride on any directory.
what would happen if someone still uploaded a file like ../var/www/wr_dir/evil.php?
I would expect the leading ‘..’ would be discarded, that's what other tools that have suffered the same vulnerability have done.
But I still wouldn't trust extractTo() against hostile input, there are too many weird little filename/directory-tree things that can go wrong — especially if you're expecting ever to run on Windows servers. zip_read() gives you much greater control over the dearchiving process, and hence the attacker much less.
First you should forbid every file that doesn’t have a proper image file extension. And after that, you could use the getimagesize function to check whether the files are regular image files.
But furthermore you should be aware that some image formats allow comments and other meta information. This could be used for malicious code such as JavaScript that some browsers will execute under certain circumstances (see Risky MIME sniffing in Internet Explorer).
You should probably not rely just on the filename extension, then. Try passing each file through an image library to validate that its really an image, also.
I don't see the risk in having renamed php files in your DB...
As long as you're not evaluating them as PHP files (or at all, for that matter), they can't do too much harm, and since there's no .php extension the php engine won't touch them.
I guess you could also search the files for <?php...
Also: assume the worst about the files uploaded to your machine. Renamed the folder into which you're saving them "viruses" and treat it accordingly. Don't make it public, don't give any file launch permissions (especially the php user), etc.
You might also want to consider doing mime type detection with the following library:
http://ca.php.net/manual/en/ref.fileinfo.php
Now you are relying on your harddrive space for extracting. You can check fileheaders to determine what kind of files they are. there probably libraries for that.
offtopic: isnt it better to let the user select couple of images instead of uploading a zip file. Better for people that don't know what zip is (yes they exist)
If you set php to only parse files ending with .php, then you can just rename a file from somename.php to somename.php.jpeg and you are safe.
If you really want to delete the files, there is a zip library available to php. You could use it to check the names and extensions of all the files inside the zip archive uploaded, and if it contains a php file, give the user an error message.
Personally, I'd add something to the Apache config to make sure that it served PHP files as text from the location the files are uploaded to, so you're safe, and can allow other file types to be uploaded in the future.
Beaware of this Passing Malicious PHP Through getimagesize()
inject PHP through image functions that attempt to insure that images
are safe by using the getimagesize() function
read more here http://ha.ckers.org/blog/20070604/passing-malicious-php-through-getimagesize/
Better for your user logo use gravatar like here used by Stackoverflow ;)
Use getimagesize function.
Full procedure:-
1.) Extract extension of image/uploaded file and then compare extension with allowed extension.
2.) Now create a random string for renaming uploaded file. best idea is md5(session_id().microtime()).It can not be duplicated and if your server is very fast and can process less than a microsecond than use incremented variable and add them with string.
now move that file.
A tip
Disable PHP file processing in upload directory, it will always prevent you from any server side attack and if possible add your htaccess in root directory or in httpd config file and disable htaccess files from there now it solve your maximum problems