Aaron Blankstein and Michael J. Freedman Princeton University Tuan Tran

Introduction How to solve those threats? Source:

Presentation Outline Security goals and assumptions Passe design Passe runtime in web setting Passe analysis phase Implementation Evaluations 3

Security goals and assumptions 4 Threat Model Developers supply non-malicious application code. Attackers are unable to compromise the trusted components. Passe’s trusted components provide very simple functionality.

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 8 Apps are decomposed into isolated views. Views handle specific requests. Passe introduces a stateless proxy between the service and storage tiers

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 15 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.

Passe runtime in web setting 16 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.

Passe runtime in web setting 17 An end user’s browser presents a significant attack channel. Cross-view attack channel

Passe runtime in web setting 18 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.

Passe runtime in web setting 19 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.

Passe analysis phase 20 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

Passe analysis phase 21 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.

Passe analysis phase 22 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.

Passe analysis phase 23 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.

Passe analysis phase 24 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.

Implementation 25 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.

Implementation 26 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.

Protections for real applications 27 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.

Protections for real applications 28 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.

Evaluation 29 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.

Performance evaluations 30 Latency Measure latency of requests by repeatedly fetching application pages with a single user. Passe’s latency overhead is not an excessive burden.

Performance evaluations 31 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.

Performance evaluations 32 Memory Overhead Passe adds memory overhead, as each view requires a separate OS process. Memory overhead is large. Do not increase significantly under load.

Conclusion 33 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.

Q & A 34