SECURE WEB APPLICATIONS VIA AUTOMATIC PARTITIONING

1
SECURE WEB APPLICATIONSVIA AUTOMATIC PARTITIONING

• S. Chong, J. Liu, A. C. Myers, X. Qi, K. Vikram,
  L. Zheng, X. Zheng
• Cornell University

2
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

3
Main hypotheses

• Servers can be trusted
• Clients cannot
• We cannot update ourselves the balances of our
  bank accounts

4
Security Model

• Swift enforces security by controlling
  information flow
• Prevents release of information toless secure
  consumers
• Will not accept information fromless trusted
  sources

5
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

6
ARCHITECTURE
7
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

8
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

9
WebIL Optimization

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

10
Splitting Code

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

11
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
12
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

13
WRITING SWIFT APPLICATIONS
14
Labels and Principals

• int alice ? alice, bob bob ? alice y
• Describes two policies that apply to y
• alice ? alice, bobmeans that alice restricts
  release of information to herself and bob
• bob ? alicebob trusts the information and
  believes only alice should modify it

15
Labels and Principals

• int alice ? alice, bob bob ? alice yint
  bob ? bob xint alice ? bob bob ? alice
  zif (x 0) z y
• Which conditions would make this code secure?
• Let us consider the flow of information from y to
  z

16
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

17
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)

18
Built-in principals

• The server
• Maximally trusted principal in the system
• Client
• Trusts the server completely acts for client

19
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

20
An example (II)

• Variable secret is declaredint ? , ?
  secret
• Secret
• Only the server can update it
• Variable tries is declaredint ? client, ?
  tries
• Not secret
• Only the server can update it

21
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 operationendorse( i, ?
  client to ? )
• Raises the trust granted to some information

22
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 operationdeclassify( ?
  to ? client)
• Lowers the secrecy level assigned to some
  information

23
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

24
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

25
Performance

• Number of roundtrips is critical factor
• Still higher number than optimum
• System is not fully optimized

26
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 variablein
real applications