Re-designing the Web’s Access Control Systems

1. Re-designing the Web’s Access Control Systems Wenliang (Kevin) Du Associate Professor Department of Electrical Engineering & Computer Science Syracuse University Joint work with Dr. Karthick Jayaraman, Tongbo Luo, Xi Tan, and Dr. Zutao Zhu Presentation at Microsoft Research, Redmond, 7/28/2011.

2. Overview • Access control in the Web • Our positions on Web’s access control • Our approaches to improve web security • Escudo: Browser-side access control • Scuta: Server-side access control • Database-side access control

3. The Alarming Situation Vulnerabilities of web applications (from WhiteHat Security)

4. The Overall Web Architecture Database Application Server Web Browser e.g., PHP, Java Servlet e.g., MySQL Web Browser

5. A Web Application Example

6. Current Access Control Systems Web Browser Web Application Server Database Server-side Code (PHP, C#, Java Servlet) SQL Code HTML Page Static Contents JavaScript Code DB Access Control Browser Access Control (SOP) Session + OS Access Control

7. Same Origin Policy (SOP) Google Mail www.gmail.com AJAX DOM Tree JavaScript Code AJAX www.microsoft.com (this action is now allowed) Cookies from Gmail.com Cookies from Microsoft.com

8. Same-Session Policy • After authentication, a session is established • Avoid repetitive authentication • Session cookies: authentication token • Same session, same privileges

9. Problems of SOP and SSP • Coarse granularity: one or nothing • No separation of privileges • Do we need to separate privileges?

10. Diversified Protection Needs Untrusted Region Semi-Trusted Region Third-party Content AddFriends.php Advertisements TrustedRegion DeleteFriends.php First-party Content Untrusted Region ViewFriends.php Third-party Content

11. The Loss of Trust State F.php’s Output: HTML Page Un-Trusted Data Un-trusted Region Button1 ViewFriends.php F.php Semi-Trusted Data Semi-Trusted Region AddFriends.php Button2 Trusted Data Trusted Region Button3 DeleteFriends.php Trust state of data gets lost: led to the Same-Origin Policy. Trust status gets lost again: led to the “Same-Session Policy”.

12. Application-Specific Logic Server-Side Access Control Web Browser Database Application-specific Access Control SQL Code HTML Page Static Contents Browser-side Access Control Database-side Access Control JavaScript Code DB Access Control Browser Access Control (SOP) Session + OS Access Control

13. Inadequate Access Control • Access control has to be built into program logic • Not easy for programmers • 83% of web sites have at least one serious vulnerability • Deploy countermeasures in programs. • Developers need to be security experts • Do we have enough security experts? • I am a security expert, I am afraid of writing web apps. • Something is fundamentally wrong! • Don’t blame the developers • Blame the Web’s security infrastructure

14. Build Better Access Control Server-Side Access Control Web Browser Database Application-specific Access Control SQL Code HTML Page Static Contents Browser-side Access Control Database-side Access Control JavaScript Code Better Access Control Better Access Control System Better Access Control System

15. The Benefit • Developers’ security efforts are reduced • They only need to “configure” • Enforcement is done by the system • Configuration: compared to Implementation • Much easier to do • Require less security expertise • Less error prone • Easier to verify

16. Design Principles Civil Engineering Principles Security Engineering Principles

17. Security Engineering Principles • [Saltzer and Schroeder 1975]: 8 design principles for building protection systems: • Economy of mechanism • Fail-safe defaults • Complete mediation • Open design • Separation of privilege • Least privilege • Least common mechanism • Psychological acceptability

18. Key Security Principles • Separation of privilege • Partitioning access permissions • Example: Root vs. Ordinary user account • SOP & SSP: privileges are not separated • Principle of least privilege • A program must have no more privileges than necessary for its legitimate purpose • SOP & SSP: do not support this principle

19. Requirement on the New Model • Finer Granularity • Reflect the nature of “Trust” • Multi-level, multi-lateral, etc. • Considering the Protection needs • Backward compatible • Well Vetted • Creativity is probably the enemy here.

20. Final Choice: the Ring model • Subjects and objects are labeled with rings • Widely used model: operating system, etc.

21. Hierarchy

22. Ring-Based Access Control for Web Browser Application Server Database Ring = 0 C.php JavaScript Code 2 0 Submit URL 2 TableC 1 D.php B.php Ring = 1 1 TableB JavaScript Code 0 0 Submit 1 0 URL 1 A.php TableA Ring = 2 JavaScript Code 2 2 Submit URL Escudo + SOP Scuta + Session Scuta

23. Escudo: Shield in Portuguese

24. Policy Integrity • Scoping Rule • A “div” tag’s principal ring is the lower bound for all its children • Node-splitting • Use tag (or nonce) to prevent <div ring=3> </div> </div> <div ring=0> malicious code </div> <div>

25. Backward Compatibility • Escudo Browsers with Non-Escudo Applications • All principals and objects belong to the same ring, mimicking same-origin policy • Escudo-applications with Non-Escudo Browsers • The configuration is ignored • Application still executes (no security)

26. Scuta: Roman Shield Browser Application Server Database Ring = 0 C.php JavaScript Code 2 0 Submit URL 2 TableC 1 D.php B.php Ring = 1 1 TableB JavaScript Code 0 0 Submit 1 0 URL 1 A.php TableA Ring = 2 JavaScript Code 2 2 Submit URL Escudo + SOP Scuta + Session Scuta Fill the gap Fill the gap

27. Scuta: Subsession Web Page Ring = 0 Cookies: SubSID_0, SubSID_1, SubSID_2, SID Subsession = 0 JavaScript Code call F.php URL (F.php) F.php F.php Ring = 2 Cookies: SubSID_2, SID JavaScript Code call F.php URL (F.php) F.php F.php Subsession = 2 Ring: 0 Ring: 1 Ring: 2 Cookies SID, SubSID_2 SubSID_0 SubSID_1 Browser Side Server Side

28. Scuta’s Basic Access Control Browser Application Server Ring = 0 C.php JavaScript Code 2 0 Submit URL 1 D.php B.php Ring = 1 JavaScript Code 0 Submit 1 URL A.php Ring = 2 JavaScript Code 2 Submit URL

29. Scuta: More Flexible Policy Support Discretionary Security Policies: Swich (session_esubsid() ) { case 0: Do Task A; break; case 1: Do task B break; case 2: Do Task C break; }

30. Scuta: Gates • Exceptions invetible • Like system calls • Provide controlled access • Example • DB modification: Ring 0 • Allow Ring3 to modify DB in a controlled way. Gate Ring 0 Ring 1 Ring 2

31. Scuta at Database Browser Application Server Database Ring = 0 C.php JavaScript Code 2 0 Submit URL 2 TableC 1 D.php B.php Ring = 1 1 TableB JavaScript Code 0 0 Submit 1 0 URL 1 A.php TableA Ring = 2 JavaScript Code 2 2 Submit URL Escudo + SOP Scuta + Session Scuta

32. Another Gap C.php 2 2 TableC 1 D.php B.php dbuser 1 TableB 0 0 A.php TableA Application Server Database

33. Fill the Gap C.php 2 dbuser_2 2 TableC 1 D.php B.php dbuser_1 1 TableB 0 0 dbuser_0 A.php TableA Application Server Database

34. Place Data in Rings • Use the GRANT command • Fine granularity on tables, columns, and operations • Examples • GRANT ALL ON TableA TO dbuser_0 • GRANT ALL ON TableB TO dbuser_1 • GRANT ALL (Profile, Name)ON TableC TO dbuser_1 • GRANT SELECT (Profile) ON TableC TO dbuser_2

35. Scuta: Architecture PHP Code Web Request Extensions Zend Engine Session Database Scuta Reply Run-time Security Context Initialization

36. Case Studies • Browser-side Protection • Cross-Site Scripting Attacks (XSS) • Same-Origin Requests • Client-side extensions • Server-side extensions • Cross-Origin (or Cross-Site) Requests • Non-Ajax • Ajax

37. Defeating XSS Attacks with Escudo Ring 0 First-Party Contents (Trustworthy) Ring 1 Ring 1 First-Party Contents (Readable by Ads) Ring 2 Other user’s comments (Untrusted) Ring 2 Session Cookie: Ring 0

38. Client-Side Extensions Third-party JS code Advertisements

39. Secure Client-Side Extensions Modify() A 3rd-party client-side extension Display() Renew() Ring 0 Ring 1 Ring 2

40. Server-Side Extensions • Server-side code written by 3rd parties • Elgg has hundreds of such extensions • An “App” model • Problematic Server-Side Extensions • Malicious • Vulnerable: the SQL Injection case

41. Secure Server-Side Extensions Trustworthy Server-side extensions Ring 0 Not so-trustworthy Server-side extensions Ring 1 Ring 2

42. Cross-Site Requests (non-Ajax) Facebook.com e.g. Delete Friends Session ID Browsing Facebook User’s Browser

43. Secure Cross-Site Requests Facebook’s Scuta Configuration Cross-Site Requests Ring 0 Ring 1 Cross-Site Requests are Mapped to the Least Privileged Ring Ring 2

44. Cross-Site Ajax Request • Security Policy • Not allowed in the past • Allowed now • Access Control Model • The new “Origin” header • White lists • Problems • “Origin” is too coarse-grained • A trusts B does not mean A trusts the Ads on B’s page. Case 2

45. Secure Cross-Site Ajax Requests Server’s Scuta Configuration Browser’s Escudo Configuration Origin-based Ring Mapping Ring 0 Ring 0 Ring 1 Ring 1 Ring 2 Ring 2 Case 2

46. Summary • Web is becoming part of the infrastructure • Should not be treated as yet-another application. • Need more system thinking for security • Web Security is a major problem • All web applications need to think about security • A good system support partially frees developers • So they can focus more on application logic • We are working on developing such a system support • Browser-side support • Server-side support • Database-side support