Identifying Attackable Data for Reflected and Persistent XSS Attacks

In a reflected XSS attack, the attacker s script is only echoed from the victim s browser through the vulnerable site and back to the victim s browser. Attackers need to identify places where they can coerce victims into sending specific data (script) to the vulnerable Web site. In persistent XSS (script injection) attacks, attackers can send the data to the vulnerable Web site themselves . Persistent XSS enables attackers to send malicious data in data fields the server might look at, but attackers can t coerce victims into sending data to the server. Table 10-1 describes several common data fields that are read by Web servers and whether the field can be used in a reflected and/or persistent XSS attack.

Table 10-1: Common Data Fields Used in XSS Attacks
Data field	Reflected	Persistent	Reason
URL/query string			An attacker can store data in the URL/query string and have the victim send it to the Web server by enticing the user into visiting a link. Attackers cansend the script in the URL in persistent XSS themselves.
POST data			For reflected XSS, attackers can host their own form and force the victim to post the form data (script). For persistent XSS, attackers can simply submit the form themselves.
User-Agent			The User-Agent header and other HTTP headers won t work for reflected XSS unless an attacker is able to set them on the victim s machine. Web browsers don t allow a Web page to set the User-Agent string, so an attacker isn t able to set it for the victim. Windows application programming interfaces (APIs) can be called to make HTTP requests with an arbitrary User-Agent string, but to do this the ability to run a binary on the victim s machine is required. If attackers can do this, they have already compromised the victim s account through some other means. For persistent XSS, the User-Agent can work for attackers because they can make custom requests to get the data stored on the server.
Referer			The Referer field yields mixed results. If the Web application being tested echoes text such as Return to http:// server/page.htm where server/page.htm is the server and page that the user was previously visiting, it might be attackable. The Referer field might seem difficult to attack because often characters such as angle brackets that are illegal characters in server and filenames are required. However, it might be possible to get script to run by using characters that are allowed in a filename, appending a query string that contains script data, or using angle brackets in the server name that uses wildcard Domain Name System (DNS) (discussed in Chapter 6); it s worth trying. For persistent XSS, attackers can use the Referer field because they can make custom requests using a malformed Referer.

Tip

Don t test using the user interface. So far, the examples shown are straightforward and don t modify the data entered into the text input controls. However, some pages might perform some client-side validation of the data typed in. This validation can block the form from being submitted through the UI. Other times, client-side script can modify the values typed into the UI before submitting the form. For example, the programmer might have client-side script to remove all characters except letters in the Name field in the helloPostDemo.asp example. If you test through the UI, you might be misled into believing that script could not be echoed through the target server when it can be. For more information about how to bypass the user interface when testing, please see Chapter 4.

Sometimes More Than the <script> Tag Is Needed

In all of the examples discussed so far, the data sent to the server is just the <script> tag. Sometimes a little more work is necessary to get script running, as the example HelloPost-DemoWithEmail.asp demonstrates . The form asks for the user s name and e-mail address. Attempting to echo the <script> tag for the name as done in earlier examples ( <SCRIPT>alert ('Hi!')</SCRIPT> ) while supplying an e-mail address isn t successful. The data is returned to the browser in the HTML, but it is HTML encoded. Instead of the data <SCRIPT>alert('Hi!') </SCRIPT> being echoed, <SCRIPT>alert('hi')</SCRIPT> is echoed. The browser won t treat this as the <script> tag, so script doesn t run.

What happens if the e-mail address field is left blank, but a name is specified? After the data is submitted, the form is displayed again, but the Name field is prepopulated with the value originally submitted with the form. By performing the test case of submitting only one field, you can echo data through the form by leaving the Email field blank. However, attempting to submit script as in previous examples still doesn t run script. The HTML source returned to the Web browser is the following:

 <html><head><title>Hello Post Demo</title> <META http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body>  <form method="POST" name="myForm">  Name: <input type="text" name="myName" value="<SCRIPT>alert('hi')</SCRIPT>"><br>  Email: <input type="text" name="myEmail" value=""><br>  <input type="submit" value="Submit">  </form> </body> </html>

The data isn t HTML encoded, but why didn t the script run? The script is being used as the value of the <input> tag s Value property. To run script the input data must be viewed as an HTML tag. To get the data to be viewed as script, the input must include a closing set of quotation marks and close the <input> tag. Do this by starting the data with " > and following it with the <script> tag. The resulting URL will look like this: http://localhost/HelloPostDemoWithEmail.asp?myName=" >< SCRIPT > alert('Hi!') </ SCRIPT >& myEmail= . This successfully runs script.

Tip

Don t forget to test to see how error cases are handled. Many form applications notice when not all required fields are sent to the server on an incompletely filled-out form. The server will then display the form again, but this time with the previously sent values already populated in the form. This allows an additional code path to test for XSS.