Download Web Security - Computer and Information Science

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.
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
The Alarming Situation
Vulnerabilities of web applications (from WhiteHat Security)
The Overall Web Architecture
Web Browser
Application
Server
e.g., PHP, Java Servlet
Web Browser
Database
e.g., MySQL
A Web Application Example
Current Access Control Systems
Web Browser
Web Application Server
Database
HTML Page
Static
Contents
JavaScript
Code
Browser Access
Control (SOP)
Server-side
Code
(PHP, C#,
Java Servlet)
Session + OS Access Control
SQL
Code
DB Access
Control
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
Same-Session Policy
 After authentication, a session is established
 Avoid repetitive authentication
 Session cookies: authentication token
 Same session, same privileges
Problems of SOP and SSP
 Coarse granularity: one or nothing
 No separation of privileges
 Do we need to separate privileges?
Diversified Protection Needs
Untrusted
Region
Advertisements
Semi-Trusted Region
Third-party
Content
AddFriends.php
Trusted Region
DeleteFriends.php
First-party Content
Untrusted Region
Third-party Content
ViewFriends.php
The Loss of Trust State
F.php’s Output: HTML Page
Un-Trusted
Data
Un-trusted Region
Button1
Semi-Trusted
Data
F.php
Semi-Trusted Region
Button2
Trusted Data
ViewFriends.php
AddFriends.php
Trusted Region
Button3
Trust state of data gets lost:
led to the Same-Origin Policy.
DeleteFriends.php
Trust status gets lost again:
led to the “Same-Session Policy”.
Application-Specific Logic
Web Browser
HTML Page
Static
Contents
JavaScript
Code
Browser Access
Control (SOP)
Server-Side Access Control
Application-specific
Access Control
Browser-side
Access
Control
Database
SQL
Code
Database-side
Access
Control
Session + OS Access Control
DB Access
Control
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
Build Better Access Control
Web Browser
HTML Page
Static
Contents
JavaScript
Code
Server-Side Access Control
Application-specific
Access Control
Browser-side
Access Control
Database-side
Access Control
Better Access
Control
System
Better Access Control System
Database
SQL
Code
Better
Access
Control
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
Design Principles
Civil Engineering Principles
Security Engineering Principles
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
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
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.
Final Choice: the Ring model
 Subjects and objects are labeled with rings
 Widely used model: operating system, etc.
Hierarchy
Ring-Based Access Control for Web
Browser
Ring = 0
Submit
JavaScript Code
URL
Application Server
URL
URL
Escudo + SOP
2
1
1
0
A.php
Ring = 2 JavaScript Code
Submit
2
0
Ring = 1 JavaScript Code
Submit
Database
0
1
1
0
TableA
2
2
Scuta + Session
Scuta
Escudo: Shield in Portuguese
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 ring=0>
malicious code
</div>
<div>
</div>
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)
Scuta: Roman Shield
Browser
Ring = 0
Submit
Application Server
JavaScript Code
URL
1
URL
URL
2
1
0
A.php
Ring = 2 JavaScript Code
Submit
2
0
Ring = 1 JavaScript Code
Submit
Database
1
Scuta + Session
Fill the gap
1
0
TableA
2
2
Escudo + SOP
0
Scuta
Fill the gap
Scuta: Subsession
Web Page
Ring = 0
F.php
JavaScript Code
call F.php
URL
(F.php)
JavaScript Code
call F.php
URL
(F.php)
Cookies: SubSID_0,
SubSID_1, SubSID_2, SID
Subsession = 0
F.php
Ring = 2
Cookies
F.php
Ring: 0
Ring: 1
SubSID_0
SubSID_1
Cookies: SubSID_2, SID
Ring: 2
SID,
SubSID_2
Browser Side Server Side
F.php
Subsession = 2
Scuta’s Basic Access Control
Browser
Ring = 0
Submit
JavaScript Code
URL
Application Server
1
Ring = 1 JavaScript Code
Submit
URL
1
URL
0
A.php
Ring = 2 JavaScript Code
Submit
2
0
2
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;
}
Scuta: Gates
 Exceptions invetible
 Like system calls
 Provide controlled access
Ring 0
Ring 1
Ring 2
 Example
 DB modification: Ring 0
 Allow Ring 3 to modify DB
in a controlled way.
Scuta at Database
Browser
Ring = 0
Submit
JavaScript Code
URL
Application Server
URL
URL
Escudo + SOP
2
1
1
0
A.php
Ring = 2 JavaScript Code
Submit
2
0
Ring = 1 JavaScript Code
Submit
Database
1
0
1
0
TableA
2
2
Scuta + Session
Scuta
Another Gap
2
2
1
0
A.php
Application Server
dbuser
1
0
TableA
Database
Fill the Gap
2
1
dbuser_2
dbuser_1
0
A.php
Application Server
dbuser_0
2
1
0
TableA
Database
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
Scuta: Architecture
PHP Code
Web
Request
Extensions
Session
Database
Zend Engine
Scuta
Reply
Initialization
Run-time Security Context
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
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)
Session Cookie: Ring 0
Ring 2
Client-Side Extensions
Third-party JS code
Advertisements
Secure Client-Side Extensions
Modify()
A 3rd-party client-side extension
Display()
Renew()
Ring 0
Ring 1
Ring 2
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
Secure Server-Side Extensions
Trustworthy
Server-side
extensions
Ring 0
Ring 1
Ring 2
Not so-trustworthy
Server-side
extensions
Cross-Site Requests (non-Ajax)
Facebook.com
e.g. Delete Friends
Browsing
Facebook
User’s Browser
Secure Cross-Site Requests
Facebook’s Scuta Configuration
Cross-Site Requests
Ring 0
Ring 1
Ring 2
Cross-Site Requests are Mapped to
the Least Privileged Ring
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
Secure Cross-Site Ajax Requests
Server’s Scuta Configuration
Ring 0
Ring 1
Browser’s Escudo Configuration
Originbased
Ring
Mapping
Ring 0
Ring 1
Ring 2
Ring 2
Case 2
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