1

I want to know if I can allow uploading all types of scripts and add these rules to a virtual host configuration; so please advise and tell me if there will be some exploits that can be used to bypass this security rules ( if yes please how to block it)

Thanks in advance, Maybe this question has been answered earlier but I don't know how to get the right results.

WMax
  • 31
  • 4
  • 3
    Don't try to create a blacklist, try to create a whitelist. Are you trying to host images, videos, or another type of data? – ThoriumBR Oct 09 '14 at 12:00
  • All kind of files, images and each and every file files but i want to be secured. – WMax Oct 09 '14 at 12:05
  • I want to know if still someone can execute php code by any way? – WMax Oct 09 '14 at 12:35
  • I actually flagged this question for migration to stackoverflow, but to come and think of it, this question fits on both sites – Lighty Oct 09 '14 at 12:59

1 Answers1

4

There are a few things you can do to mitigate the risk:

  1. Try to upload the files to a path outside your webroot

    For example, if you host your site on /var/www/myserver/html, make your PHP upload script write files on /var/www/myserver/data.

    This way, a Local File Include will not work, as the sent files are outside the server root.

  2. Don't use Mime Type or file extension to determine the file type

    It's easy to forge Mime Type and file extension. Instead, use PHP Fileinfo functions to identify the file.

  3. Don't store the files with the original filename

    Always rename the file to something unpredictable, like a hashed salt. Doing this makes harder to an attacker to predict and use the file he just uploaded.

  4. Make sure your error messages are not leaking data

    If your error message says File webshell.avi not found on /var/www/myserver/data, you are leaking precious information. On a production server, don't enable error reporting, or send them to you, not the client.

  5. Use a script to read the files and send the data to client

    Don't link direct to the files, but have a script read them instead. This way you can sanitize the data before sending, and the raw files will not be processed by your server.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • having the IIS server configured so that accessing other files/folders that aren't supposed to be touched with HTTP auth should be in that list too, to prevent up/downloading from other locations, or am i wrong? – Lighty Oct 09 '14 at 13:01
  • 1
    You are right. But having files outsite webroot is easier and safer: you don't have to configure anything on IIS, so there's nothing to forget on an update. – ThoriumBR Oct 09 '14 at 13:03
  • Ye i configure httpd host to home folder and is iam safe with the text file and no user can execute php code in ay way right? – WMax Oct 09 '14 at 13:50
  • It depends largely on your code. Hosting files on the server root is secure if the code is secure. Hosting outside adds a layer of security, and following my list will add several layers. But poorly written code can break all those layers. – ThoriumBR Oct 09 '14 at 14:13
  • @ ThoriumBR Could you say me a example of code that is capable of breaking all these? I think you are wrong as i don't think anyone can break that security, i add almost all of the file extensions to show as plain text. – WMax Oct 09 '14 at 16:53
  • Depending on your system, I would say to move the upload folder to the same level as your webroot dir. for example: your webroot `/home/username/public_html` contains the website, you should make a new folder on `/home/username/` and upload there. This way, you block direct access to php scripts that might be uploaded. After creating the folder, remove the permitions to execute. – Ismael Miguel Oct 09 '14 at 17:01
  • Permissions to execute on the `/home/username` will not prevent execution of php scripts. That's because the php binary (`/usr/bin/php`) will have execute permissions anyway. – ThoriumBR Oct 09 '14 at 17:10
  • But at least they won't have direct access to the file. It must be read by a script and sent to the browser. If someone uploads a file containing `GIF89a p !ù , D ;` (base64: R0lGODlhAQABAHAAACH5BAUAAAAALAAAAAABAAEAAAICRAEAOw==) the code won't be executed. Removing the execute permissions is just to be sure that there is no way to accidentally leave an open vulnerability that might let run any files. And if php is started by the shell, it won't run without execute permissions. – Ismael Miguel Oct 09 '14 at 17:25
  • You can only execute a bare php script by connecting to a shell. If an attacker have shell access to your server, it can `chmod +x anything.php`. But with shell access, he don't even need to. – ThoriumBR Oct 09 '14 at 17:29
  • But still, creating the files in the same level as the webroot dir will help a lot. If you upload the file to the webroot dir with that data and name it `a.gif.php` and access it, the code will run. Reading the magic number would tell it is a simple gif image, and the browser would agree. And while you access it, it could be doing something worst like installing a worm or opening a backdoor or anything it wishes (it could try to get root access, since php has access to the shell, and using the shellshock bug then the whole system is in deep trouble). – Ismael Miguel Oct 09 '14 at 17:34
  • You are right. That why my first recomendation is to not store the files on a dir accessible by the webserver. – ThoriumBR Oct 09 '14 at 17:37
  • Well guys can you just show me a simple script that may bypass my these security? I use a single random folder creating for each uploading file and delete it after 1 month. I have made a a user and assigned to the directory in htaccess file. – WMax Oct 10 '14 at 20:46