Seven Deadliest Web Application Attacks [NOOK Book]

Overview

Do you need to keep up with the latest hacks, attacks, and exploits effecting web applications? Then you need Seven Deadliest Web Application Attacks. This book pinpoints the most dangerous hacks and exploits specific to web applications, laying out the anatomy of these attacks including how to make your system more secure. You will discover the best ways to defend against these vicious hacks with step-by-step instruction and learn techniques ...
See more details below
Seven Deadliest Web Application Attacks

Available on NOOK devices and apps  
  • NOOK Devices
  • NOOK HD/HD+ Tablet
  • NOOK
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK Study
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
$24.95
BN.com price

Overview

Do you need to keep up with the latest hacks, attacks, and exploits effecting web applications? Then you need Seven Deadliest Web Application Attacks. This book pinpoints the most dangerous hacks and exploits specific to web applications, laying out the anatomy of these attacks including how to make your system more secure. You will discover the best ways to defend against these vicious hacks with step-by-step instruction and learn techniques to make your computer and network impenetrable.

Attacks detailed in this book include:

  1. Cross-Site Scripting (XSS)
  2. Cross-Site Request Forgery (CSRF)
  3. SQL Injection
  4. Server Misconfiguration and Predictable Pages
  5. Breaking Authentication Schemes
  6. Logic Attacks
  7. Malware and Browser Attacks


  • 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
Read More Show Less

Editorial Reviews

From the Publisher
"The threats highlighted should be understood by web developers, administrators and general users alike. If you use the web in any way then this should be on your bookshelf. In addition to the detailing the threat Shema also provides countermeasures to minimise or remove the risk, but be warned; you may never look at a website the same way again." - Andrew Waite, Security Researcher, InfoSanity Research
Read More Show Less

Product Details

  • ISBN-13: 9781597495448
  • Publisher: Elsevier Science
  • Publication date: 2/20/2010
  • Sold by: Barnes & Noble
  • Format: eBook
  • Edition number: 1
  • Pages: 192
  • File size: 788 KB

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.

Read More Show Less

Read an Excerpt

Seven Deadliest Web Application Attacks


By Mike Shema

SYNGRESS

Copyright © 2010 Elsevier Inc.
All right reserved.

ISBN: 978-1-59749-544-8


Chapter One

Cross-Site Scripting

INFORMATION IN THIS CHAPTER

• Understanding HTML Injection

• Employing Countermeasures

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.

These Spiders' parlors also exist at sites typically assumed to be safe: social networking, well-established online shopping, Web-based e-mail, news, sports, entertainment, and more. Although such sites do not encourage visitors to download and execute untrusted virus-laden programs, they serve content to the browser. The browser blindly executes this content, a mix of Hypertext Markup Language (HTML) and JavaScript, to perform all sorts of activities. If you're lucky, the browser shows the next message in your inbox or displays the current balance of your bank account. If you're really lucky, the browser isn't siphoning your password to a server in some other country or executing money transfers in the background.

In October 2005, a user logged in to MySpace and checked out someone else's profile. The browser, executing JavaScript code it encountered on the page, automatically updated the user's own profile to declare someone named Samy their hero. Then a friend viewed that user's profile and agreed on his own profile that Samy was indeed "my hero." Then another friend, who had neither heard of nor met Samy, visited MySpace and added the same declaration. This pattern continued with such explosive growth that 24 hours later, Samy had over one million friends, and MySpace was melting down from the traffic. Samy had crafted a cross-site scripting (XSS) attack that, with approximately 4,000 characters of text, caused a denial of service against a company whose servers numbered in the thousands and whose valuation at the time flirted around $500 million. The attack also enshrined Samy as the reference point for the mass effect of XSS. (An interview with the creator of Samy can be found at http://blogoscoped.com/archive/2005-10-14-n81.html.)

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

