1. Static Checking of Dynamically-Varying Security Policies in Database-Backed Applications
Adam Chlipala
OSDI 2010

2. Beyond Code Injection Injection Cross Site Scripting
Broken Authentication and Session Mgmt.
Insecure Direct Object References
Cross Site Request Forgery
Security Misconfiguration
Insecure Cryptographic Storage
....
An application includes an unintended run-time program interpreter
Dependent on application-specific authentication and access control regimes!

3. Authentication Snafus

4. Roads to Security Attack vector #1 Attack vector #2 Audit Resource
Security Policy
Resource
Surprise attack
Attack vector #3
Information flow:
who can learn what
Access control:
who can change what

5. Dynamic Checking Pros Easy to add to existing programs
Output to User
Program Variable
Store security information with values
Sensitive
Datum
Check before interaction with environment.
Program Variable
Program Variable
Pros
Easy to add to existing programs
Flexibility in coding security checks
Cons
Bugs are only found for program paths that are tested.
Performance overhead

6. Static Checking Pros Checks all program paths at compile time
Sensitive
Datum
High Security
Low Security
Output to User
Type
Program Variable
Type
Type
Type
Type
Program Variable
Program Variable
Subtyping check
Pros
Checks all program paths at compile time
No changes to run-time behavior required
Cons
Usually requires extensive program annotation
Limited policy expressiveness

7. The Best of Both Worlds UrFlow analysis Like Dynamic Checking:
No program annotations required
Flexible and programmer-accessible policy language (SQL)
Like Security Typing:
Checks all program paths statically
No run-time overhead
The
UrFlow
analysis
for the
Ur/Web
programming
language

8. A Word About Ur/Web queryX (SELECT * FROM t)
Integrated parsing and type-checking of SQL and HTML
queryX (SELECT * FROM t)
(fn row => <xml><tr>
<td>{[row.T.A]}</td>
<td>{[row.T.B]}</td>
<td>{[row.T.C]}</td>
<td>{[row.T.D]}</td>
<td><form><submit
action={delete row.T.A}
value="Delete"/>
</form></td>
</tr></xml>);

9. Client may learn anything this query could return.
Simple Policies Id
Name
Secret
Secrets
Client may learn anything this query could return.
policy sendClient
(SELECT Id, Name
FROM Secrets)

10. Reasoning About KnowledgeId
Name
Secret
Code
Secrets
policy sendClient
(SELECT *
FROM Secrets
WHERE known(Code))

11. What is “known”? known: “foo” 42 n v (U, P) (“foo”, n) (42, v) U P
App source
Web page that generated this request
Cookies
AUTH
(Username, Password)
= (U, P)
“foo” n 42 v
known:
“foo” 42 n v
(U, P)
(“foo”, n)
(42, v) U P
((42, v), P)

12. Multi-Table Policies policy sendClient (SELECT SecretId
Name
Secret
Owner
Secrets Id
Name
Password
Users
policy sendClient
(SELECT Secret
FROM Secrets, Users
WHERE Owner = Users.Id
AND known(Password))

13. Understanding SQL Usage
Program Execution
...
(U, P) = readCookie(AUTH);
pass = SELECT Password
FROM Users
WHERE Id = U;
if (pass != P) abort();
rows = SELECT Secret
FROM Secrets
WHERE Owner = U;
// Send rows to client....
known (U, P)
∃ u ∈ Users. u.Id = U ∧ u.Password = P
∀ v. mightSend(v) ⇒ ∃ s ∈ Secrets.
s.Owner = U ∧ v = s.Secret

14. Understanding SQL Usage
policy sendClient
(SELECT Secret
FROM Secrets, Users
WHERE Owner = Users.Id
AND known(Password))
Prove:
∀ v. mightSend(v)
⇒ allowed(v)
known (U, P)
∀ s ∈ Secrets. ∀ u ∈ Users.
s.Owner = u.Id ∧ known(u.Password)
⇒ allowed(s.Secret) ∧
∃ u ∈ Users. u.Id = U ∧ u.Password = P ∧
∀ v. mightSend(v) ⇒ ∃ s ∈ Secrets.
s.Owner = U ∧ v = s.Secret

15. Automated Theorem-Prover
UrFlow Sketch
Program Code
Policies (SQL)
Finite set of execution paths
Policies
(First-Order Logic)
P2 /\ policies => Q1
Symbolic executions
State: P1 P2 P3
... PN
Check: Q1 Q2
Automated Theorem-Prover

16. Fancier Policies policy sendClient (SELECT Body
Forum
Body
Messages
Forum
User
Level
ACL Id
Password
Users
policy sendClient
(SELECT Body
FROM Messages, ACL, Users
WHERE ACL.Forum = Messages.Forum
AND ACL.User = User.Id
AND known(Password)
AND Level >= 42)

17. Write Policies policy mayInsert (SELECT * FROM Secrets AS New, UsersId
Name
Secret
Owner
Secrets Id
Name
Password
Users
policy mayInsert
(SELECT *
FROM Secrets AS New, Users
WHERE New.Owner = Users.Id
AND known(Password)
AND known(New.Secret))

18. Case Studies

19. Progress UrFlow Imperative programs are too hard to analyze!
Just use declarative languages, and your life will be so much easier.
App
Maybe later. I'm going to get back to coding my web application, which does almost nothing besides SQL queries.
Programming Languages Researchers
Practitioners
UrFlow

20. Ur/Web Available At: http://www.impredicative.com/ur/
Including online demos with syntax-highlighted source code