the-web-application-hackers-handbook

478 Chapter 12 n Attacking Users: Cross-Site Scripting
The only significant caveat to using this technique is that the resulting request
will contain the following header:
Content-Type: text/plain
The original request normally would have contained a different Content-Type
header, depending on exactly how it was generated. If the application tolerates
the supplied Content-Type header and processes the message body in the normal
way, the technique can be used successfully when trying to develop a working
XSS exploit. If the application fails to process the request in the normal way, on
account of the modified Content-Type header, there may be no way to send a
suitable cross-domain request to trigger the XSS-like behavior.
TIP If you identify XSS-like behavior in a request that contains nonstandard
content, the first thing you should do is quickly verify whether the behavior
remains when you change the Content-Type header to text/plain. If it
does not, it may not be worth investing any further effort in trying to develop
a working XSS exploit.
Executing JavaScript from Within XML Responses
The second challenge to overcome when attempting to exploit XSS-like behavior
in nonstandard content is to find a way of manipulating the response so
that it executes your script when consumed directly by the browser. If the
response contains an inaccurate Content-Type header, or none at all, or if your
input is being reflected right at the start of the response body, this task may be
straightforward.
Usually, however, the response includes a Content-Type header that accurately
describes the type of data that the application returns. Furthermore, your
input typically is reflected partway through the response, and the bulk of the
response before and after this point will contain data that complies with the
relevant specifications for the stated content type. Different browsers take different
approaches to parsing content. Some simply trust the Content-Type header,
and others inspect the content itself and are willing to override the stated type
if the actual type appears different. In this situation, however, either approach
makes it highly unlikely that the browser will process the response as HTML.
If it is possible to construct a response that does succeed in executing a script, this
normally involves exploiting some particular syntactic feature of the type of content
that is being injected into. Fortunately, in the case of XML, this can be achieved by
using XML markup to define a new namespace that is mapped to XHTML, causing
the browser to parse uses of that namespace as HTML. For example, when Firefox
processes the following response, the injected script is executed:
HTTP/1.1 200 Ok
Content-Type: text/xml