6

I'm working on a project for a client where they would like their users to upload a ZIP file that can be extracted. Once extracted, we would utilise certain files in there, such as images and HTML files.

It's clear that this is a huge security risk as you cannot safely check the contents of the file. The project is currently for internal users only, but they would like to open it up to external users at a later point.

The project is currently being built with Laravel, and there are no libraries that could possibly help there. So I figure this is probably going to be more of a question regarding the server itself. But what measures could we take to prevent viruses and attacks in these zips?

  • If you do decide to do this, make sure you are unzipping in a location that does not share space with anything important and try to use a utility/library that understands things like zip bombs. It is quite possible for very small zip files to explode to many many gigabytes on the disk. – crovers Nov 24 '16 at 14:24
  • I would recommend you to use a bastion host for this which is isolated and not connected to the webserver directly. And then run a service to check for files to verify them. – M.S.P Nov 25 '16 at 3:36
  • 1
    P.S if any harmful file is uploaded, it may result a DOS. However, that will atleast safeguard your webserver. – M.S.P Nov 25 '16 at 3:37
5

Maybe you can find libraries that could help to detect harmful files. But I'm afraid that you will have to choose between being strict and having false positive, or loose with the risk of occasionaly letting malware pass.

My advice here would be to rely on traceability. You control (as much as possible) the uploaded files, but for each one keep the name or id of the user that uploaded it. And you advertise largely on that. If later a problem occur, you will be able to identify who is guilty for it. Of course it only makes sense if you know all your users. But I cannot imagine a way to secure a site accepting dynamic content for uncontrolled users ...

  • I think that is also a good step to take, thank you very much for the reply! – Jarrod Nov 24 '16 at 17:49
3

There are a handful of "unzip services" where you send off the file and get contents back. As long as data confidentiality isn't critical this would offload much of your risk. Just search for them.

  • Thank you for your reply. Do you think you could recommend some? – Jarrod Nov 24 '16 at 17:48
  • 2
    What black magic do these "unzip services" use which one can not implement themselves on their own server? – Philipp Nov 25 '16 at 9:23
1

I suppose a proper answer is missing. So the best way, I could think of is as follows:

  1. Create a bastion host for uploading files. And keep it isolated from the server. This will help you to protect your site from DOS and even if a DOS occurs, it would be only for a particular type of service.
  2. Limit the size of upload and create Captcha , so that people don't upload huge files on the host.
  3. Run unzip-services and using signature based detection and heuristic behaviour detection, try to verify all the files for anomalies, (possibly ADS), trojans, rootkits, etc...
  4. Always assign a ID number to the zips so that it can be traced back to the user who uploaded it. This will help you to confront the person who uploaded the malicious threat.

Complete mitigation is not possible in this case but the solution will allow to reduce the threat to substantial level.

1

Zip archives themselves are not evil. Only their content is and only if executed.

The act of unzipping a zip archive is only dangerous if your implementation of the decompression algorithm has a vulnerability (for example, to a zip bomb). Even when there are harmful executables in there, these are only dangerous when executed as a program.

So there is no reasonable security concern with unpacking the zip archives, fingerprint the filetypes (do not rely on extensions) and keeping only the whitelisted filetypes. As an additional security precaution you can also virus-scan the files. But when you don't keep any unpacked binaries around, this is likely unnecessary.

Note that embedding 3rd party HTML on a website is dangerous, because it opens the site up to XSS injections. It is only reasonably safe if users can not look at HTML uploaded by other users.

  • Zip bombs aren't always intentionally evil. I worked on a system that was brought offline by a zipped log file. – Robert Fraser Nov 25 '16 at 11:14
  • Search Google for 'zip exploits' it's certainly not wise to do it in production. – Josh Bressers Nov 25 '16 at 11:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.