Skip to main content

Effective way of preventing malicious file upload

The below are all the prescribed best practices when deciding to upload a file in a web application. The below are list of implemented approaches:

A few points:

  • Extension whitelistng: Obvious and the first line of defense was to white listing of extensions. A simple but easily by-passable approach. Good to have this approach.
  • File header type checking: This helps prevents the above bypass. Even if the request is captured and tampered to include a restricted file (say exe), the application will check the file header (the magic nos) of the file and reject it. Suppose an application only accepts .pdf files and expects %pdf header, but when we try uploading an exe which has a header MZ, the file will not be uploaded. In this case even though you try replacing the MZ with %pdf, the file will get uploaded but the resultant file would be treated as a pdf and not an exe, so becomes useless.
  • Content type: The content type decides how to treat/ render this file once uploaded. The application restricts the type of Content Type in the request. Any attempt to change the content type to something which is not whitelisted will not let the application upload the file at all.
  • Anti Null-Byte: Sometimes in php based application, it's possible to by pass the extension restrictions by inserting the NULL bytes in the file name, so that the application check the last extension which is valid but while reading the file name once it's uploaded it discards the anything after the null byte and effectively uploading a php file. The application concerned was even filtering the file names and did not allow any special characters in the file name.
  • Size of the file: Another effective approach is to check the file size is only within the prescribed limit. There's no use of allowing a file with size of 100 MB if it just meant to be profile pic upload. Another good to have approach.
  • Random file names: The files getting uploaded were being assigned a different random name. so it's hard to guess the file name which needs to be accessed. The original file name is discarded.
  • File contents scanning: The file was being checked for any seemingly malicious codes before uploading. Our attempt to upload an innocent looking file with an embedded script was unsuccessful. 
  • Exiftool: We tried exiftool to alter a file header and insert an script and upload the modified image file. The file gets uploaded as all the above check get passed, but the code would not execute since the application can not invoke the headers. It just renders the file.
A mix of above approaches seems to be pretty solid when trying to thwart malicious file upload.


Comments

Popular posts from this blog

Ardilla- New tool for finding SQL Injection and XSS

Three Researchers -- MIT's Adam Kiezun , Stanford's Philip Guo , and Syracuse University's Karthick Jayaraman -- has developed a new tool ' Ardilla ' that automatically finds and exploits SQL injection and cross-site scripting vulnerabilities in Web applications. It creates inputs that pinpoint bugs in Web applications and then generates SQL injection and XSS attacks. But for now Ardilla is for PHP -based Web app only. The researchers say Ardilla found 68 never-before found vulnerabilities in five different PHP applications using the tool -- 23 SQL injection and 45 XSS flaws. More information is awaited. For their attack generation techniques refer to their document at: http://www.cs.washington.edu/homes/mernst/pubs/create-attacks-tr054.pdf

File Upload through Null Byte Injection

Sometimes, during file upload we come across situation wherein there would be check on the file extension at the client side as well as server side too. If the application does allow only .jpeg extension to be uploaded, the client side java script checks for the extension of the file before passing the request. We all know that how easily this can be defeated. Some applications, checks for the extension at the server side also. That's not easy to bypass. However there are some ways with which it still can be bypassed. Most of server side scripts are written in high level languages such as Php, Java etc who still use some C/C++ libraries to read the file name and contents. That leads to the problem. In C/C++ a line ends with /00 or which is called Null Byte. So whenever the interpreter sees a null byte at the end of the a string, it stops reading thinking it has reached at the end of the string. This can be used for the bypass. It works for many servers, specially php servers. T

Combining power of Fiddler with Burp

Both are pretty powerful tools when it comes to intercept and modify http communications. But at some point of time, they become even more powerful combo if tied with each other. They complement each other. In a recent pentest I came across a similar situation where in Burp was not able to intercept a specific kind of traffic and Fiddler came to rescue. The application was designed to upload video. The initial communication was straight forward, I mean logging into application, filling up the video details etc. And all these were easily captured by Burp except the point where you hit the Upload Video and it connects to a different server and surprisingly it was not captured by Burp, not sure why, even after repeated attempts. So, I fired Fiddler to see if the it sees this request. But it's a;ways to play with requests using Burp due to it's various functionalities like, Intruder, Repeaters etc. But it was necessary to capture this request in Burp. So the below steps can be