We save the request payload and
Content-Type header in a database. It should be JSON or CSV but may be malformed. Support users download the request payload as a file in their browsers using
Content-Disposition: attachment. We attempt to add a file extension of either
.json or, the default, '.csv'.
How can the support users download this file safely when it could contain absolutely anything? I'm less worried about ZIP bomb type attacks but more spyware, ransomware, etc., etc.
We have a REST API that supports both JSON and CSV content types.
The API is secured with a unique client certificate for each user.
For reasons of arbitration we must keep an audit record of the exact content submitted to the service, we do this by storing the bytes directly in the database along with the content type header and some other fields from the URL and client certificate. All of this, with the exception of the certificate is pre-validation as we need to record invalid submissions as well.
We have a support team a very activity for them is to help users who are not able to submit their documents because of a) malformed content or b) the content violates some business rule.
Now a requirement has come in to allow our support team to download the audit information so they can try to reproduce the users issue by submitting it to a test system or just looking at the content to spot mistakes.
We will provide a link to the file with either a .csv or .json extension if we can detect the content type.
Obviously this is wide open to XSS from the point of the unvalidated fields but that is mitigated easily enough by correctly encoding it for display however I do not see how this is possible for the downloaded file.
For example, I submit an Excel spreadsheet with
Content-Type: text/csv, a support user downloads the file and opens in Excel to view the CSV and gets warned "the file extension doesn't match the content, do they want to open anyway?" to which they click "yes" because they are trying to figure out why it's malformed and my malicious spreadsheet is opened.
Even if we remove the file extension requirement then a support user may try to open it in Excel anyway seeing the content is supposed to be a CSV.
I cannot think of any robust solutions;
- Train support users to open in plain text editor first, but users are fallible)
- Prevent downloading of content that is not character data, but character data can still be an attack vector, i.e., a
.batfile and doesn't meet the requirements
- Encode content and display on screen for copy/paste thus ensuring it's only text, files could be large and currently use streaming from DB to output stream to keep memory overhead low.
- Trust our users and that they keep their client certificates safe
Is it just that the requirements will always be at odds with security and there is no way to download user submitted files safely?