1

I have a web application (forum software) where I am working on a feature about user attaching files to the forum posts.

The application is written in assembly language and the database is SQLite.

The approach I used is to keep the attached files as a blobs in the database and to allow downloading only with the headers:

Content-type: application/octet-stream
Content-Disposition: attachment

This way, the files will never be stored as a files on the server.

Any validations of the file type and content are not planned to be implemented, because are considered superfluous on this setting (and I want to give the users maximal freedom, without compromising the security of course).

It is clear, that uploading huge files is one way to make DoS attacks, but this is not a subject of the preset question.

The possible bugs in the web-application itself, causing buffer overflows and similar are not an issue as well (they are possible, of course, but I want to ask about the architecture, not the implementation).

The questioned setting is the following scheme:

  1. file-less: from the POST request -> to the SQLite blob field.
  2. from the SQLite blob field -> to the network and user browser.
  3. Always: application/octet-stream and Content-Disposition: attachment
  4. No server validation of the file type and/or content.

And the question is:

What attack vectors are still possible with the above approach?

P.S. The question Pentesting file upload functionality is similar, but mainly discuss the uploaded files as existing in the FS of the server that is different from the system I am asking for.

closed as too broad by Steffen Ullrich, Steve, Bacon Brad, CaffeineAddiction, Matthew Sep 29 '17 at 15:23

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Attack vectors against what? Against the server, the application, the users of this service, the non-users of the service (since it might be used to distribute malware) ... ? – Steffen Ullrich Sep 28 '17 at 11:57
  • About the server and immediate action over the visitors. What the user will do with the downloaded file is out of scope of the question. But the user must safely download and save the file on the local system. Of course, distribute of malware is totally unacceptable. – johnfound Sep 28 '17 at 12:00
  • And how about the user not doing anything with the file by itself but instead making others download the malware directly from your site? And, do you consider the use of assembler part of your architecture which can be considered a problem by itself (low level programming language without the safety net of higher level languages)? – Steffen Ullrich Sep 28 '17 at 12:02
  • 1
    "without single security issue" - that you are aware of. – symcbean Sep 28 '17 at 16:10
  • 1
    You realize that there is an inherent contradiction in these two statements of yours, right: "online for 2 years now without single security issue" vs "there was several bugs mainly with XSS that was reported and fixed quickly after the initial release of the engine." For reference, XSS is one of the more dangerous vulnerabilities out there, right below remote code execution. – Conor Mancone Sep 28 '17 at 17:33
1

The possible vector is a content-range attacks, when you will be asked for a document not from the very beginning of it, it can force you to read all the content into the memory for sending just a byte. So you can hit OOM on server while network and bandwidth payload for the attack is measured in hundreds of bytes

  • "it can force you to read all the content into the memory" - only if the application is written in such a way that it maps the entire file into memory for requests. The webserver should not be affected (both Apache and nginx treat the front and back end connections as streams). – symcbean Sep 28 '17 at 15:54
  • it highly depends on the sotrage: you cant read just a part of the field, and if it is a sigle blob field - HTTP request asks you for one byte from 1000000 to 1000001 - but you have to read it all to extract it - like this curl -i -X GET --header "Range: bytes=1000000-1000001" http://your-app.tld/place-to-get-a-blob-from – Alexey Vesnin Sep 28 '17 at 16:26
0

I will answer with 2 distinct points.

  1. BLOBS

    Blobs are allowed in all major databases, but the quality of their implementation may vary. In fact their require the database to be able to store objects of arbitrary size, which is not the first concern of a relational database. As a result, frequent insertion, deletion or updates of blobs may end in a database using much more space than actually necessary. In addition, the risk of a low level problem in the middle or writing a blob is roughly proportional to the size of the blob and that could result in a damaged database. More of my opinion, but I prefere storing large files directly in a file system (it is its job), and only store names in the database.

  2. Malwares

    You do not directly use the attached files on your platform, but you offer them to your clients. If one of them maliciously or inadvertently uploads a file containing a malware, your platform will be a diffusion vector for that malware. Apart from possible legal problems (but make sure your general conditions are explicit about it), the user experience will certainly be very poor => you should at least scan any incoming file with an up to date anti-virus software.

  • 1. The database is SQLite. But the efficiency of the storage is offtopic actually. 2. The malware can be distributed in totally valid .zip files for example. – johnfound Sep 28 '17 at 12:04
  • @johnfound: 1 it is not only about efficiency but also about robustness (the Availability pilar). For point 2, some (good) antivirus softwares are able to walk down into well known archive formats like zip – Serge Ballesta Sep 28 '17 at 12:14
  • Not if the zips are password protected. :P – johnfound Sep 28 '17 at 12:21
  • @johnfound: Of course! There are 2 common policies for encrypted content: either reject anything you cannot scan, or make clear that you endorse no responsability for encrypted content – Serge Ballesta Sep 28 '17 at 12:52
  • The forum engine is not responsible for the content of the attached files at all. It is responsible only for the security of the transport from the user that attached the file and the user that downloaded the file. No one (the uploader, the downloader, the server and the side parties) should be injured during this process. – johnfound Sep 28 '17 at 13:03

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