AUTOMATICALLY SECURING DISTRIBUTED APPLICATIONS
A processing system for distributed multi-tier applications is provided. The system includes a server component that executes a replica of a client-side application, where a client component executes the client-side application. The client component captures events from the client-side application and transmits the events to the replica to validate the computational integrity security of the application.
Latest Microsoft Patents:
Due to the possibility of these attacks, almost every action in a typical shopping cart application today requires a round trip to the server, the latency of which can be quite noticeable, especially on mobile or long-distance connections. For non-malicious users, who constitute the majority, this unnecessary precaution leads to a much less responsive user experience. Moreover, the developer of the distributed application currently is responsible for splitting the application in a manner that places all security-sensitive operations on the server. While some language-based approaches have recently been proposed to address this problem, these techniques still require a great deal of developer involvement, making them difficult to use for existing large-scale projects.SUMMARY
The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview nor is intended to identify key/critical elements or to delineate the scope of the various aspects described herein. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
A distributed execution system is provided that employs replicated application execution to automatically preserve the integrity of distributed computations between client and server applications. The system replicates a copy of client-side computations on a trusted server tier and captures user events such as keyboard or other command inputs (e.g., text inputs from a cell-phone client application). The captured user-initiated events are transferred to an abstract replica of the client (operated at the server) for execution, where the system observes results of the computation, both as computed on the client-side and on the server side utilizing the replica of the client-side code. Any discrepancy between server side execution via the replica and client execution results that are sent via messages are flagged as a potential violation of computational integrity. Most existing approaches for ensuring integrity of client computation involve the client sending a proof of certain properties that its execution state holds. The server efficiently validates these proofs convincing itself of the integrity of the client execution. For instance, the client could periodically send over its stack traces to the server, and the server could check the traces for any properties it desires. These techniques only provide a partial enforcement of integrity of client execution. The distributed execution system provides a more complete solution where integrity is guaranteed under a reasonable set of design assumptions.
To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways which can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
Systems and methods are provided for validating security of remote applications. In one aspect, a distributed processing system for remote applications is provided. The system includes a server component that executes an abstract replica of a client-side application, where a client component executes the client-side application. It is noted that the replica only has to mimic the relevant details, but can omit many others such as the actual graphical rendering of the client-side user interface on the server, for example. The client component captures events from the client-side application and transmits the events to the replica to validate security of the client-side application. The events can be generated by a user or an application component. Security can be validated by comparing execution messages or observed states between the replica and the client side application.
As used in this application, the terms “component,” “application,” “event,” “replica,” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers. Also, these components can execute from various computer readable media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal).
Referring initially to
Concurrently, as the events 130 are transmitted to the replica 140, the replica executes as if it were the client application. The replica generates a subsequent message and submits the message to the checker 160. The checker 160 then compares the message generated by the replica 140 and the message 150 generated by the client component 110. If the messages are the same (or within some predetermined threshold) then the checker can notify the client and the server that security is valid. If the respective messages are different, the checker can notify the client and the server that a security error has been detected. If an error is detected, several actions can occur. Error notifications can cause the client and the server to shut down. In another aspect, a re-boot message could be transmitted to the client and the application could be restarted where further checks could be employed by the checker to determine if security is valid. In yet another aspect, the client component 110 could be notified that a previous message checked invalid and that a previous section or portion of an application would need to be re-executed. As can be appreciated, a plurality of differing actions could occur upon error detection.
When a portion of application code is moved to the client, a malicious user can easily subvert the client side of the computation and potentially jeopardize sensitive server states. The system 100 employs replicated execution to automatically preserve the integrity of a distributed computation. The system 100 replicates an abstract replica of the client-side computation on the trusted server tier 114. Client-side events 130 are transferred to the replica 140 of the client for execution. The system 100 observes results of the computation, both as computed on the client-side and on the server side using the replica 140 of the client-side code. Any discrepancy is flagged as a potential violation of computational integrity. It is noted that checking may occur online, e.g., concurrently when the application is executed, or after the fact, as part of security auditing. In general, substantially any segmented application is supported for security verification and validation by the system 100.
Referring now to
Volta generally requires the developer to declaratively define which portion of the application runs on the server 210 and which part on the client 220 with the help of class-level annotations. Tier-splitting is performed subsequently as a .NET byte-code rewriting pass that reads the placement annotations, introducing RPCs as needed. To implement the system, the Volta tier-splitter can be augmented to perform additional rewriting steps described below. Base Volta libraries can also be augmented to provide support for browser emulation. As noted previously, Volta provides one possible implementation of a tier-split application but other types of implementations are possible.
In general, the system 300 relies on re-execution to produce the correct result within C 330 based on user events that it receives, effectively ignoring malicious data changes that occur on the client 310. If the malicious changes result in different RPCs issued to the server 350, which constitutes the observable state, the checker 340 will flag a potential exploit and terminate that client's connection.
Primitive events 320 can be intercepted by registering a handler for each on the HTML BODY element. Since in the HTML event model, all events bubble up (or propagate) to the top-level document BODY element, it is a convenient point to intercept them. To intercept custom events 320, the system registers an extra handler shown in pseudo-code in code Fragment (B) above for each event of interest.
System-generated event handlers queue details about the event into an application-specific queue. In addition to the event type (key press, key release, and so forth), the serialized event details include the key code for keyboard-related events, mouse button information for mouse events, and so forth. Finally, the unique identifier corresponding to the object which raised the event can also be sent over.
Referring now to
An alternative approach consists of keeping audit logs for messages arriving from C and C′ and to perform periodic cross-checking. Moreover, if RPCs are large, sending the entire RPCs is unnecessary-to save bandwidth, simply compute Message Authentication Codes (MAC) and send them over. Since there could be multiple clients connected to the same server, the client replica C is executed in its own AppDomain, a lightweight process-like abstraction in the .NET runtime. At runtime, the system maintains a separate AppDomain associated with each user session, and looks it up when a batch of events is received from the client. An advantage of using separate AppDomains is memory isolation: each uses its own heap and loads its own copy of dynamically linked libraries and maintains its copy of global data structures. Moreover, cross-AppDomain communications are cheaper than inter-process communication in general as they do not require a process context switch and AppDomains can share DLLs.
Protection scheme for data manipulation: As mentioned above, the system uses re-execution to produce the correct result within the replica C based on user events that it receives, effectively ignoring malicious data changes that occur on the client. If the malicious changes result in discrepancies in the RPCs, this can cause the system to flag a potential exploit.
Protection scheme for code manipulation: Note that the system does not try to prevent code tampering in general; indeed, adding a semicolon that does not change the program semantics cannot be detected. However, the system prevents code modifications that result in different RPCs being issued by the client.
Protection scheme for script injections and worms: Referring to
In another aspect, program execution is considered deterministic. Allowing non-determinism will lead to differences in the execution of C and C′ that are not captured by the system, thus resulting in false positives. Fortunately, there is a way to “virtualize” sources of randomness that are discussed below. For instance, if a random number generator is used, the client can block its execution until it gets the random number from the server. Similarly, for a computation that accesses local time, the server component can block until the time measurement arrives from the client.
Referring now to
At 720, non-determinism is considered. Reliance of having non-deterministic execution specified can be removed through additional instrumentation. The following sources of non-determinism are most common in Web applications, discussed in turn below:
- Capturing user events
- Third-party interactions
At 730, Performance and Scalability is considered. Other system optimizations include: Actively “pushing” results to the client. An advantage of the system described above is that, once computed, RPC results can be actively pushed to the client. This way, when the RPC is finally issued on the client, its result will already be available, leading to low-latency RPCs. This demonstrates that not only does the system make the application more secure in many cases it can also make it more responsive. Deployment strategy for the system meshes nicely with the traditional load-balancing approach to deployment of large-scale Web applications. In particular, a load balancer could be used to repeatedly direct the same user to the server where both its replica and the corresponding server threads run. Currently, this functionality is implemented in the checker, which looks up the appropriate AppDomain for a user session. Moreover, to save memory, both the server thread and the replica can be serialized on high server load for long-running sessions and then brought back from disk.
Proceeding to 810, a client application replica is generated that is executable on a server that is remote from the client component or machine. As noted above, a tier-splitting application can be employed to generate the remote client application and the replica. At 820, client events are monitored and processed by the client component and by the replica. As noted previously, these can include keyboard activities, mouse activities, or substantially any input that alter the state of the remote client application. After the inputs events have been monitored, a message is generated that indicates how the client responded to the respective events. At 830, the message indicating client activity is transmitted to the server application. Concurrently to the client, the replica also processes the received events and generates its own execution message at 840. Proceeding to 850, the replica message and the client-generated message of 830 are compared. If the messages compare, execution of the remote application can continue in a substantially unimpeded manner. If a discrepancy is detected between messages at 850, error events can be generated. As noted previously, various responses to errors can be set up including retries, reboots, or prevention of further remote client activity until the source of the security violation is detected. Remote troubleshooting and guidance can be optionally generated and delivered to the user in order to help them determine the source of the respective security violation or other detected error. Alternatively, means of error recovery can be provided.
In order to provide a context for the various aspects of the disclosed subject matter,
With reference to
The system bus 918 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, 64-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
The system memory 916 includes volatile memory 920 and nonvolatile memory 922. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 912, such as during start-up, is stored in nonvolatile memory 922. By way of illustration, and not limitation, nonvolatile memory 922 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory 920 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).
Computer 912 also includes removable/non-removable, volatile/non-volatile computer storage media.
It is to be appreciated that
A user enters commands or information into the computer 912 through input device(s) 936. Input devices 936 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 914 through the system bus 918 via interface port(s) 938. Interface port(s) 938 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 940 use some of the same type of ports as input device(s) 936. Thus, for example, a USB port may be used to provide input to computer 912 and to output information from computer 912 to an output device 940. Output adapter 942 is provided to illustrate that there are some output devices 940 like monitors, speakers, and printers, among other output devices 940 that require special adapters. The output adapters 942 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 940 and the system bus 918. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 944.
Computer 912 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 944. The remote computer(s) 944 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 912. For purposes of brevity, only a memory storage device 946 is illustrated with remote computer(s) 944. Remote computer(s) 944 is logically connected to computer 912 through a network interface 948 and then physically connected via communication connection 950. Network interface 948 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL).
Communication connection(s) 950 refers to the hardware/software employed to connect the network interface 948 to the bus 918. While communication connection 950 is shown for illustrative clarity inside computer 912, it can also be external to computer 912. The hardware/software necessary for connection to the network interface 948 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
What has been described above includes various exemplary aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing these aspects, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the aspects described herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
1. A system for securing distributed applications, comprising:
- a server component that executes an abstract replica of a client-side application; and
- a client component that executes the client-side application, the client component captures events from the client-side application and transmits the events to the replica to validate the integrity of application execution.
2. The system of claim 1, the events are generated by a user or an application component.
3. The system of claim 2, the integrity is facilitated by comparing messages or observable states computed by the replica and received from the client-side application.
4. The system of claim 3, further comprising a checker to compare the messages computed by the replica and received from the client-side application.
5. The system of claim 3, further comprising a component to generate an error event if a discrepancy is detected between messages.
6. The system of claim 1, further comprising tier-splitting components to automatically generate the client-side application and the replica.
7. The system of claim 1, the replica provides minimal functionality of the client-side application in order to compute a desired integrity checking result from an event stream.
8. The system of claim 1, the client-side application is an asynchronous interpreted programming language based web application.
9. The system of claim 8, the client-side application is communicated with via one or more remote procedure calls.
10. The system of claim 9, the client-side application is translated into an interpreted programming language for execution within a web browser.
11. The system of claim 1, further comprising an event handler inserted into the client-side application through code rewriting.
12. The system of claim 1, further comprising an event handler inserted into the client-side application through runtime modifications.
13. The system of claim 1, further comprising a component to batch events to reduce performance overhead.
14. The system of claim 1, further comprising an audit log that is generated to compare messages or observable states between the client-side application and the replica.
15. The system of claim 14, the audit log is examined online in real time, examined at a later time, or provides a sample for further analysis.
16. The system of claim 15, further comprising a method authentication component that is transmitted in lieu of a complete message inside of a remote procedure call.
17. A method to validate security of a remote application, comprising:
- generating a replica of a remote client application;
- executing the replica in conjunction with the remote client application;
- monitoring events associated with the remote client application; and
- comparing results between the replica and the remote client application to validate security of the application.
18. The method of claim 17, further comprising automatically instumenting the remote client application to monitor user events and communications with third-party components.
19. The method of claim 17, further comprising generating a message to indicate an execution pattern for the remote client application.
20. A system for virtualizing script/bytecode execution across tiers, comprising:
- means for instrumenting user events;
- means for controlling third party interactions; and
- means for discovering sources of non-determinism.
Filed: Oct 24, 2008
Publication Date: Apr 29, 2010
Applicant: MICROSOFT CORPORATION (Redmond, WA)
Inventors: Benjamin Livshits (Kirtland, WA), Henricus Johannes Maria Meijer (Mercer Island, WA), Cedric Fournet (Cambridge), Jeffrey Van Gogh (Redmond, WA), Danny Van Velzen (Redmond, WA), Krishnaprasad Vikram (Ithaca, NY), Abhishek Prateek (New Delhi)
Application Number: 12/257,776