Im working on an upload script, and i want a user to be able to upload any file.
I had it al working on localhost, i added
php_flag engine off
AddType text/plain php html shtml php5 php4 php3 cgi asp aspx xml
to my htaccess in the upload folder, and it showed the source of PHP, html and all other files. Exactly as i wanted to.
Now i tried to upload it to a real webserver, and unfortunately my host does not allow such .htaccess files.
I tried openinging the files with file_get_content() and fopen() and giving them a text/plain header.. but nothing works. It first executes the scripts and shows the output in my textarea.
Do you guys have any suggestions on how i can fix this without .htaccess ?
Thanks!
Don't upload files into the webroot and let people access them directly. As you say, .php scripts (and probably a lot more) get executed that way. A classic way for arbitrary code execution attacks.
Store uploaded files outside the webroot where they're not publicly accessible and create a script that allows users to download the files, for example using readfile or Apache mod_xsendfile, after having done the necessary permission checks.
Also see Security threats with uploads.
Related
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.
They have some php code within (if, endif, variables), but essentially they are html files.
Do you think is a good idea to use the .html extension and prevent direct access to them trough .htaccess, so the php code is not visible to anyone ?
Is it safe?
can you test the script?
As far as I know the PHP is just server-side so after the server "do its thing" it doesn't show on the users computer (when he tries to see the source code).
Javascript and HTML are displayed but not the php.
I have used the .htaccess file to block some other files in the folder such as the DB credentials and such that I had named .inc (for include). If you block the html with the htaccess noone is going to be able to see the webpage.
I hope I understood it right! (And clarified it as well)
Just have an .htaccess with deny from all in the views folder... ;p
Tho if you have files like images or css that you want loaded from that theme folder then by all means rename the view to .php and put as this on the first line:
if (!defined("RUN")){die('No direct access');}
Obviously define('RUN',true); in your config.
I'm working on a little project with a few friends, and have set up a pretty simple PHP upload script that only certain users can access. I am not worried about any type of attacks against the server, since this is for fun, but I do have a question.
I've made a subdomain (static.foo.bar) where the uploaded files are moved to. This subdomain had mod_php turned off, to prevent malicious upload and execution of php scripts. The script also checks for file extensions and mime content types, but I assume those can easily be bypassed/spoofed.
However, a user could easily upload an .html file and have it redirect somewhere else. Likewise, they could upload an image file instead and have it display an image in the browser, instead of being asked to download the image.
I assume this is the behavior of the browser, but I've also noticed that when uploading a file to sendspace (or any other service), even if the file is .html (and valid html) it will ask the user to download it instead of displaying it on the website.
I am running Apache on CentOS.
How do I accomplish this?
ForceType is probably what you're looking for.
# In your .htaccess file
<Location /uploads_directory>
ForceType application/octet-stream
</Location>
You want to set all files' mime type to application/octet-stream so the browser will download them instead of trying to show the content.
I'm having a bit of trouble trying to access the content of .txt files on a remote server that are in an .htaccess protected directory.
What I am trying to do is the following:
Connect to the FTP server via PHP and use ftp_nlist to retrieve a list of all the .txt files in a directory. Up to here, everything works fine.
For each .txt file found, I want to retrieve the contents. There are a number of ways to do this normally which all work fine when there is no .htaccess file protecting the .txt files.
BUT! As soon as I protect the online directory with the .htaccess file, every single method I have tried fails to get the contents of the .txt files. The .htaccess file that is protecting the folder that contains the .txt files has the following (and nothing else):
<Files *.txt>
Order Deny,Allow
Deny from All
</Files>
Obviously, the online PHP website itself can access the contents of the .txt files without any problems, and the .htaccess file itself is doing it's job perfectly (denying direct access to any of the files), but when I'm trying to access the .txt files remotely from my WAMP server, I just can't find a way to bypass the .htaccess protection.
Basically, I want to imitate remotely, from my WAMP server, what my website already does itself locally by using $contents = file($filepath). Surely there must be a way... Can anyone point me in the right direction? Should I be using a different method of protecting the .txt files, or should I be using a specific PHP function to access the contents?
Your question isn't clear.
If you protect a folder or a file with .htaccess you will be still able to download that file with FTP. .htaccess affects only Apache (http requests).
If you want to be able to download those file anyway with http, then you just do a script that outputs its content:
downloader.php:
//> Check if the admin is logged, and check if $_GET['filename'] is allowed
readfile($_GET['filename']);
Then you can request your file with:
http://yoursite/downloader.php?filename=file.txt
Of course be sure to protect the access of this downloader.php
I'm trying to develop a file uploading module on our new site that allows you to upload any file to our servers. The uploaded file is uploaded to /files, in which the following .htaccess to prevent users from executing i.e a .php file:
<Files *.*>
ForceType applicaton/octet-stream
</Files>
This triggers the browsers download window (at least in FF and Safari), but is it safe to assume the file won't be run on the server using this method? If not, how would you implement such a solution?
I think the safest thing is to restrict 100% web access to the directory, and have a script like download.php through which you pass a file id that then fetches the appropiate file and outputs it to the browser. However, I am pretty sure that what you have will work and is safe.
is it safe to assume the file won't be run on the server using this method?
Kind of, but it depends on what other directives are present in your config; maybe there are other rules set up to allow PHP files to run. If the only way you're enabling PHP is by keying the PHP handler on file type, that should stop PHP executing.
However, stopping PHP executing is just one of your worries. If people upload files that contain active content, such as HTML or Flash — even if the filetype says it's an innocent image — they can gain control of other users' sessions on your site through cross-site scripting (XSS). See Stop people uploading malicious PHP files via forms for some discussion of this.
A ‘download.php’ interface that uses Content-Disposition to always trigger the download box, coupled with storing the files under non-user-supplied filenames like ‘1234.dat’, is much safer.
I think you actually want this:
<Directory /path/to/files>
SetHandler default-handler
</Directory>
What you have might work in practice, because the server is configured by default not to execute anything unless specifically told to do so, but it doesn't really guarantee that nothing will be executed. ForceType just sets the content type for static files (I'm not sure, but I doubt that it affects executable scripts).
Seconding Paolo's answer, move your files directory out of the accessible path. You can then write the download.php script using PEAR's HTTP_Download module to serve the files.
I agree with Paolo, his way is more secure. There is always the issue of someone exploiting your PHP files to execute an uploaded one. Bad Example:
include_once("/modules/".$_GET["module"].".php");
Where someone passed in module=../Files/exploit
For maximum security, you shuold have the folder containing the uploaded files be mounted from a separate partition with the no-exec flag.