Web inSecurity
Session: Tuesday, Session 3, Space B
Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page
Convener: JeffH
Devdatta Akhawe (UCBerkeley) presented on..
"Web (In)Security and Identity Implementations"
..wherein he discusses a vulnerability found in Facebook Connect's implementation, and another bug -- a 'design bug' -- found in a web single-sign-on protocol (WebAuth). The latter protocol is very similar to various 'front-channel' HTTP-redirect-based web single-sign-on protocols such as SAML web browser SSO profile, OpenID, etc.
The papers where these findings are discussed in detail are..
The Emperor’s New API: On the (In)Secure Usage of New Client Side Primitives
Several new browser primitives have been proposed to meet the demands of application interactivity while enabling security. To investigate whether applications consistently use these primitives safely and adequately in practice, we study the real-world usage of two client-side primitives, namely postMessage and HTML5’s client-side database storage. We examine new purely client-side communication protocols layered on postMessage (Facebook Connect, Google Friend Connect) and several real-world web applications (including Gmail, Buzz, Maps and others) which use client-side storage abstractions. We find that, in practice, these abstractions are widely used insecurely, which leads to severe vulnerabilities and can increase the attack surface for web applications in unexpected ways. We conclude the paper by offering insights into why these abstractions can be hard to use safely, and propose the economy of liabilities principle for designing future abstractions. The principle recommends that a good design for a primitive should minimize the liability that the user undertakes to ensure application security. We suggest enhancements to the existing browser primitives to make their secure use more practical.
Towards a Formal Foundation of Web Security PDF HTML
We propose a formal model of web security based on an abstraction of the web platform and use this model to analyze the security of several sample web mechanisms and applications. We identify multiple distinct threat models that can be used to analyze web applications, ranging from a web attacker who controls malicious web sites and clients, to stronger attackers who can control the network and/or leverage sites designed to display user-supplied content. We propose two broadly applicable security goals and study five security mechanisms. In our case studies, which include HTML5 forms, Referer validation, and a single sign-on solution, we use a SAT-based model-checking tool to fid two previously known vulnerabilities and three new vulnerabilities. The case study of a Kerberos-based single sign-on system illustrates key differences between network protocols and web protocols and finds a vulnerability that arises because of the way cookies, redirects, and embedded links are used.
The web security model is available as opensouce..https://code.google.com/p/websecmodel/
Presented this talk..
The Need for Coherent Web Security Policy Framework(s)
Web-based malware and attacks are proliferating rapidly on the Internet. New web security mechanisms are also rapidly growing in number, although in an incoherent fashion. In this position paper, we give a brief overview of the ravaged web security landscape, and the various seemingly piece-wise approaches being taken to mitigate the threats. We then propose that with some cooperation, we can likely architect approaches that are more easily wielded and provide extensibility for the future. We provide thoughts on where and how to begin coordinating the work.
The position paper underlying the talk is..http://w2spconf.com/2010/papers/p11.pdf
..and mentioned recent developments since the talk was originally conceived (May-2010)..
- WebSec working group now established in IETF
- chartered to complete current in-progress specs on..
- HTTP Strict Transport Security (HSTS) - Origin - Content-sniffing
- as well as develop a requirements document for web security policy framework
- HSTS now natively implemented in Firefox 4 and Chrome 4+
- anticipated just the sort of attacks that Firesheep utilizes
- onus is now really on web site operators to offer truly secure site access
- WebAppSec working group being established in W3C
- in-progress W3C specs on CORS and UMB will move over here
- will be home for Mozilla Content Security Spec (CSP
