Read an Excerpt
Hacking Web Apps
Detecting and Preventing Web Application Security Problems
By Mike Shema Elsevier Science
Copyright © 2012 Elsevier, Inc.
All rights reserved.
ISBN: 978-1-59749-956-9
Excerpt
CHAPTER 1
HTML5
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.
The path to HTML5 included the map of de facto standards that web developers embraced from their favorite browsers. Yet importantly, the developers behind the standard gave careful consideration to balancing historical implementation with better-architected specifications. Likely the most impressive feat of HTML5 is the explicit description of how to parse an HTML document. What seems like an obvious task was not implemented consistently across browsers, which led to HTML and JavaScript hacks to work around quirks or, worse, take advantage of them. We'll return to some of security implications of these quirks in later chapters, especially Chapter 2.
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)
Some features of HTML5 reflect the real-world experiences of web developers who have been pushing the boundaries of browser capabilities in order to create applications that look, feel, and perform no different than "native" applications installed on a user's system. One of those boundaries being stressed is the venerable Same Origin Policy—one of the very few security mechanisms present in the first browsers. Developers often have legitimate reasons for wanting to relax the Same Origin Policy, whether to better enable a site spread across specific domain names, or to make possible a useful interaction of sites on unrelated domains. CORS enables site developers to grant permission for one Origin to be able to access the content of resources loaded from a different Origin. (Default browser behavior allows resources from different Origins to be requested, but access to the contents of each response's resource is isolated per Origin. One site can't peek into the DOM of another, e.g. set cookies, read text nodes that contain usernames, inject JavaScript nodes, etc.)
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):
• Origin—The scheme/host/port of the resource initiating the request. Sharing must be granted to this Origin by the server. The security associated with this header is predicated on it coming from an uncompromised browser. Its value is to be set accurately by the browser; not to be modified by HTML, JavaScript, or plugins.
• 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.
• Access-Control-Request-Headers—Used in a preflight request to determine if the server will honor the additional headers the XHR object wishes to set. For example, client-side JavaScript is forbidden from manipulating the Origin header (or any Sec-header in the upcoming WebSockets section). On the other hand, the XHR object may wish to upload files via a POST method, in which case it may be desirable to set a Content-Type header (although browsers will limit those values this header may contain).
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-Expose-Headers—A list of headers that the browser may make visible to the client. For example, JavaScript would be able to read exposed headers from an XHR response.
• 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.
(Continues...)
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.
