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?

Anders
  • 64,406
  • 24
  • 178
  • 215
Ravi
  • 89
  • 1
  • 6
  • 17
    Uploading them is fine. You want to avoid them being executed by your server (and possibly by unsuspecting downloaders). Be warned that you can lie in extensions; putting PHP code in a .txt or extensionless file could still execute. – SomeoneSomewhereSupportsMonica Oct 05 '16 at 07:38
  • 2
    Please read through the questions in [tag:file-upload]. This question has been asked and answered multiple times before, in great detail. See, e.g., http://security.stackexchange.com/q/503/971, http://security.stackexchange.com/q/8587/971, http://security.stackexchange.com/q/7506/971, http://security.stackexchange.com/q/11756/971, http://security.stackexchange.com/q/8648/971, and others. – D.W. Oct 05 '16 at 20:27
  • @D.W. I don't think any of the linked question is a duplicate of this one. – Anders Oct 05 '16 at 21:15

3 Answers3

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.

Aaron
  • 103
  • 3
Stephane
  • 18,557
  • 3
  • 61
  • 70
  • 2
    Storing binary files to a database is a really, really terrible design decision. Don't do that. – Ivan Oct 05 '16 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 05 '16 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 05 '16 at 15:03
  • 3
    @Johnny depends on the database, Mongo is designed for this. – rook Oct 05 '16 at 15:10
  • 1
    I get that, but I don't find the fringe cases where it's appropriate to be worth the trouble it causes when done incorrectly (which bites most new developers who don't understand the ramifications of what they're doing). Hiding potentially malicious/binary code inside a database field outside the visibility of any sort of AV product does not strike me as a well-thought-out idea. – Ivan Oct 05 '16 at 15:11
  • @Johnny - https://glyph.twistedmatrix.com/2016/04/dont-stop-the-blob.html – TessellatingHeckler Oct 05 '16 at 15:29
  • 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 `BLOB`s... – svidgen Oct 05 '16 at 16:18
  • Thanks to all for your prompt response! after this discussion I come to know the better way is store the file on non-execution environment or I could use the CDN. – Ravi Oct 06 '16 at 12:02
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.

André Borie
  • 12,706
  • 3
  • 39
  • 76
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.

Abdelhafeez Bushara
  • 11