Ripley: Automatically Securing Web 2.0 Applications Through Replicated Execution

1. Ripley: Automatically Securing Web 2.0 Applications Through Replicated Execution Authors: K. Vikram AbhishekPrateek Benjamin Livshits Presented by: Wenji Chen

2. Web 1.0 vs. Web 2.0 • Computation happens on server-side. • Synchronous page request and response • Reload page • Move a portion of computation to the client-side. • Asynchronous data request and response • Update parts of the page without the client’s notice

3. Motivation for Ripley • Move a portion of computation on the server side to the client side • Application is more responsive more friendly app • The portion of code and data on the client side is vulnerable to malicious users.  loss of security! • How to restore the loss of integrity caused by a portion of code moving to the client-side? • The server replicates the computation happening on the client-side, and checks for integrity. • Replicate and replay

4. Performance vs. Security Ripley focuses on integrity, not confidentiality. Ripley doesn’t tend to protect against attacks like Cross Site Scripting, SQL injection.

5. Ripley Architecture Keep a replica of client code on server side Capture and send user events(key strokes, mouse clicks) to server and replay Compare server and client results to check integrity

6. Handle with events on client-side • Events are classified into two kinds • Primitive events • Include each key press and mouse click • Ripley intercept them by registering a handler for each • Custom events • Only those that the app has registered explicit handlers for • Ripley register an extra handler for each • Event transfer • Eager excess network usage, but speedy replication • Lazy minimal network usage, but delayed replication • Middle-path  batch the events until reaching the max size of a network packet

7. Feasibility • Use distributed compiler VOLTA for app development • Split the .NET code into server&client parts • Modify the client part into a replica of client part on server-side • Translate the client parts into JavaScript to be run in browser .NET S C C’ VOLTA C JavaScript Replica

8. Performance and Scalability • Replica running on server-side • CPU • Memory • Network overhead •  let replica run in .NET which is faster than JavaScript • use browser emulator to run replica, which doesn’t care about page rendering or layout. •  asynchronously transfer client-side events to server-side (0-latency RPCs) • compress the event data transferring between server and client •  MAC-ing RPCs

9. Experimental Results • Overhead measurements on VOLTA app • Shopping cart • Game of Sudoku • Blog app • Speed Typing Test • Online Quiz • CPU: • Client: several ms added for event capture • Server: several ms added for integrity checking • Memory: • About 1MB per connected client • Can scale to 100’s of clients per server • Network: • 120 bytes per client-side event, uncompressed • 3-4 bytes per client-side event, compressed

10. Implementation Issues • Non-determinism • Random family of functions [Math.Random] • Block them on client-side and request from server • Reading and measuring time • Block them on client-side and request from server • Accessing third-party servers • Assumption: client-side code does not interact with other JavaScripts • Interoperate with plugins • Ripley is targeting standalone deployment of a Ripley app within an HTML frame.

11. Discussion • When part of the workload is delegated to the clients, replication in Ripley cannot scale very well. • Distributed online game • Ripley ensures the integrity of distributed computation which is based on the event transferring and replaying, but how about the integrity of event itself ?

12. Thanks for your attention! Questions?