1. Towards a Formal Foundation of Web Security devdatta akhawe / adam barth / peifung eric lam john mitchell / dawn song

2. motivation the web is interesting web security is hard formalization will help

3. informed abstract models of the web platform will be amenable to automation, reveal practical attacks and support useful evaluation of alternate designs.

4. web security 101 abstract model alloy implementation case studies

5. The complete isolation that SOP provides is too coarse for modern applications. browsers handle code + documents from multiple sources and need to ensure integrity and confidentiality The security of the whole system is a global property based on invariants at all three components Network robber.com bank.com Web Browser robber.com bank.com Same Origin Policy – code from different websites or “origins” shouldn’t interfere User Same Origin Event Cross Origin Event

6. web security 101 abstract model alloy implementation case studies

7. User The security of the whole system is a global property based on invariants at all three components Network robber.com bank.com Web Browser robber.com bank.com User Simple model of user – not confused and follows security indicators Web Browser Network Web Browser Network

8. networkbrowser threatsgoals network browser threatsgoals

9. The sandbox in which code runs what are the semantics of the isolation? Origin, path, http(s)? Script Context Location bar, http(s), lock icon who decides what is shown ? User Interface Stored passwords/cookies when to send them? State Storage

10. networkbrowserthreatsgoalsnetwork browser threatsgoals

11. Connected to network May break specification (esp. attacker) Many to many relationship with DNS servers HTTP Methods, status codes, headers Integrity – some headers/methods determined by attacker http Different APIs with specific constraints For example, XHR works only same- origin, Forms only allow GET/POST network requests

12. networkbrowserthreatsgoalsnetwork browser threatsgoals

13. web attacker robber.com browser APIs only gadget attacker can inject limited form of content comments on a blog network attacker can modify network traffic except encrypted content Malicious person with his own site No special network privileges Key threat model threat model hierarchy Note that any protocol not over HTTPS can be easily subverted by the network attacker

14. networkbrowserthreatsgoalsnetwork browser threatsgoals

15. Session integrity – Any action that an honest server takes should not be directly/indirectly caused by a dishonest/untrusted principal – A request caused by robber.com shouldn’t reduce money in my bank account Don’t break web invariants – Do not increase attack surface of benign applications – For example, currently cross-origin DELETE/PUT requests with ambient authorization (cookies) aren’t allowed security goals Session integrity – Any action that an honest server takes should not be directly/indirectly caused by a dishonest/untrusted principal – A request caused by robber.com shouldn’t reduce money in my bank account

16. web security 101 abstract model alloy implementation case studies

17. Alloy An object modeling language Executable model eased development Bounded model checker Translates predicates to SAT instances Easy visualization of counterexamples

18. metamodel

19. session integrity // a function that for a given transaction // tells the list of servers involved in causing it fun involvedServers[t:HTTPTransaction]:set NetworkEndpoint{ // the ScriptContext origin getTransactionOwner[t].servers // get list of servers involved in redirect chain + (t.*cause & HTTPTransaction).resp.from } pred webAttackerInCausalChain[t:HTTPTransaction]{ // see if WebAttacker controlled server in set of involved some (WEBATTACKER.servers & involvedServers[t]) }

20. web security 101 abstract model alloy implementation case studies

21. NameType of vulnerabilityPreviously Origin Headerintegrity violationknown Cross Origin Resource Sharing breaks invariantknown HTML5 Formbreaks invariantunknown Referer Validationintegrity violationunknown WebAuthsession fixationunknown case studies NameType of vulnerabilityPreviously Origin Headerintegrity violationknown Cross Origin Resource Sharing breaks invariantknown HTML5 Formbreaks invariantunknown Referer Validationintegrity violationunknown WebAuthsession fixationunknown

22. NameType of vulnerabilityPreviously Origin Headerintegrity violationknown Cross Origin Resource Sharing breaks invariantknown HTML5 Formbreaks invariantunknown Referer Validationintegrity violationunknown WebAuthsession fixationunknown NameType of vulnerabilityPreviously Origin Headerintegrity violationknown Cross Origin Resource Sharing breaks invariantknown HTML5 Formbreaks invariantunknown Referer Validationintegrity violationunknown WebAuthsession fixationunknown case studies

23. HTML5 Form vulnerability – Extremely simple vulnerability – Missed completely by many experts until our study Referer Validation Vulnerability – Past verification not detailed enough WebAuth Vulnerability – More complicated – Hard to find without such analysis

24. HTML5 Form

25. HTML5 GET/POST DELETE PUT GET/POST DELETE PUT robber.com bank.com GET/POST HTML4 Page at robber.com

26. the attack

27. HTML5 PUT PUT ??? cross origin redirect to bank.com “Don’t break web invariants” violated robber.com bank.com Page at robber.com Fix is to disable cross-origin redirects for special methods; model doesn’t find any error after fix

28. alloy counterexample (actual snapshot)

29. Referer Validation

30. the Referer header Sent by nearly all browsers Tells a server which page caused a request For example, if I click on a google search result for “nytimes”, then nytimes.com receives a Referer header value of http://www.google.com/search?q=nytimes

31. disallowed link allowed link attacker sites good sites Redirect Entry Pages Internal Pages (change state) application Outgoing link the idea : check Referer for internal page requests allowed link trusted Referer value untrusted Referer value

32. WebAuth

33. Single sign on solution at Stanford – called CalNet at Berkeley – also common in other academic institutions Single sign on: one password to rule them all – Provides a service similar to Kerberos, but on web At least two parties other than user – The single sign on provider (WebAuth Server) – The application, e.g. library services

34. Application WebAuth Server GET Secret Access Denied! Login at WebAuth (redirect) login form Username Password Send Secret and Set Cookie identifying user for future Username/Password ok! Redirect to App with identifier key Run Crypto Checks on Identifier sent Identifier Key This completes the login procedure

35. the attack

36. Application WebAuth Server GET secret Access Denied! Login at WebAuth (redirect) Username Password Username /Password ok! Redirect to App with identifier key Run Crypto Checks on Identifier sent BLOCK and save link Set cookie identifying user as ATTACKER Send the link Follow link attacker benign user login form Attacker’s credentials that identifies attacker Is this really that bad ?

37. why this is bad At UC Berkeley, I pay my bills via a service that uses CalNet Could be fooled into paying someone else’s bill Fix is to add a nonce to ensure that the application remembers context – model fails to find attack after fix

38. conclusion

39. informed abstract models of the web platform will be amenable to automation, reveal practical attacks and support useful evaluation of alternate designs. informed abstract models of the web platform will be amenable to automation, reveal practical attacks and support useful evaluation of alternate designs.

40. images from sxc.hu http://bit.ly/csf10-websec thank you