|
Part3
Browser Security Handbook, part 3
Browser Security Handbook, part 3
Table of Contents
Experimental and legacy security mechanismsThrough the years, browsers accrued a fair number of security mechanisms that had either fallen into disuse, or never caught on; as well as a number of ongoing proposals, enhancements, and extensions that are yet to prove their worth or become even vaguely standardized. This section provides a brief overview of several technologies that could fall into this class. Fun fact: when it comes to newly proposed features, many of them essentially introduce new security boundaries and permission systems mostly orthogonal, yet intertwined, with same-origin controls. Although this appears to be a good idea at first sight, some researchers warn about the pitfalls of finer-grained origins as difficult to understand to users, and hard to fully examine for potential side effects and interactions with existing code. HTTP authenticationHTTP authentication is an ancient mechanism most recently laid out in RFC 2617. It is a simple extension of HTTP:
Two key authentication schemes are supported by virtually all clients: basic and digest. The former simply sends user names and passwords in plain (base64) text - and hence the data is vulnerable to snooping, unless the process takes place over HTTPS. The latter uses a simple nonce-based challenge-response mechanism that prevents immediate password disclosure. Microsoft further extended the mechanism to include two proprietary NTLM and Negotiate schemes (reference) that integrate seamlessly with Microsoft Windows domain authentication. As hinted in the section on URL syntax, URLs are permitted to have an optional user[:password]@ segment immediately before the host name, to enable pre-authenticated bookmarks or shared links. In practice, the mechanism would be seldom used for legitimate purposes, but became immensely popular with phishers - who would often construct URLs such as http://www.example-bank.com:something_something@www.evilsite.com/ in hopes of confusing the user. This led to this URL syntax being banned in Microsoft Internet Explorer, and often resulting in security prompts elsewhere. Because of these limitations and the relative inflexibility of this scheme to begin with, HTTP authentication has been almost completely extinct on the Internet, and replaced with custom solutions built around HTTP cookies (it is still sometimes used for intranet applications or for simple access control for personal resources). Amusingly, its ghost still haunts modern web applications: HTTP authentication prompts often come up in browsers when viewing trusted pages where a minor authentication-requiring sub-resource, such as <IMG>, is included from a rogue site - but these prompts usually do a poor job of clearly explaining who is asking for the credentials. This poses a phishing risk for services, such as blogs or discussion forums, that allow users to embed external content.
Name look-ahead and content prefetchingSeveral browsers are toying with the idea of prefetching certain information that, to their best knowledge, is likely to be needed in the immediate future. For example, Firefox offers an option to perform a background prefetch of certain links specified by page authors (reference); and Chrome is willing to carry out look-ahead DNS lookups on links on a page (reference). The idea here is that if the user indeed takes the action anticipated by browser developers or page owners, he or she would appreciate the reduced latency achieved through these predictive, background operations. On the flip side, prefetching has two important caveats: one is that it is generally rather wasteful - as users are very unlikely to follow all prefetched links, and quite often, would not follow any of them; the other is that in certain applications, such look-aheads may reveal privacy-sensitive information to third parties. One particularly interesting risk scenario is the context of a web mail interface: unless prefetching is properly disabled or limited, the sender of a mail containing a HTTP link might have the ability to detect that the recipient had read his message, even if the link itself is not followed. Password managersAs a part of a broader form auto-completion mechanism, most browsers offer users the ability to save their passwords on client side, and auto-complete them whenever previously seen authentication forms appear again. Unfortunately, as noted in the previous section, the only standard mechanism for identifying and scoping user passwords in HTTP traffic had largely fallen into disuse; the new form- and cookie-based alternatives are custom-built for every application, are share almost nothing in common with each other. As a result, most browsers face challenges trying heuristically detect when a legitimate authentication attempt takes place and succeeds, or trying to decide how to define the realm for stored data. In particular, it might be easier than intuitively expected for certain types of user content hosted under the same host name as a trusted login interface to spoof such forms and intercept auto-filled data; letting user-controlled forms and login interfaces mix on the same site appears to be not necessarily a good idea for time being. Several of the relevant password manager behaviors are shown below:
Robert Chapin offers some additional research into password manager scoping habits, exploring some non-security considerations as well. Microsoft Internet Explorer zone modelAll current versions of Internet Explorer utilize an interesting concept of security zones, not shared with any other browser on the market. The idea behind the approach is to compartmentalize resources into various categories, depending on the degree of trust given - and then control almost all security settings for these groups separately. The following zones are defined:
This design makes it possible to, for example, fine-tune the permissions of file:/// resources without impacting Internet sites, or to forbid navigation from "Internet" to "Local intranet" - and from this perspective, appears to offer a major security benefit. On the flip side:
Microsoft Internet Explorer frame restrictionsAnother interesting, little-known security feature unique to Microsoft Internet Explorer is the concept of SECURITY=RESTRICTED frames. The idea behind the mechanism is that some services may have a legitimate use for limiting the ability of data displayed within <IFRAME> containers to disrupt the top-level document or abuse same-origin policies - and so, with the SECURITY=RESTRICTED attribute, the content may be placed in the "Restricted sites" zone, and deprived of the ability to run disruptive scripts or access cookies. No support outside of Microsoft Internet Explorer makes this feature useless as a security defense for most intents and purposes; but the mechanism needs to be considered for its potential negative security impact, such as the ability to prevent frame busting code from operating properly and making UI redress attacks a bit easier. No support for HTTP cookies within a restricted container limits the impact by design. Due to its minimal use, the mechanism likely received very little security scrutiny. Microsoft Internet Explorer XSS filteringAn experimental reflected HTML injection filter is proposed for Microsoft Internet Explorer 8. It is uncertain what final shape this mechanism would take, and how useful it will be for preventing attacks; the complexity of escaping rules, jiffy handling of certain character sets, and quirky rules for parsing HTML documents, all make it likely that the mechanism would never achieve a 100% coverage - a property that Microsoft pragmatically acknowledges in their design proposals. As such, the mechanism would serve to complement, rather than replace, proper server-side development practices. An important downside of the design is that it aims to selectively disable script snippets that appear in URL query parameters, instead of displaying an interstitial or other security prompt, and permitting the page to display in full, or not display at all. This behavior may potentially enable attackers to carefully take out frame-busting code or other security-critical components of targeted applications, while leaving the rest of the functionality intact. Script restriction frameworksSeveral experimental browser-side or client-side designs aim to provide control over same-origin permissions for scripts, or over when scripts may execute on pages to begin with. Although such features would not necessarily prevent all the potential negative effects of rendering attacker-controlled HTML in trusted domains, a well-executed solution could indeed avert most of the high-impact vulnerabilities. There are two primary classes of solutions proposed:
Origin headersAdam Barth, Collin Jackson, and other researchers propose the introduction of reliable Origin headers as an answer to the risk of cross-site request forgery - giving sites the ability to reliably and easily decide whether a particular request permitted across domains comes from a trusted party or not. In theory, an existing Referer HTTP header could be used for the same purpose, but many users install tweaks to suppress it for privacy reasons; the header may also be dropped on certain page transitions, and was not generally designed to be reliable. Origin proposals attempt to limit the risk of the header being disabled by limiting the amount of data being sent across domains (host name, but no full URL; though arguably, it may still easily disclose undesirable information); and limiting the types of requests on which the header is provided (although this may undermine some of the security benefits associated with the solution). Mozilla content security policiesBrandon Sterne of Mozilla proposes content security policies, a mechanism that would permit site owners to define a list of valid target domains for <IMG>, <EMBED>, <APPLET>, <SCRIPT>, and <IFRAME> resources appearing in their content The security benefit of these features is by itself limited to very specialized uses, primarily associated with policy enforcement; the proposal originally also incorporated the ability to define a list of valid origins for incoming requests as a method to mitigate cross-site request forgery attacks - but this part of the design got dropped in favor of more flexible and simpler Origin headers. Open browser engineering issuesOther than the general design of HTTP, HTML, and related mechanisms discussed previously, a handful of browser engineering decisions tends to contribute to a disproportional of day-to-day security woes. Understanding these properties is sometimes important for properly assessing the likelihood and maximum impact of security breaches, and hence determining the safety of user data. Some of the pivotal, open-ended issues include:
|
