• Aaron Blankstein and Michael J. Freedman
• Princeton University
• Tuan Tran
Introduction
How to solve those threats?
Source: http://www.economist.com/node/18226961
Presentation Outline
 Security goals and assumptions
 Passe design
 Passe runtime in web setting
 Passe analysis phase
 Implementation
 Evaluations
3
Security goals and assumptions
Threat Model
 Developers supply non-malicious application code.
 Attackers are unable to compromise the trusted components.
 Passe’s trusted components provide very simple functionality.
4
Security goals and assumptions
Motivating Classes of Vulnerabilities
 Poorly understood application behavior
 Use library calls which have surprising behavior.
 Cross-Site Scripting
 XSS attacks may allow a vulnerability in one view to make AJAX
requests to other views.
 Arbitrary Code Execution
 Attackers can execute arbitrary code.
5
Security goals and assumptions
Security Properties of Passe
 Isolation of Execution
 An attacker is unable to inspect or alter the memory of views
 Isolation of Data
 An attacker is unable to read or modify portions of the durable data
store.
 Enforcement of Data Policy
 An attacker is unable to violate high-level application data policies.
6
Passe design
Accommodates the typical
tiered, scale-out architecture.
 Service tier
 Handle request.
 Access shared storage.
 Storage tier
 Handle partitions of the
shared storage.
7
Passe design
 Apps are decomposed into
isolated views.
 Views handle specific
requests.
 Passe introduces a stateless
proxy between the service and
storage tiers
8
Passe design
Interacting with a Shared Data Store
 Passe provides data isolation between application views.
 Application views interact with a shared data store through a
query interface.
 An unbound query has a set of arguments.
 Ex: result = fetchUserMessage(uname = “Bob”)
 Passe constrains the arguments to queries.
9
Passe design
Protecting the Shared Data Store
 Enforce dependencies: a database proxy; cryptographic tokens.
 Every request and response must include a token.
 To approve a query, the database proxy checks:
 The unbound query.
 The argument value and token.
10
Passe design
Learning Constraints
 Passe uses dynamic taint tracking to learn the dependencies.
 Developers can either supply test cases or run an “internal beta”.
 Passe translates dependencies into the token-based constraints,
allowing any of the witnessed traces to run.
11
Passe runtime in web setting
Implement as a drop-in replacement
for Django.
 Dispatcher
 Use URL of a request.
 Session Manager
 Handle mapping cookies.
 Authentication Manager
 Check users credential.
 Database proxy
 Mediates access to database.
 View Server
 Provide a wrapper around view function.
12
Passe runtime in web setting
Isolating View
 Determining view boundaries
 Each view handles a complete request.
 Translating function calls
 Wrap application code with a view server.
 Dealing with global variables
 Shared global variables are no longer shared.
 Sandboxing the processes
 Engaging Linux’s App Armor.
 Create specific communication channels for the processes.
13
Passe runtime in web setting
Constraining SQL Queries
 Specify how a SQL query maps to an unbound query.
 Treat the query sting as the unbound query.
 Store the string with a cryptographic hash of the query string.
 Specify how SQL query results are stored
 Use a hash of the query string.
 Separate the results by column.
14
Passe runtime in web setting
Handling a Web Request
 View receives the HTTP request
object and a token.
 View makes two queries with
protected arguments.
 View displays all posts form
Alice’s friends.
15
Passe runtime in web setting
User Authentication and Session Management
 Modify Django’s mechanisms for associating a request with a user.
 In Django:
 View can call into the library which returns the user.
 The request is a part of a session associated with a user.
 In Passe:
 Embed the user’s ID in a token.
16
Passe runtime in web setting
An end user’s browser presents a significant attack channel.
Cross-view attack channel
17
Passe runtime in web setting
Isolating Views at Client’s Browser
 Passe supports execution with isolation at the client browser.
 Passe’s dispatcher interposes on AJAX requests between views.
 Implement a trusted shim layer which ensures that the headers
are correctly added to each outgoing AJAX request.
18
Passe runtime in web setting
Applicability to Other Frameworks
 Passe’s architecture is applicable to other web frameworks.
 Ruby on Rails


