Static Checking of Dynamically-Varying Security Policies in - PowerPoint PPT Presentation

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

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

Authentication Snafus 3

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

Dynamic Checking Output to User Database Program Variable Sensitive Datum Program Program Variable Variable Store security information with values Check before interaction with environment. 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 5

Static Checking Sensitive Datum High Security Low Security Output to User Type Database Type Program Variable Type Type Type Program Program Variable 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 6

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

A Word About Ur/Web Integrated parsing and queryX (SELECT * FROM t) type-checking of SQL (fn row => <xml><tr> and HTML <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>); 8

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

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

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

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

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

Understanding SQL Usage policy sendClient Prove: (SELECT Secret ∀ v. mightSend(v) FROM Secrets, Users ⇒ allowed(v) WHERE Owner = Users.Id known (U, P) AND known(Password)) ∀ 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. 14 s.Owner = U ∧ v = s.Secret

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

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

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

Case Studies 18

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

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