4

I am testing web application which allows to upload files in every format without any restrictions. There is also a function to download uploaded files but when I download file it is returned with header:

Content-disposition: attachment; filename=test.html

so it will not open in browser.

How this vulnerability can be exploited? Is it possible to use this bug to execute XSS?

Without this header it will open in the browser so it would be enough to upload html file containing script, is it possible to perform similar attack in this case?

3

I think the only thing you should keep in mind is that, while the header forces the browser to download the file, this doesn't prevent the asset from being included inside an actual page if a malicious user finds a way to inject it. As a for instance, if the download URL was something like this:

http://example.com/download/{user_file_id}

And the server let references to it be injected directly into another page:

<script src="http://example.com/download/{user_file_id}"></script>

It would still execute as normal javascript, regardless of the content-disposition or just about any other header. I'm guessing there is no good reason why the application directly injects uploaded files as javascript, in which case the risk of it compromising the server seems minimal.

There is, however, a minor increased risk of compromise to other user's on the server. If a malicious user finds a way to perform XSS injection on the website, the ability to host their javascript payload on the server itself would additionally allow them to circumvent any protection from any CSP settings. As a result, XSS injection becomes more dangerous.

In reality though the biggest risk (from what I understand about the system you have described) is probably legal issues (note: IANAL). If anyone can upload anything to the server, I imagine there are potential legal concerns to be aware of. The server you describe could effectively be used to distribute any information/files/content desired by anyone who has access to it: especially if the service doesn't require authentication. What if happens if someone decides to use it to distribute child pornography? That's an extreme example, but sometimes such things are unfortunately relevant, and there are plenty of less extreme examples that still cause problems.

7

If it is an Apache server, you might be able to upload a .htaccess file, enabling you to establish directory listings or specifying file extensions to run like php, jsp, py or whatever the server is able to understand.

From there, you will be able to upload a webshell or something else.

By way of .htaccess configuration, you may be able to change the server's behavior toward the uploaded files and bypass that attachment header imposition.

In this GitHub repo you will find some .htaccess-based attacks like shells, RCE, traversals, etc.

  • 4
    Those are good ones. My own personal rules for managing uploads is to always store them off server or in a non-public directory. Also, always rename the files and set an appropriate extension based off the (real) mime type. The next step is to switch out apache for nginx :p – Conor Mancone Sep 27 '17 at 22:17
2

From my understanding, it is not possible to force the server to run the code that you have uploaded due to the header being set server side. However given you can upload anywhere code you want, it may be worth seeing if you can view this file anywhere else whereby the code my actually be ran rather than downloaded.

The only possible method that could potentially work is by injecting via the attachments file name itself e.g. similar to header injection. The "What is file download injection" of the following link might be useful: https://dl.packetstormsecurity.net/papers/attack/Aspect_File_Download_Injection.pdf

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.