Client-Side File Upload Validation Bypass

[dkatzz]

Describe the bug The program's image upload functionality relies on client-side file type checks, which can be bypassed. This allows an attacker to upload potentially harmful files disguised with permitted extensions.

Recommendations

• Implement strict server-side validation to verify the actual file type based on content analysis
• Maintain an explicit allowlist of allowed file types

[dkatzz]

@caitlinshk I remember chatting about something similar and it being difficult to validate anything on the server side because we send the file straight to AWS and their error messaging isn't great, right?

[caitlinshk]

It is actually possible to have AWS validate the file type, we just need to set it up - see https://github.com/civiform/civiform/issues/6301.

It's true that if a user bypasses the client-side type check and uploads a disallowed filetype, then they'll see an ugly AWS error and not be redirected back to CiviForm. But, that seems fine since the people doing that would likely be malicious attackers.

[gwendolyngoetz]

Also related to https://github.com/civiform/civiform/issues/5218

[nb1701]

There's another small bug here, in that even when client side validation catches that it's invalid, the save image button is enabled and then ends up sending nothing back, resulting in an error from AWS because the file has size zero.

[nb1701]

Additionally, you can't test the fix here locally, because LocalStack does not appear to respect the Content-Type condition.

[dkatzz]

Additionally, you can't test the fix here locally, because LocalStack does not appear to respect the Content-Type condition.

It may be worth filing an issue against localstack. They've fixed issues we've seen in the past (https://github.com/localstack/localstack/issues/10351)

[nb1701]

This isn't going to be quite as easy as I'd hoped. While we can add a Content-Type restriction to the policy in the presigned upload URL, since we're submitting it through a form, the type on the POST request is multipart/form-data, and apparently AWS is only looking at the header to determine if the data is allowed.

We may need to do something like let it upload, and then on the callback, check the MIME type on the file just uploaded, and delete it if it is invalid. Which is pretty cumbersome.

[nb1701]

Some more notes:

• What I said above is incorrect. AWS requires the POST to be multipart/form-data. What it's actually looking for is the Content-Type field within the form.
• We can't set the Content-Type field within the form at page generation, so we'd end up having to have some JS to dynamically change the form value when the user selects a file to upload.
• AWS doesn't actually check that the provided file is the content type you say it is in the form. So you could attach a malicious exe, bypassing the accept field in the input tag, modifying the client-side JS to always inject image/jpeg for the Content-Type field, and AWS will happily accept it.
• This seems to make the Content-Type policy field in the presigned upload URL kind of useless from a security standpoint.
• I think we're going to have to do one of the following:
  • Have the form submit back to CiviForm, have CiviForm check the actual file type, then send it to S3 and let it redirect back to the page like it does now
  • Don't use the Content-Type policy check, let it upload, then have the callback go to a CiviForm validation check of that particular file, and delete it if it doesn't conform.
• I think the second option is probably less secure, both because we let the file land in the S3 bucket, and also because it relies on the callback actually happening, which a user could block.
• The first option isn't super great being that we'd upload the whole file to the server, and could potentially introduce a DoS if you bypass the file limit check and upload a massive file.

Still not sure what the best way forward is here.

[nb1701]

Going to investigate post-upload validation. We maybe be able to download perhaps just the first 1kb of the file and pass it through https://tika.apache.org/ and delete the file if it is not an expected type.

[nb1701]

After some more thought, possibly all we need to do is ensure the file has a valid extension. For MacOS/Linux, a file can't be executed unless you chmod +x it, so if a malicious executable is uploaded, double clicking it isn't going to do anything. Windows relies on the file extension to determine how to open it, so as long as we ensure all files have a valid extension type, we should be okay there.

[dkatzz]

@nb1701 should this still be marked as blocked or can this be worked on now?