Ripley: Automatically Securing Web Applications through Replicated Execution - Research Paper Example

?Summary Distributed multi-tier AJAX based web applications (Facebook, Google Maps, Hotmail, etc have made their ground in the present day Internet. The server tier of these applications is usually implemented in Microsoft .NET or Java J2EE while the client tier runs JavaScript within the client’s browser. Through this, a portion of computation is brought closer to the client saving network roundtrips by sparing the server for involvement in trivial computations. When necessary, small grained requests can be made instead of downloading entire HTML pages. Within this setting of web applications, the code and data that originates at the client’s machine and browser cannot be trusted as any malicious client can easily tamper with it. A remedy could be, splitting the code in a way such that the security sensitive computations are carried out on the server. However, this demands excessive code digging and annotating from the developers. Alternatively, manual validation on server side can be considered. However, maintaining responsiveness at client’s end alongside would be considerably challenging. The paper presents an alternative and easy solution in form of RIPLEY through which the integrity of server is ensured. RIPLEY is based on the idea that the computations that are executed at the client end are re-executed on the server. RIPLEY replicates the computations on the client tier onto the server tier. The events of every client are recorded and relayed to RIPLEY, which then re-computes and compares the results with those that were generated at the client. In case of matching discrepancies, a violation of computational integrity is noted and the connection with client is terminated. No matter how the code is split, RIPLEY ensures integrity, thus saving the developers from lengthy code analysis and partitioning process. RIPLEY can be integrated with the server cloud where it deploys automatically performing the three basic steps; capture events from browser, transmit the events to server and compare the results of client and server. Through RIPLEY, any code changes or malicious data is ignored. RIPLEY however does not provide input sanitization. The process of code replication is simplified when RIPLEY is integrated with Volta, a distributing compiler that provides narrow standardized API and DOM. Through Volta the need of copying the browser specific details into the replica is overruled. Communication of RIPLEY across different tiers can be achieved through RPC provided in Volta infrastructure. Volta is believed to preserve the original semantics while translating. If the application involves interacting with database at the server, introducing RIPLEY would not change anything. As computations are repeated, a burden is posed on the server in form of CPU time and memory. Owing to the transmission of events, some degree of network overhead is also expected when using RIPLEY. In view to the CPU overhead, the client replicas are run in .NET on the server, which is considerably faster than JavaScript. In view to the memory overhead, the replica is run within a lightweight headless browser emulator rather than a full fledge browser. In view to the network traffic, the transfer of events is combined with the existing RPC inside the same network packet. Rather than the full replication of client as done in the paper, partial replication can also be done in view to the overheads of RIPLEY. In some cases, use of RIPLEY increases the overall performance and responsiveness as the code executed on server are faster than in clients. Use of push technology the RPC results can be pushed to the browser resulting in 0-latency RPCs. The original .NET application is fed into Volta. Volta tier splits it into server application and the client replica and optionally the JavaScript based client tier. It replaces any cross tier calls with AJAX RPCs. All data transfers between server and client are serialized which de-serialized on receipt. The event capturing JavaScript code is added to the client tier. The custom and primitive events are intercepted by RIPLEY and transferred to the replica. In order to reduce the network bandwidth and avoid bottlenecks, the events are asynchronously relayed to the server in form of batches. The events are batched till the queue reaches the maximum size of network packet. When that happens, the batch is transmitted to the server. Otherwise the transmission takes place on a RPC call wherein the events are flushed from the queue to the server. RIPLEY changes the server binary to be able to appropriately handle the events that come from the client and relaying them to the client replica for replaying the actions. These events are de-serialized from the wire before relaying them to the replica. RIPLEY captures the RPCs that come from the replica as well as the JavaScript client and records them into audit logs. The checking is performed in cases where the malicious client needs to be detected. The RPCs are relayed to the application server code only when the two RPCs are equal. RIPLEY then intercepts the server response in form of a string at the HTTP levels and relays copies of it to both the replica and the client. In cases where the need to detect malicious clients is absent, RIPLEY can be set to ignore the RPCs from the JavaScript client altogether and relay only the RPC of the replica to the server. In another setting, RIPLEY can directly forward the RPC from the client replica to the server and send its response back to the client. When the RPC from the JavaScript client arrives, the server can match the two RPCs to see its equivalence. This setting is generally used in scenarios where the clients are slow. In yet another setting, the audit logs are maintained wherein the two RPCs are recorded. And the checking is done at random intervals. In this case however, the integrity of server would be probabilistic. Furthermore, in case of large sized RPCs, instead of transferring RPCs, the Message Authentication Codes can be calculated and sent over to conserve network bandwidth. As there would be multiple clients connected to the server in an instant, RIPLEY maintains a separate APPDOMAIN for every client replica that runs on the server. Each client has its own isolated memory with separate dynamic linking and data structures. In order to evaluate the overhead and effectiveness of RIPLEY, it was tested on five Volta applications that were security sensitive namely Shopping Cart, Game of Suduko, Blog Typing Test and Online Quiz. Some predetermined events were executed on all these applications. In view to the network bandwidth, although the number of events for the Blog and Speed Typing applications was more, yet as the RPCs were sent asynchronously, the client side performance did not slow down. Furthermore, the size of the events can be reduced substantially to only a few bytes on the wire through compression. However, presently compression is not supported for HTTP requests in browsers. In view to memory consumption, the applications were tested with and without RIPLEY on two browsers (Internet Explorer and Firefox). It was found that total memory overhead was 5MB owing to the limited browser features of Volta. When multiple instances of clients were replicated, since all the clients shared libraries, only additional 1.3MB was added to the memory overhead. In view to CPU overhead, RIPLEY does add an overhead on the server as well as client. As the RPCs are sent in bulks, RIPLEY takes time to check for integrity. However, during the checkout of Shopping cart and finish of Suduko, overhead is maximum as the RPC is sent in bulk. While for the Blog and Game the overhead is maximum in the start when the entries and questions are retrieved from database on server. At other instants the latency is negligible. On the client side, the event capturing operation adds overhead to the browser. In order to assess the scalability aspect of RIPLEY, the client portion of Hotmail was replicated. Although there was an overhead in network bandwidth (0.4%), memory (1.75MB per client) and computation, yet the overhead due to replication was considered to be acceptable. The paper presented RIPLEY from the context of Volta compiler. The idea of replication can however be extended to various other environments as well (Flash, Silverlight, or server side JavaScript). RIPLEY is completely applicable to Silverlight, Flash besides AJAX applications. Reference K.Vikram, Abhishek Prateek, and Ben Livshits (2009). Ripley: Automatically Securing Web 2.0 Applications Through Replicated Execution. In Proceedings of the Conference on Computer and Communications Security, Association for Computing Machinery, Inc. Read More