XSS in Content-Disposition

Question

Lets assume i have found a xss on site example.com, now to trigger an XSS, i use the following URL:

https://example.com/a.php?v=%22%3E%3Cimg%20src=x

Which results in following response:

HTTP/1.1 500 Internal Server Error
Server: nginx
Date: Mon, 27 Jul 2015 02:15:23 GMT
Content-Type: text/html;
Content-Length: 44
Connection: keep-alive
Strict-Transport-Security: max-age=31557600; includeSubdomains;
X-Permitted-Cross-Domain-Policies: master-only
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Security-Policy: sandbox
Content-Disposition: attachment

"><img src=x

Does this pose a security risk considering XSS protection is enabled and also the CSP sandbox and content-disposition attachment mitigates this so that even if injection was successful, code will not execute for XSS.

Answer 1

Yes this still poses a security risk.

From what I understand this header is only used by IE 8 and newer tell the browser to use it's built in XSS filtering. Even if modern versions of other browsers user it, there are certainly older browsers that do not. In addition - I would not trust IE's built in XSS protection to keep anyone safe.

If preventing XSS were this simple XSS would not be a thing.

UPDATE:

Regarding the Content-Disposition: Attachment this will make XSS more difficult, but it seems like there are still a few ways to get around this:

• https://web.archive.org/web/20100812171626/http://i8jesus.com/?p=64
• https://sirdarckcat.blogspot.com/2007/12/bypassing-content-disposition.html
• https://bugzilla.mozilla.org/show_bug.cgi?id=392459

Even if it is not exploitable in it's current state I would still say that this is a very bad security practice. It would leave the site in a position where a seemingly minor code change in the future could open things up to an XSS vulnerability

Answer 2

Not in that context, but if you can achieve HTTP header injection, it might be possible.

From my blog post:

Injecting the content-type text/html\r\n\r\n into a file upload, caused the download to be rendered in HTTP as:

HTTP/1.1 200 OK
Date: Mon, 16 Apr 2018 17:34:21 GMT
Expires: Thu, 26 Oct 1978 00:00:00 GMT
Content-Type: text/html

Cache-Control: no-store, no-cache, must-revalidate, max-age=0
X-Content-Type-Options: nosniff
Content-Length: 39
Vary: *
Connection: Close
content-disposition: attachment;filename=xss.htm
X-Frame-Options: SAMEORIGIN

<script>alert(document.domain)</script>

Bypassing the content-disposition header inserted by the application as the header has been transposed into the HTTP body.