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

Post a Comment

Popular posts from this blog

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...
1 comment
Read more

'Information Leakage-Improper Error Handling' dropped

From Owasp Top 10 2010 List, the issue 'Information Leakage-Improper Error Handling' has been dropped. But it's not the final list,its child release actually. Bu I feel it shouldn't be set aside because its still the one of the prevalent issues these days. That's why I mailed to Dave Wicher: Hi Dave, Excellent work, Congrats! Just one little query- Don't you think that Information Leakage & Improper Error Handling still deserves to be in Top 10? Dave replied: This topic is clearly a very prevalent issue that deserves attention by most organizations. However, the typical impact of such a flaw is usually very low. Therefore, the overall risk of this type of flaw is lower than the other items in the top 10, which is why it was replaced in this update with one of the 2 new items. Regarding dropping Info Leak/Error handling - It is incredibly prevalent, no question. But their impact is typically very low, so the overall risk is low, which is why it fell out of t...
3 comments
Read more

jtool - an alternative to otool

jtool comes with a capability of running on Linux environment. Some ipa scanning tools are created to run on Linux environment where mac environment is not available. In such cases tools such as otool and class-dump-z will not work. So jtool can be an alternative to otool. For more information on jtool please refer to http://www.newosxbook.com/tools/jtool.html . It lists down various commands which have same output as otool or a equivalent. There are several commands mentioned in link. But for our customized requirements and basis checks I have listed down the below ones after running on many binaries. The outputs are similar or equivalent to otool and class-dump-z: Commands for checking PIE flag (ASLR) in jTool jtool -d -v -arch | grep stack ·           Automatic Reference Counting (ARC) protection: jtool -d -v -arch | grep _objc_release ·           To check if the devic...
1 comment
Read more