...
Code Block |
---|
<action name="doUpload" class="com.example.UploadAction"> <interceptor-ref name="fileUpload"> <param name="maximumSize"> 10240 </param> <param name="allowedTypes"> text/plain,image/JPEG,text/html </param> </interceptor-ref> </action> |
The code for file upload is present upload appears in the Upload
class:
Code Block | ||||
---|---|---|---|---|
| ||||
public class Upload extends ActionSupport { private File uploadedFile; // setter and getter for uploadedFile public String execute() { try { // File path and file name are hardcoded for illustration File fileToCreate = new File("filepath", "filename"); // Copy temporary file content to this file FileUtils.copyFile(uploadedFile, fileToCreate); return "SUCCESS"; } catch (Exception e) { e.printStackTrace(); addActionError(e.getMessage()); return "ERROR"; } } } |
The value of the parameter type maximumSize
ensures that a particular Action
cannot receive a very large file. The allowedType
parameter defines the type of files that are accepted. However, this approach fails to ensure that the uploaded file conforms to the security requirements because interceptor checks can be trivially bypassed. If an attacker were to use a proxy tool to change the content type in the raw HTTP request in transit, the framework would fail to prevent the file's upload. Consequently, an attacker could upload a malicious file having an .exe
extension.Although this code appears to violate ERR08-J. Do not catch NullPointerException or any of its ancestors, it falls under the exception ERR08-EX2.
Compliant Solution
The file upload must succeed only when the content type matches the content actually present within the file. For example, a file with an image header must contain only an image and must lack executable code. This compliant solution uses the Apache Tika library to detect and extract metadata and structured text content from documents using existing parser libraries. The checkMetaData()
method must be called before invoking execute()
.
...