I'm testing a particular vulnerability box since yesterday and I came with one rather strange problem that I didn't expect. Lets say a vulnerable web-application offer image file upload.
The image actually doesn't have to be image, the back-end accept any file exstension. The problem is, same back-end always returns *.jpg
so instead of uploaded evil.php
script, you come up with random_number.jpg
.
Of course, the first thing I've tried is getting the served response, which in this case is base64-encoded image data.
Looking further, I've found that the application returns binary/octet-stream
as a Content-type response header which means when I try to access the URL http://localhost/vulnbox/uploaded/random_num.jpg
, the browser opens file download message. The actual file is returned as binary, ready to be downloaded, yet looking into the file, I see that the code stays in.
Is there a way I can force response of Content-type to any other and get actual evil script ran?
Accept
header totext/html
as part of the content negotiation. Whether the server will actually reply differently depends on its configuration, though.format=xml
or similar. If that works, you can probably XSS the site by uploading HTML and then requesting it with the parameter set to give it to you as XML.crossdomain.xml
or similar). Also, you can make Flashplayer ignore the Content-Type header of the server response, so long as the server doesn't also setContent-Type-Options: nosniff
(maybeX-
prefixed). Upload a malicious SWF, load another site with<object type="application/x-shockwave-flash" data="*uploadurl*" />