OWASP Top 10 number 3: Malicious File Execution
Number 3 in the Top 10 most critical web application security vulnerabilities identified by the Open Web Application Security Project (OWASP) is Malicious File Execution, which occurs when attacker's files are executed or processed by the web server. This can happen when an input filename is compromised or an uploaded file is improperly trusted.
Examples
- file is accepted from the user without validating content
- filename is accepted from the user
In the example below a file name is accepted from the user and appended to the server's filesystem path.
|
If the filename was compromised to ../../web.xml , it might allow access to web server properties
Malicious File Execution can result in:
- files loaded from another server and executed within the context of the web server
- modifying paths to gain access to directories on the web server
- malicious scripts put into a directory with inadequate access controls
Protecting against Malicious File Execution
- the Java EE Security Manager should be properly configured to not allow access to files outside the web root.
- do not allow user input to influence the path name for server resources
- Inspect code containing a file open, include, create, delete...
- firewall rules should prevent new outbound connections to external web sites or internally back to any other server. Or isolate the web server in a private subnet
- Upload files to a destination outside of the web application directory.
- Enable virus scan on the destination directory.
Java specific Protecting against Malicious File Exection
Use the OWASP ESAPI HTTPUtilities interface:
- The ESAPI HTTPUtilities interface is a collection of methods that provide additional security related to HTTP requests, responses, sessions, cookies, headers, and logging.
The HTTPUtilities getSafeFileUploads method uses the Apache Commons FileUploader to parse the multipart HTTP request and extract any files therein
public class HTTPUtilities
public void getSafeFileUploads(java.io.File tempDir,
java.io.File finalDir)
throws ValidationException
References and More Information:
- Top 10 most critical web application security vulnerabilities
- Open Web Application Security Project (OWASP)
- OWASP TOP 10 FOR JAVA EE
- OWASP Enterprise Security API
- OWASP ESAPI Overview Presentation
- Login or register to post comments
- Printer-friendly version
- caroljmcdonald's blog
- 3865 reads






Comments
JPA but unrelated to this entry
by saturon - 2009-10-21 12:41
Sorry this is completely unrelated to you post but since you are an expert I just be so free;) : Can you maybe tell me the intrinsic reasons why in the JPA 1.0 EntityManager when retrieving an Object via find, you have to deal with null if not found, but when using the Query interface via createQuery getResultList throws a NoResultException when not found. Maybe i am missing something but I feel its very inconsistent for a Language, and actually I had to do a lot of redesing because of changing from a simple finder to a more fine grained query using the query interface. Thanks Ben