Seven Deadliest Web Application Attacksby Mike Shema
Seven Deadliest Wireless Technologies Attacks draws attention to the vagaries of Web security by discussing the seven deadliest vulnerabilities exploited by attackers. Each chapter presents examples of different attacks conducted against Web sites. The methodology behind the attack is explored, showing its potential impact. Then, the chapter moves on to address possible countermeasures for different aspects of the attack.
The book consists of seven chapters that cover the following: the most pervasive and easily exploited vulnerabilities in Web sites and Web browsers; Structured Query Language (SQL) injection attacks; mistakes of server administrators that expose the Web site to attack; brute force attacks; and logic attacks. The ways in which malicious software malware has been growing as a threat on the Web are also discussed.
This book is intended for anyone who uses the Web to check e-mail, shop, or work. Web application developers and security professionals will benefit from the technical details and methodology behind the Web attacks covered in this book. Executive level management will benefit from understanding the threats to a Web site, and in many cases, how a simple attack requiring nothing more than a Web browser can severely impact a site.
- Knowledge is power, find out about the most dominant attacks currently waging war on computers and networks globally
- Discover the best ways to defend against these vicious attacks; step-by-step instruction shows you how
- Institute countermeasures, don’t be caught defenseless again, and learn techniques to make your computer and network impenetrable
- Elsevier Science
- Publication date:
- Sold by:
- Barnes & Noble
- NOOK Book
- File size:
- 807 KB
Read an Excerpt
Seven Deadliest Web Application Attacks
By Mike Shema
SYNGRESSCopyright © 2010 Elsevier Inc.
All right reserved.
Chapter OneCross-Site Scripting
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]
Meet the Author
Mike Shema develops web application security solutions at Qualys, Inc. His current work is focused on an automated web assessment service. Mike previously worked as a security consultant and trainer for Foundstone where he conducted information security assessments across a range of industries and technologies. His security background ranges from network penetration testing, wireless security, code review, and web security. He is the co-author of Hacking Exposed: Web Applications, The Anti-Hacker Toolkit and the author of Hack Notes: Web Application Security. In addition to writing, Mike has presented at security conferences in the U.S., Europe, and Asia.
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >