8

I need help regarding file uploading. In one of my projects the client wants to allow a file upload without restrictions on the file type. But I'm afraid that then users can upload executable files like .php, .aspx, .dll, .so and then they can easily do "remote code execution" or "script attack".

How to solve this issue?

Improve this question
3

3 Answers 3

Reset to default
20

The most common solution for this kind of issue is to make sure the stored file is not accessible by the web server.

One simple way to do this is is to store the file in a database and never save it to the disk. You need to be careful not to create some kind of XSS though: do not allow the file to be linked to directly or, ideally, downloaded. If you need the file to be made available through your web interface, use the "attachment" content-disposition header to make sure the browser will not attempt to interpret the file.

Improve this answer
8
  • 2
    Storing binary files to a database is a really, really terrible design decision. Don't do that.
    – Ivan
    Oct 5, 2016 at 14:58
  • 6
    There are people who believe storing binary files in a database is a terrible evil, and those who believe it can be an appropriate solution in some cases. I used to be one of the former until a speaker at a conference threw doubt on that for me.
    – thomasrutter
    Oct 5, 2016 at 15:01
  • 7
    "it's bad" is not going to convince anyone here. There cases when using BLOB in a database can have negative impact on stability, performances, etc. but all of them can be dealt with by using the relevant design. Overall, if you know your tools, it is not a problem that cannot be solved (usually quite easily).
    – Stephane
    Oct 5, 2016 at 15:03
  • 3
    @Johnny depends on the database, Mongo is designed for this.
    – rook
    Oct 5, 2016 at 15:10
  • 4
    @Johnny I'd frame it pretty much the opposite way. Fragmenting customer/user data between storage engines has consequences. Your filesystem and your database handle authentication and authorization differently. They'll scale differently. They manage transactions differently (if at all). They're administered differently. They can fail independently. ... From my perspective, the cases where it's better to fragment your customers' data between independently managed storage devices on distinct "transactional" systems are much more "fringe" than the cases where you'd be afraid of BLOBs...
    – svidgen
    Oct 5, 2016 at 16:18
2

Use a sane framework which includes proper URL routing. Instead of the web server directing requests to executable files depending on the URL, it redirects all requests to the framework's entry point and lets it handle the request, usually based on a route to controller mapping.

This means any uploaded file is safe as there should be no way for it to get executed.

Improve this answer
0

Store it in a special database or any nonexc environment as Stephene mentioned. If only authorized people have to upload a file , then you can apply those restrictions and add captcha as well to avoid bots.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .