the-web-application-hackers-handbook

Chapter 12 n Attacking Users: Cross-Site Scripting 487
HTML can be embedded in various locations within a valid image file, including
the comment section of the image. Several browsers, including Firefox and
Safari, happily render an image file as HTML. The binary parts of the image
are displayed as junk, and any embedded HTML is displayed in the usual way.
TIP Suppose a potential victim is using an HTML5-compliant browser, where
cross-domain Ajax requests are possible with the permission of the requested
domain. Another possible attack in this situation would be to place an absolute
URL after the fragment character, specifying an external HTML file that
the attacker fully controls, on a server that allows Ajax interaction from the
domain being targeted. If the client-side script does not validate that the URL
being requested is on the same domain, the client-side remote file inclusion
attack succeeds.
Because this validation of the URL’s domain would have been unnecessary
in older versions of HTML, this is one example where the changes introduced
in HTML5 may themselves introduce exploitable conditions into existing applications
that were previously secure.
Finding and Exploiting DOM-Based XSS Vulnerabilities
DOM-based XSS vulnerabilities cannot be identified by submitting a unique string
as each parameter and monitoring responses for the appearance of that string.
One basic method for identifying DOM-based XSS bugs is to manually walk
through the application with your browser and modify each URL parameter to
contain a standard test string, such as one of the following:
“alert(1)
“;alert(1)//
‘-alert(1)-’
By actually displaying each returned page in your browser, you cause all
client-side scripts to execute, referencing your modified URL parameter where
applicable. Any time a dialog box appears containing your cookies, you will
have found a vulnerability (which may be due to DOM-based or other forms
of XSS). This process could even be automated by a tool that implemented its
own JavaScript interpreter.
However, this basic approach does not identify all DOM-based XSS bugs.
As you have seen, the precise syntax required to inject valid JavaScript into an
HTML document depends on the syntax that already appears before and after
the point where the user-controllable string gets inserted. It may be necessary to
terminate a single- or double-quoted string or to close specific tags. Sometimes
new tags may be required, but sometimes not. Client-side application code may
attempt to validate data retrieved from the DOM, and yet may still be vulnerable.