|
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 across more than a single vendor; 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:
Credentials are also cached for authentication with other subresources on the same site, and are sent out on future requests in an unsolicited manner (globally, or only for a particular path prefix). 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 (or injected) 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 within a single same-origin context 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 - in theory - 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 would normally limit the impact, but flaws in the design are known. Due to its minimal use, the mechanism likely received very little security scrutiny otherwise. HTML5 sandboxed framesA better-developed descendant of the SECURITY=RESTRICTED is the current HTML5 proposal for sandboxed frames. The design appears to be considerably more robust and offers a better granularity for restricting the behavior of framed sites: embedding domains will be able to disallow scripting altogether; allow JavaScript but make all same-origin policy checks fail; or allow scripting, but prevent navigating the top-level document to prevent framebusting. Of all these features, the ability to place content in a same-origin policy sandbox is the most tricky one. Perhaps most importantly, the attacker could simply open the normally framed document directly (this is prevented by using text/html-sandboxed as a MIME type; but content sniffing logic will render this trick unsafe in certain browsers). The other significant problem is that mechanisms such as local storage and workers (see next chapter), form autocomplete, and so forth, need to be specifically accounted forth and denied access to - something that will likely prove challenging in the long run. HTML5 storage, cache, and worker experimentsFirefox 2 embraced the idea of globalStorage, a somewhat haphazard mechanism that permitted data to be stored persistently for offline use in a local database shared across all sites (and until Firefox 2, with no strong security controls on scoping). The concept of globalStorage originated with early HTML5 drafts, although there, got eventually ditched in favor of a more tightly controlled sessionStorage and localStorage APIs, supported by Firefox 3.6, Internet Explorer 8, Opera, and WebKit-based browsers. Another idea of SQL database support made rounds, but originally failed to gain any support. WARNING: The implementation of sessionStorage and localStorage in Internet Explorer 8 dangerously deviates from the standard, treating storages managed by HTTP and HTTPS content as same-origin. The sessionStorage implementation in Firefox 3.6 also permits properties set by HTTP pages to be read by HTTPS content, but not vice versa - which can be problematic. Further along the lines of offline storage mechanisms, Firefox 3 introduced, and Firefox 3.1 revised in a largely incompatible manner, the concept of cache manifests that permit sites to opt for having certain resources persistently stored in a site-specific cache, and then retrieved from there instead of being looked up on the net. The feature is again borrowed from the ever-shifting HTML5 specification (and now also available in WebKit browsers). Web workers are another HTML5 design along these lines, starting to ship with WebKit browsers. The idea is to permit asynchronous, background JavaScript execution in a separate process; dedicated workers would be tied to their opener, and terminated when the page closes; shared workers are not bound to their origin, and free to use postMessage API to interact with third-party domains; and persistent workers may be allowed to launch and execute across browser sessions with no additional dependencies of any sort. There are still some kinks in the design documents at this point, however. Microsoft Internet Explorer XSS filteringAn experimental reflected HTML injection filter is available in Microsoft Internet Explorer 8. The filter attempts to disable any Javascript on the page that seems to be copied from query parameters. 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 likely 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. The filter also features a same-origin exception that inhibits filtering when site-supplied links are followed. In many complex web applications, this may be used to bypass the mechanism altogether. 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:
Secure JSON parsingA traditional method for modern web applications to parse same-origin, serialized text JavaScript responses returned by servers in response to XMLHttpRequest calls is to pass them to eval() - which turns the string into a native object. Unfortunately, calls to eval() have a number of side effects - most notably, any code smuggled inside the string would execute in the recipient script security context, putting an additional burden on the server or the client to sanitize the code - and leading to many security bugs. Several implementations of secure JSON parsers were proposed earlier, such as the (unsafe!) implementation suggested RFC4627, but they generally combine varying levels of insecurity with very significant performance penalties. In response to this, several browsers rolled out JSON.parse(), a native non-executing JSON parser that could be used as a drop-in replacement for eval(). The interface does not address the much greater risk of loading cross-domain JavaScript information via <SCRIPT SRC=...> or similar approaches, and the cross-browser support is at this point very limited, shipping in Chrome and Firefox 3.5. 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 (specification), a mechanism that would permit site owners to define a list of valid target domains for <IMG>, <EMBED>, <APPLET>, <SCRIPT>, <IFRAME>, and similar resources appearing in their content; and to disallow inline code from being used directly on a page. The security benefit of these features is limited primarily to cross-site scripting prevention and webmaster 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 number of day-to-day security issues. 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:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|