How can an information security professional keep up with all of the hacks, attacks, and exploits on the Web? One way is to read Hacking Web Apps. The content for this book has been selected by author Mike Shema to make sure that we are covering the most vicious attacks out there. Not only does Mike let you in on the anatomy of these attacks, but he also tells you how to get rid of these worms, trojans, and botnets and how to defend against them in the future. Countermeasures are detailed so that you can fight against similar attacks as they evolve.
Attacks featured in this book include:
• SQL Injection
• Cross Site Scripting
• Logic Attacks
• Server Misconfigurations
• Predictable Pages
• Web of Distrust
• Breaking Authentication Schemes
• HTML5 Security Breaches
• Attacks on Mobile Apps
Even if you don’t develop web sites or write HTML, Hacking Web Apps can still help you learn how sites are attackedas well as the best way to defend against these attacks. Plus, Hacking Web Apps gives you detailed steps to make the web browser – sometimes your last line of defense – more secure.
- More and more data, from finances to photos, is moving into web applications. How much can you trust that data to be accessible from a web browser anywhere and safe at the same time?
- Some of the most damaging hacks to a web site can be executed with nothing more than a web browser and a little knowledge of HTML.
- Learn about the most common threats and how to stop them, including HTML Injection, XSS, Cross Site Request Forgery, SQL Injection, Breaking Authentication Schemes, Logic Attacks, Web of Distrust, Browser Hacks and many more.
|Product dimensions:||7.40(w) x 9.20(h) x 0.70(d)|
About 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 an Excerpt
Hacking Web Apps
Detecting and Preventing Web Application Security Problems
By Mike Shema
Elsevier ScienceCopyright © 2012 Elsevier, Inc.
All rights reserved.
Mike Shema 487 Hill Street, San Francisco, CA 94114, USA
INFORMATION IN THIS CHAPTER:
What's New in HTML5
Security Considerations for Using and Abusing HTML5
Written language dates back at least 5000 years to the Sumerians, who used cuneiform for things like ledgers, laws, and lists. That original Stone Markup Language carved the way to our modern HyperText Markup Language. And what's a site like Wikipedia but a collection of byzantine editing laws and lists of Buffy episodes and Star Trek aliens? We humans enjoy recording all kinds of information with written languages.
HTML largely grew as a standard based on de facto implementations. What some (rarely most) browsers did defined what HTML was. This meant that the standard represented a degree of real world; if you wrote web pages according to spec, then browsers would probably render it as you desired probably. The drawback of the standard's early evolutionary development was that pages weren't as universal as they should be. Different browsers had different quirks, which led to footnotes like, "Best viewed in Internet Explorer 4" or "Best viewed in Mosaic." Quirks also created programming nightmares for developers, leading to poor design patterns (the ever-present User-Agent sniffing to determine capabilities as opposed to feature testing) or over-reliance on plugins (remember Shockwave?). The standard also had its own dusty corners with rarely used tags (<acronym>), poor UI design (<frame> and <frameset>) or outright annoying ones (<bgsound> and <marquee>). HTML2 tried to clarify certain variances. It became a standard in November 1995. HTML3 failed to coalesce into something acceptable. HTML4 arrived December 1999.
Eight years passed before HTML5 appeared as a public draft. It took another year or so to gain traction. Now, close to 12years after HTML4 the latest version of the standard is preparing to exit draft state and become official. Those intervening 12years saw the web become an ubiquitous part of daily life. From the first TV commercial to include a website URL to billion-dollar IPOs to darker aspects like scams and crime that will follow any technology or cultural shift.
This chapter covers the new concepts, concerns, and cares for HTML5 and its related standards. Those wishing to find the quick attacks or trivial exploits against the design of these subsequent standards will be disappointed. The modern security ecosphere of browser developers, site developers, and security testers has given careful attention to HTML5.A non-scientific comparison of HTML4 and HTML5 observes that the words security and privacy appear 14 times and once respectively in the HTML4 standard. The same words appear 73 and 12 times in a current draft of HTML5. While it's hard to argue more mentions means more security, it highlights the fact that security and privacy have attained more attention and importance in the standards process.
The new standard does not solve all possible security problems for the browser. What it does is reduce the ambiguous behavior of previous generations, provide more guidance on secure practices, establish stricter rules for parsing HTML, and introduce new features without weakening the browser. The benefit will be a better browsing experience. The drawback will be implementation errors and bugs as browsers compete to add support for features and site developers adopt them.
THE NEW DOCUMENT OBJECT MODEL (DOM)
Welcome to <!doctype html>. That simple declaration makes a web page officially HTML5. The W3C provides a document that describes large differences between HTML5 and HTML4 at http://www.w3.org/TR/html5-diff/. The following list highlights interesting changes:
<!doctypehtml> is all you need. Modern browsers take this as an instruction to adopt a standards mode for interpreting HTML. Gone are the days of arguments of HTML vs. XHTML and adding DTDs to the doctype declaration.
UTF-8 becomes the preferred encoding. This encoding is the friendliest to HTTP transport while being able to maintain compatibility with most language representations. Be on the lookout for security errors due to character conversions to and from UTF-8.
HTML parsing has explicit rules. No more relying on or being thwarted by a browser's implementation quirks. Quirks lead to ambiguity which leads to insecurity. Clear instructions on handling invalid characters (like NULL bytes) or unterminated tags reduce the chances of a browser "fixing up" HTML to the point where an HTML injection vulnerability becomes easily exploitable.
New tags and attributes spell doom for security filters that rely on blacklists. All that careful attention to every tag listed in the HTML4 specification needs to catch up with HTML5.
Increased complexity implies decreased security; it's harder to catch corner cases and pathological situations that expose vulnerabilities.
New APIs for everything from media elements to base 64 conversion to registering custom protocol handlers. This speaks to the complexity of implementation that may introduce bugs in the browser.
Specific issues are covered in this chapter and others throughout the book.
CROSS-ORIGIN RESOURCE SHARING (CORS)
One of the browser's workhorses for producing requests is the XMLHttpRequest (XHR) object. The XHR object is a recurring item throughout this book. Two of its main features, the ability of make asynchronous background requests and the ability to use non-GET methods, make it a key component of exploits. As a consequence, browsers have increasingly limited the XHR's capabilities in order to reduce its adverse security exposure. With CORS, web developers can stretch those limits without unduly putting browsers at risk.
The security boundaries of cross-origin resources are established by request and response headers. The browser has three request headers (we'll cover the preflight concept after introducing all of the headers):
Access-Control-Request-Method—Used in a preflight request to determine if the server will honor the method(s) the XHR object wishes to use. For example, a browser might only need to rely on GET for one web application, but require a range of methods for a REST-ful web site. Thus, a web site may enforce a "least privileges" concept on the browser whereby it honors only those methods it deems necessary.
The server has five response headers that instruct the browser what to permit in terms of sharing access to the data of a response to a cross-origin request:
Access-Control-Allow-Credentials—May be "true" or "false." By default, the browser will not submit cookies, HTTP authentication (e.g. Basic, Digest, NTLM) strings, or client SSL certificates across origins. This restriction prevents malicious content from attempting to leak the credentials to an unapproved origin. Setting this header to true allows any data in this credential category to be shared across origins.
Access-Control-Allow-Headers—The headers a request may include. There are immutable headers, such as Host and Origin. This applies to headers like Content-Type as well as custom X-headers.
Access-Control-Allow-Methods—The methods a request may use to obtain the resource. Always prefer to limit methods to only those deemed necessary, which is usually just GET.
Access-Control-Allow-Origin—The origin(s) with which the server permits the browser to share the server's response data. This may be an explicit origin (e.g. http://other.site), * (e.g. a wildcard to match any origin, or "null" (to deny requests). The wildcard (*) always prevents credentials from bring included with a cross-origin request, regardless of the aforementioned Access-Control-Allow-Credentials header.
Access-Control-Max-Age—The duration in seconds for which the response to a preflight request may be cached. Shorter times incur more overhead as the browser is forced to renew its CORS permissions with a new preflight request. Longer times increase the potential exposure of overly permissive controls from a preflight request. This is a policy decision for web developers. A good reference for this value would be the amount of time the web application maintains a user's session without requiring re-authentication, much like a "Remember Me" button common among sites. Thus, typical durations may be a few minutes, a working day, or two weeks with a preference for shorter times.
Sharing resources cross-origin must be permitted by the web site. Access to response data from usual GET and POST requests will always be restricted to the Same Origin unless the response contains one of the CORS-related headers. A server may respond to these "usual" types of requests with Access-Control-headers. In other situations, the browser may first use a preflight request to establish a CORS policy. This is most common when the XHR object is used.
Excerpted from Hacking Web Apps by Mike Shema. Copyright © 2012 by Elsevier, Inc.. Excerpted by permission of Elsevier Science.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Chapter 1 - Introduction
Chapter 2 - Cross Site Scripting (XSS)
Chapter 3 - Cross Site Request Forgery (CSRF)
Chapter 4 - SQL Injection
Chapter 5 - Server Misconfigurations and Predictable Pages
Chapter 6 - Breaking Authentication Schemes
Chapter 7 - Logic Attacks
Chapter 8 - Web of Distrust
Chapter 9 - HTML5 Security Breaches