3

I am working on a file upload feature in our app. Users can also download uploaded files from the app. To prevent malicious file upload, I am checking magic bytes of the file to find the file type uploaded and verify its part of my whitelist (doc", "pdf",xls", "xlsx", "docx", "png", "jpeg", "ppt", "pptx", "msg", "jpg", "gif").

I am good so far and now it occurred to me a scenario where in user can upload a file say like

  1. ms word which can have an embedded exe or any malicious file.
  2. outlook message item which can have an malicious file attachment.

Are these scenarios valid case of attacks on Unrestricted file upload? If so how to handle these? Appreciate any insights on this.

Pro
  • 241
  • 3
  • 4
  • 2
    We cannot say what restrictions you need to put on your uploads since these fully depends on your unknown use case. But yes, if you allow complex container formats (like office or PDF) a simple magic bytes or extension check is not enough. But, what you exactly need to do depends on your specific use case - some might allow you to convert the file into a form which automatically strips all these problems while other use cases don't allow this. – Steffen Ullrich Feb 13 '18 at 07:05
  • You provide insufficient details. Best universal approach would be to only allow specific file types and deny the rest. – Overmind Feb 13 '18 at 07:06
  • @SteffenUllrich, We are OK to have restrictions in our use case. Could you elaborate on how we can detect the embedded files and reject them? – Pro Feb 13 '18 at 07:10
  • 1
    @Pro: this depends on the specific file format and is not easily done in all cases. Modern office documents are just ZIP files you could analyze for embedded files. Older office documents are more complex and detecting macro based attacks is complex too. PDF is yet another format which needs its own tools. Mail messages are also a tricky container format etc. In short: there is no general and no easy solution. The best is to limit uploads to mostly innocent formats like images. – Steffen Ullrich Feb 13 '18 at 07:18
  • Thanks @SteffenUllrich, btw I have set response header "Content-Disposition" so that the uploaded file can only be downloaded to the machine and doesnt run in browser..do you think can solve the issue with container files? – Pro Feb 13 '18 at 08:46
  • 1
    @Pro: an office document or mail will probably not be interpreted by the browser anyway but just downloaded. But, this does not make it less dangerous. If the user trusts your site then he will open the office document with the standard application (i.e. MS Office in many cases) and then run into the security issues there. – Steffen Ullrich Feb 13 '18 at 09:05
  • Also we store the file uploaded as a BLOB in database and its not stored on the Linux server where our application is hosted. Does it make it less dangerous? I guess at least the attacks on the web server are prevented but still scripts embedded in a doc can be run to steal user info like pwd etc from the desktop where use downloads the script? – Pro Feb 13 '18 at 09:20
  • See also https://security.stackexchange.com/questions/11756/is-it-safe-to-serve-any-user-uploaded-file-under-only-white-listed-mime-content – Xiong Chiamiov Feb 13 '18 at 20:26
  • Possible duplicate of [Is it safe to store and replay user-provided mime types?](https://security.stackexchange.com/questions/8648/is-it-safe-to-store-and-replay-user-provided-mime-types) – Xiong Chiamiov Feb 13 '18 at 20:26

1 Answers1

1

You can run Anti-Virus Scan on them. In simplest scenario, you could use free clamav antivirus. You can also use commercial scanners with file server license or something similar. This would give you maximum flexibility as well low false-positive ratio.

Also, you can sanitize files like they propose on OWASP.

According to this, you can search for OLE objects in Office Documents, embedded files in PDF, and I think both can produce false positives.

Regarding images they propose you use graphics library to recreate the image from original data by resizing it slightly.

Aria
  • 2,706
  • 11
  • 19