- Shopping Bag ( 0 items )
INFORMATION IN THIS CHAPTER
Understanding HTML Injection
When the Spider invited the Fly into his parlor, the Fly at first declined with the wariness of prey confronting its predator. The Internet is rife with traps, murky corners, and malicious hosts that make casually surfing random Web sites a dangerous proposition. Some areas are, if not obviously dangerous, at least highly suspicious. Web sites offering warez (pirated software), free porn, or pirated music tend to be laden with viruses and malicious software waiting for the next insecure browser to visit.
How often have you encountered a prompt to reauthenticate to a Web site? Have you used Web-based e-mail? Checked your bank account online? Sent a tweet? Friended someone? There are examples of XSS vulnerabilities for every one of these Web sites.
XSS isn't always so benign that it acts merely as a nuisance for the user. (Taking down a Web site is more than a nuisance for the site's operators.) It is also used to download keyloggers that capture banking and online gaming credentials. It is used to capture browser cookies to access victims' accounts with the need for a username or password. In many ways, it serves as the stepping stone for very simple, yet very dangerous attacks against anyone who uses a Web browser.
UNDERSTANDING HTML INJECTION
For example, consider the search function of an online store. Visitors to the site are expected to search for their favorite book, movie, or pastel-colored squid pillow, and if the item exists, they purchase it. If the visitor searches for DVD titles that contain living dead, the phrase might show up in several places in the HTML source. Here, it appears in a meta tag.
[UNABLE TO REPRODUCE CHARACTER STRING IN ASCII] <meta name="description" content="Cheap DVDs. Search results for living dead" /> <meta name="keywords" content="dvds,cheap,prices" /><title>
However, later the phrase may be displayed for the visitor at the top of the search results, and then near the bottom of the HTML inside a script element that creates an ad banner.
XSS comes in to play when the visitor can use characters normally reserved for HTML markup as part of the search query. Imagine if the visitor appends a double quote (") to the phrase. Compare how the browser renders the results of the two different queries in each of the windows in Figure 1.1.
Note that the first result matched several titles in the site's database, but the second search reported "No matches found" and displayed some guesses for a close match. This happened because living dead" (with quote) was included in the database query and no titles existed that ended with a quote. Examining the HTML source of the response confirms that the quote was preserved:
matches for "<span id="ctl00_body_ctl00_lblSearchString"> living dead"</span>"
matches for "<span id="ctl00_body_ctl00_lblSearchString"> living dead<script>alert("They're coming to get you, Barbara.") </SCRIPT></span>"
Instead of displaying <script>alert ... as text like it does for the words living dead, the browser sees the <script> tag as the beginning of a code block and renders it as such. Consequently, the attacker is able to arbitrarily change the content of the Web page by manipulating the DOM.
Before we delve too deeply into what an attack might look like, let's see what happens to the phrase when it appears in the meta tag and ad banner. Here is the meta tag when the phrase living dead" is used:
<meta name="description" content="Cheap DVDs. Search results for living dead"" />
The quote character has been rewritten to its HTML-encoded version – " – which browsers know to display as the " symbol. This encoding preserves the syntax of the meta tag and the DOM in general. Otherwise, the syntax of the meta tag would have been slightly different:
<meta name="description" content="Cheap DVDs. Search results for living dead" />
This lands an innocuous pair of quotes inside the element and most browsers will be able to recover from the apparent typo. On the other hand, if the search phrase is echoed verbatim in the meta element's content attribute, then the attacker has a delivery point for an XSS payload:
<meta name="description" content="Cheap DVDs. Search results for living dead"/> <script>alert("They're coming to get you, Barbara.")</SCRIPT> <meta name=" />
Here's a more clearly annotated version of the XSS payload. Note how the syntax and grammar of the HTML page have been changed. The first meta element is properly closed, a script element follows, and a second meta element is added to maintain the validity of the HTML.
Pop-up windows are a trite example of XSS. More vicious payloads have been demonstrated to
Steal cookies so attackers can impersonate victims without having to steal passwords
Spoof login prompts to steal passwords (attackers like to cover all the angles)
Capture keystrokes for banking, e-mail, and game Web sites
Use the browser to port scan a local area network
Surreptitiously reconfigure a home router to drop its firewall
Automatically add random people to your social network
Lay the groundwork for a cross-site request forgery (CSRF) attack
Regardless of what the actual payload is trying to accomplish, all forms of the XSS attack rely on the ability of a user-supplied bit of information to be rendered in the site's Web page such that the DOM structure will be modified. Keep in mind that changing the HTML means that the Web site is merely the penultimate victim of the attack. The Web site acts as a broker that carries the payload from the attacker to the Web browser of anyone who visits it.
Identifying Points of Injection
The Web browser is not to be trusted. Obvious sources of attack may be links or form fields. Yet, all data from the Web browser should be considered tainted. Just because a value is not evident, such as the User-Agent header that identifies every type of browser, it does not mean that the value cannot be modified by a malicious user. If the Web application uses some piece of information from the browser, then that information is a potential injection point regardless of whether the value is assumed to be supplied manually by a human or automatically by the browser.
Uniform Resource Identifier Components
Any portion of the Uniform Resource Identifier (URI) can be manipulated for XSS. Directory names, file names, and parameter name/value pairs will all be interpreted by the Web server in some manner. The URI parameters may be the most obvious area of concern. We've already seen what may happen if the search parameter contains an XSS payload. The URI is dangerous even when it might be invalid, point to a nonexistent page, or have no bearing on the Web site's logic. If the Web site echos the link in a page, then it has the potential to be exploited. For example, a site might display the URI if it can't find the location the link was pointing to.
Oops! We couldn't find [UNABLE TO REPRODUCE CHARACTER STRING IN ASCII]. Please return to our [UNABLE TO REPRODUCE CHARACTER STRING IN ASCII]
Introduction Chapter 1. Cross-Site Scripting (XSS) Chapter 2. Cross-Site Request Forgery (CSRF) Chapter 3. SQL Injection Chapter 4. Server Misconfiguration and Predictable Pages Chapter 5. Breaking Authentication Schemes Chapter 6. Logic Attacks Chapter 7. Web of Distrust
Posted May 13, 2011
No text was provided for this review.