SECURE WEB APPLICATIONS VIA AUTOMATIC PARTITIONING S. Chong, J. Liu, A. C. Myers, X. Qi, K. Vikram, L. Zheng, X. Zheng Cornell University

INTRODUCTION Designers of web applications –Want to push as much as possible application functionality into the clients –Must protect application integrity against rogue clients Paper presents a “principled approach” to building secure web applications –“Secure by construction”

Main hypotheses Servers can be trusted Clients cannot – We cannot update ourselves the balances of our bank accounts

Security Model Swift enforces security by controlling information flow –Prevents release of information to less secure consumers –Will not accept information from less trusted sources

Overall Organization Applications are written in a higher-level programming language that details all security requirements as annotations Compiler uses these annotations to decide whether an application and its data can run on the client –Partitions code and data at the level of individual expressions and object fields

ARCHITECTURE

Jif source code Written in an extension of Jif 3.0 programming language Jif is itself an extension of Java with specific mechanisms for information flow control and access control – Expressed in Jif as labels attached to program variables

WebIL Intermediate Code Intermediate language with much simpler annotations –S means annotated code/data must be placed on the server –S?C means annotated code/data must be placed on the server but can be replicated on the client

WebIL Optimization Second phase produces exact placement and replication of code and data –Satisfying all security requirements –Minimizing costs and avoiding unnecessary network messages

Splitting Code Fine grain transformation –Some statements within a specific method may run on the client while other statements must remain on the server

JavaScript Output Jif/WebIL generate Java code to run on the client Converted to JavaScript using the Google web toolkit Final code uses an Ajax approach Ajax web applications can retrieve data from the server by issuing their own HTTP requests

Partitioning and Replication Can have same computations running simultaneously on the server and the client to improve responsiveness and security Has been done manually often using different languages –Can introduce inconsistencies Swift replicates a single piece of code

WRITING SWIFT APPLICATIONS

Labels and Principals int {alice → alice, bob; bob ← alice} y; –Describes two policies that apply to y alice → alice, bob means that alice restricts release of information to herself and bob bob ← alice bob trusts the information and believes only alice should modify it

Labels and Principals int {alice → alice, bob; bob ← alice} y; int {bob → bob} x; int {alice → bob; bob ← alice} z; if (x == 0) { z = y}; –Which conditions would make this code secure? –Let us consider the flow of information from y to z

Security Conditions For every confidentiality policy on y, there is one at least as restrictive on z –True for the example For every integrity policy on z, there is one at least as restrictive on y –True for the example Must also consider implicit flows of data

Implicit Information Flows As in – if (x == 0) { z = …}; For the code to be secure, the security policy of z should be at least as restrictive as that of x –No true in example as the security policy of z is not as restrictive as that of x –Must add that bob trusts alice completely (“alice acts for bob”)

Built-in principals * : –The server –Maximally trusted principal in the system Client: –Trusts the server completely: * acts for client

An example (I) Game makeGuess: –Client must guess a secret number between 1 and 10 in less than maxtries tries –Secret number must remain secret until the game ends –Variable counting the number of tries is not secret but should not be modified by client

An example (II) Variable secret is declared int { * → *,* ← *} secret; –Secret –Only the server can update it Variable tries is declared int { * → client,* ← *} tries; – N ot secret –Only the server can update it

First problem Each guess is proposed by the client –Cannot be trusted –Must be passed to the server to be compared by server to secret value Swift has an endorse operation endorse( i, { * ← client } to {* ← *} ) –Raises the trust granted to some information

Second problem Value of secret number –Must remain secret until the client guesses it –Correct guess results in an implicit transfer of information to client Swift has an declassify operation declassify( {* → *} to { * → client } ) –Lowers the secrecy level assigned to some information

Comments Endorse and declassify operations are inherently dangerous –Must always be explicit Swift controls their use by requiring that they occur in code marked as trusted by the affected principal

Evaluation Swift compiler adds 36,000 lines of “real” code to the Jif compiler Server and client runtime systems are 3,000-line long each Porting the Jif runtime system into WebIL resulted into 2,800 lines of code

Performance Number of roundtrips is critical factor: –Still higher number than optimum –System is not fully optimized

Conclusion Swift achieves its three important goals of –Enforcement of information security –Responsive user interface –Uniform general-purpose programming model Experience will tell how easy it will be to specify the correct labels of each variable in real applications