the-web-application-hackers-handbook

Chapter 12 n Attacking Users: Cross-Site Scripting 435
Sure enough, when the page is rendered within the user’s browser, the popup
message appears, as shown in Figure 12-2.
Figure 12-2: A proof-of-concept XSS exploit
Performing this simple test serves verifies two important things. First, the
contents of the message parameter can be replaced with arbitrary data that gets
returned to the browser. Second, whatever processing the server-side application
is performing on this data (if any), it is insufficient to prevent us from supplying
JavaScript code that is executed when the page is displayed in the browser.
TRY IT!
http://mdsec.net/error/5/
NOTE If you try examples like this in Internet Explorer, the pop-up may fail to
appear, and the browser may show the message “Internet Explorer has modified
this page to help prevent cross-site scripting.” This is because recent versions
of Internet Explorer contain a built-in mechanism designed to protect
users against reflected XSS vulnerabilities. If you want to test these examples,
you can try a different browser that does not use this protection, or you can disable
the XSS filter by going to Tools ÿ Internet Options ÿ Security ÿ Custom
Level. Under Enable XSS filter, select Disable. We will describe how the XSS filter
works, and ways in which it can be circumvented, later in this chapter.
This type of simple XSS bug accounts for approximately 75% of the XSS
vulnerabilities that exist in real-world web applications. It is called reflected
XSS because exploiting the vulnerability involves crafting a request containing
embedded JavaScript that is reflected to any user who makes the request. The
attack payload is delivered and executed via a single request and response. For
this reason, it is also sometimes called first-order XSS.