The dispatcher make routing decisions based on Rails’ routes.
Views are separated along Rails’ ActionControllers and Views
 Passe would need to provide a new third party authentication
library.
19
Passe analysis phase
Passe monitors application execution to:
 Enumerate Views
 Assign each of them a unique identifier.
 Enumerate Queries
 Associate each view with the SQL queries.
 Infer Dependency Relationships Between Queries
 Determine data, control-flow relationships.
 Translate Dependencies into Enforceable Constraints.
 Dependencies must be translated to constraints
20
Passe analysis phase
Dynamic Taint Tracking
 The interpreter exposes a library which application-level code
can use to taint tracking and tracing.
 Any instruction which returns an object propagates taint from the
arguments to that object.
 The interpreter checks the taint of any boolean used to evaluate a
conditional jump.
21
Passe analysis phase
Tainting Data Objects and Logging Query Events
 Passe captures a query call with the following information:
 The view
 The query string
 An ordered list of the query’s argument values and their taints.
 Any previous database results and their taints.
 The control-flow taint set for the execution context.
 The analyzer translates witnessed dependency relationships
between queries and objects into the integrity constraints.
22
Passe analysis phase
Inferring Constraints from Dependency Relationships
 Passe collects all of the events and merges the dependency.
 Data-flow relationships:
 Checks for equality and set membership relationships
 These two relationships are captured based on object identifiers
 Control-flow relationships:
 Determine which control-flow relationships affect the event.
 Create a set of invariants for the query.
23
Passe analysis phase
Impacts of False Positives and Negatives
 False Positive:
 Developers allow dataflow which Passe does not.
 Resolve by including new test cases.
 False Negative:
 Passe generate a policy which is too permissive.
 Remedy by manually inserting the dependencies into the
policy.
24
Implementation
 Implement Passe as modified versions of Django 1.3
 Runtime engine:
 Modify the dispatcher to support interprocess call to view.
 Modify library to make proxied requests.
 Analysis engine:
 Add annotating calls for the tracer.
25
Implementation
Unsupported Django Behavior
 Views are forced to authenticate users through the default
authentication library.
 Applications cannot use arbitrary global variables.
 The URL Map may only contain views found during analysis.
26
Protections for real applications
Passe in the Presence of Vulnerabilities
 Unexpected behavior
 The normal path of the code would create a constraint for the
SQL statements.
 XSS attacks
 Restricting the content returned by views.
 Arbitrary code execution
 Restricting developer-supplied code to specific database
actions.
27
Protections for real applications
Common Web Vulnerabilities and Their Effects
 SQL Injection
 The only parts of a query allowed to change are the arguments.
 SQL Injection attacks are mitigated.
 Cross-Site Request Forgery
 Mitigate CSRF attacks by requiring forms to carry CSRF tokens.
 Click Jacking
 Load web pages in a HTML frame and access using Javascript.
 Passe adds the X-Frame-Options header to all outgoing responses.
28
Evaluation
Case studies
 Social News Platform
 Social news service like Reddit.
 Users can submit stories, comments and votes them.
 CMS Platform
 Users can create and manage a blog.
 Support multiple authors, group and static pages.
 Web Forum
 Developers can run an online forum.
 Support user accounts, groups.
29
Performance evaluations
Latency
 Measure latency of requests
by repeatedly fetching
application pages with a
single user.
 Passe’s latency overhead is
not an excessive burden.
30
Performance evaluations
Throughput (TP)
 Apps with little I/O and no
database op, TP is reduced by
37%
 Apps require more I/O and
query, TP is reduced by 25%.
 The cost of Passe may vary
greatly.
31
Performance evaluations
Memory Overhead
 Passe adds memory overhead,
as each view requires a separate
OS process.
 Memory overhead is large.
 Do not increase significantly
under load.
32
Conclusion
 Passe provides security guarantees for applications.
 Passe decomposes applications into isolated views.
 Passe enforces the integrity of data queries and security policy.
 Passe prototype is capable of executing unmodified Django
applications with little performance overhead.
33
Q&A
34