XSS can be more generally, although less excitingly, described as HTML injection. The more popular name belies the fact that successful attacks need not cross sites or domains and need not consist of JavaScript to be effective.

An XSS attack rewrites the structure of a Web page or executes arbitrary JavaScript within the victim's Web browser. This occurs when a Web site takes some piece of information from the user – an e-mail address, a user ID, a comment to a blog post, a zip code, and so on – and displays the information in a Web page. If the Web site is not careful, then the meaning of the HTML document can be disrupted by a carefully crafted string.

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.

matches for "<span id="ctl00_body_ctl00_lblSearchString"> living dead</span>" ... lots of HTML here... <script type="text/javascript"><!- ggl_ad_client = "pub-6655321"; ggl_ad_width = 468; ggl_ad_height = 60; ggl_ad_format = "468x60_as"; ggl_ad_channel ="; ggl_hints = "living dead"; //-> </SCRIPT>

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>"

If the Web site will echo anything we type in the search box, what might happen if a more complicated phrase were used? Figure 1.2 shows what happens when JavaScript is entered directly into the search.

By breaking down the search phrase, we see how the page was rewritten to convey a very different message to the Web browser than the Web site's developers intended. The HTML language is a set of grammar and syntax rules that inform the browser how to interpret pieces of the page. The rendered page is referred to as the Document Object Model (DOM). The use of quotes and angle brackets enabled the attacker to change the page's grammar to add a JavaScript element with code that launched a pop-up window. This happened because the phrase was placed directly in line with the rest of the HTML content.

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.

<meta name="description" content="Cheap DVDs. Search results for living dead"/> close content attribute with a quote, close the meta element with /> <script> ... </SCRIPT> add some arbitrary JavaScript <meta name=" create an empty meta element to prevent the browser from displaying the dangling "/> from the original <meta description ... element " />

The ggl_hints parameter in the ad banner script element can be similarly manipulated. Yet, in this case, the payload already appears inside a script element, so the attacker needs only to insert valid JavaScript code to exploit the Web site. No new elements needed to be added to the DOM for this attack. Even if the developers had been savvy enough to blacklist <script> tags or any element with angle brackets, the attack would have still succeeded.

<script type="text/javascript"><!- ggl_ad_client = "pub-6655321"; ggl_ad_width = 468; ggl_ad_height = 60; ggl_ad_format = "468x60_as"; ggl_ad_channel ="; ggl_hints = "living dead"; close the ggl_hints string with"; ggl_ad_client="pub-attacker"; override the ad_client to give the attacker credit function nefarious() { } perhaps add some other function foo=" create a dummy variable to catch the final "; "; //-> </SCRIPT>

Each of the previous examples demonstrated an important aspect of XSS attacks: the location on the page where the payload is echoed influences what characters are necessary to implement the attack. In some cases, new elements can be created, such as <script> or <iframe>. In other cases, an element's attribute might be modified. If the payload shows up within a JavaScript variable, then the payload need only consist of code.

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.

Alas, this chapter is far too brief to provide a detailed investigation of all XSS attack techniques. One in particular deserves mention among the focus on inserting JavaScript code and creating HTML elements, but is addressed here only briefly: Cascading Style Sheets (CSS). Cascading Style Sheets, abbreviated CSS and not to be confused with this attack's abbreviation, control the layout of a Web site for various media. A Web page could be resized or modified depending on whether it's being rendered in a browser, a mobile phone, or sent to a printer. Clever use of CSS can attain much of the same outcomes as a JavaScript-based attack. In 2006, MySpace suffered a CSS-based attack that tricked victims into divulging their passwords (www.caughq.org/advisories/CAU-2006-0001.txt). Other detailed examples can be found at http://p42.us/css/.

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]

Read More Show Less

Table of Contents

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

Read More Show Less

Customer Reviews

Average Rating 5
( 1 )
Rating Distribution

5 Star

(1)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted May 13, 2011

    No text was provided for this review.

Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)