This question already has an answer here:

So I've been doing a red team exercise and one internal app echos back Cannot find /whatever/your/path. Since this is not a PHP or even fully featured web server there is no magical automatic decoding so if you send in /%00%0d%25/stuff you'll get Cannot find /%00%0d%25/stuff

The issue is that every single browser in recent history either automatically encodes < or > or is intelligent enough to not render the non-HTML page (since there's no HTML tags it interprets the string into a renderable context) as HTML. I've tested every browser that we currently have in operation and not a single one has generated an XSS condition because they either correctly encoded the URL and any parameters or escaped the non-HTML document so that it can be rendered as seemingly plaintext.

Am I right to assume that unless combined with another far more significant vulnerability this is unexploitable unless you happen to be running Netscape 1.0 or some other equally poor (and unapproved) browser?

marked as duplicate by Arminius, Steffen Ullrich, TheJulyPlot, Rory Alsop Aug 14 '17 at 14:31

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • @Arminius that appears to answer the first part (is any current browser vulnerable) but there still remains the bit of is it possible to change the way the browser guesses the content type when a header isn't returned. – Sirens Aug 13 '17 at 1:51
  • @Sirens: instead of adding an essentially new question to an existing one because the existing one was correctly marked as duplicate you should ask your new question in a new question, not in an edit. – Steffen Ullrich Aug 13 '17 at 6:24
  • @SteffenUllrich your wish is my command – Sirens Aug 13 '17 at 6:33

Browsers interprets pages as HTML when the HTTP response headers contains "Content-Type: text/html".

If the response contains "Content-Type: text/plain", then the text is interpreted as plain text and the text will be displayed as is, no HTML interpretation will be done to the text.

  • That wasn't really the question, I was wondering if there is a way to get a browser to send characters as part of a URL without encoding them – Sirens Aug 13 '17 at 6:34

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