Download
dynamic information flow analysis for javascript in a web browser n.
Skip this Video
Loading SlideShow in 5 Seconds..
Dynamic Information Flow Analysis for JavaScript in a Web Browser PowerPoint Presentation
Download Presentation
Dynamic Information Flow Analysis for JavaScript in a Web Browser

Dynamic Information Flow Analysis for JavaScript in a Web Browser

135 Views Download Presentation
Download Presentation

Dynamic Information Flow Analysis for JavaScript in a Web Browser

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Dynamic Information Flow Analysisfor JavaScript in a Web Browser Tom Austin Software and Languages Research Group University of California at Santa Cruz

  2. How Can We Make JavaScript Secure? Bank.com XSS attack Analytics.com EvilAdServer.com f(accountNum); reportUsage(); AnotherAdServer.com getAd(url).display(); function fillForm()={…} ? var accountNum = …; AdServer.com passwords validate(accountNum); financial information Widgets.com

  3. Cross-Site Scripting (XSS):malicious injection of client-side code into web pages

  4. Stealing Browser History • Example attack: steal browsing history. • Browser history is protected, BUT it can be derived from the color of links. return [ decode(ebayLink.currentStyle.color==visited), decode(msnLink.currentStyle.color==visited), decode(aolLink.currentStyle.color==visited), decode(cnnLink.currentStyle.color==visited), decode(boaLink.currentStyle.color==visited), ];

  5. Current JavaScript Security • Same-origin policy: Limits a script’s access to different frames and windows • Browser-specific features • Signed scripts [Mozilla] • Secure zones [Internet Explorer] • JavaScript subsets • Facebook JavaScript (FBJS) • Google’s Caja

  6. Information Flow Security in a Browser Bank.com XSS attack Analytics.com EvilAdServer.com H L L L AnotherAdServer.com L L L AdServer.com H L Widgets.com

  7. Information Flow Analysis Overview • Track sensitive data as it flows through system. • Addresses dual problems of confidentiality (keeping data secret) and integrity (keeping tainted data from corrupting good data). • Focuses on the control flow of the program -- timing channels, back channels, etc. are out of scope.

  8. Explicit Flows • Information flows directly by assignment. • Related to taint analysis in Perl, Ruby, and PHP. • Below example attempts to leak secret to the public variable x. function decode(secret) { var x = secret; //BAD return x; }

  9. Implicit Flows function decode(x){ var y = false; if (x) y = true; return y; } • Data leaks through the control flow of the code. • The boolean value of x is returned in the field y, without direct assignment.

  10. Correctness Property:Termination-insensitive noninterference • Noninterference: Public outputs (L) do not depend on private inputs (H) • Termination-insensitive: Program may leak one bit through termination • Intermediary output channels may leak more through termination behavior, but the attacker is limited to a brute force attack (Askarov et al. 2008)

  11. Dynamic Analysis Static Analysis • Validation of code done on client • Validation usually done before run time • More information about current execution • Able to reason about complete program • Able to handle dynamic code evaluation • Easier to handle implicit flows?

  12. Challenge: Implicit Flows Standard Solution: The No-Sensitive-Upgrade Check

  13. Static Approaches to Implicit Flows function decode(x){ var y = true; var z = true; if (x) y = false; if (y) z = false; return z; } • Analysis ensures that private data does not affect public data. • In this example, y's final value depends on x. • [Denning 1976] NOT CERTIFIED

  14. Implicit Flow Example function decode(x){ var y = true; var z = true; if (x) y = false; if (y) z = false; return z; } x=falseH x=trueH How can we safely handle this assignment? falseL

  15. Simple-Upgrade (SU) Strategyfor Implicit Flows • Make a public variable private whenever it is modified in a private block of code. • Intuitive, but fails to defend against implicit flows.

  16. Implicit Flow Example:Simple-Upgrade Strategy function decode(x){ var y = true; var z = true; if (x) y = false; if (y) z = false; return z; } x=falseH x=trueH Partially leaked falseL trueL

  17. No-Sensitive-Upgrade (NSU) Strategy for Implicit Flows • Forbid assignment to public variables in private code. [Zdancewic 2002] • Defends against implicit flows. • Rejects some valid program executions.

  18. Implicit Flow Example:NSU Strategy function decode(x){ var y = true; var z = true; if (x) y = false; if (y) z = false; return z; } x=falseH x=trueH STUCK falseL

  19. The Importance of Termination return [ decode(ebayLink .currentStyle .color==visited), decode(msnLink .currentStyle .color==visited), decode(aolLink .currentStyle .color==visited), ]; • Simple-upgrade strategy: all variables are decoded and returned to the attacker. • No-sensitive-upgrade strategy: the attacker only knows whether all variables are false.

  20. Challenge: Ease of Use Our Solution: Permissive-Upgrades

  21. No-Sensitive-UpgradeFalse Alarms var name = emp.name; if(emp.isDoctor()){ name = "Dr. " + name; debug("Bonus for "+name;) emp.salary += phdBonus; } return emp;

  22. Permissive-Upgrade Strategy Tolerates Partially Leaked Data • The no-sensitive-upgrade approach gets stuck when data is partially leaked. • Partially leaked data (labeled P) is: • Private on this execution • Possibly public on an alternate execution

  23. Updated Security Lattice • The permissive-upgrade strategy permits partially leaked data (P) and adds it to the security lattice. • Partially leaked data must be treated more carefully than private data (H). • Critically, joining H-data with P-data results in P-data: P H "a"H + "b"P = "ab"P L

  24. The Permissive-Upgrade Approach var name = emp.name; if(emp.isDoctor()){ name = "Dr. " + name; debug("Bonus for "+name;) emp.salary += phdBonus; } return emp;

  25. Implicit Flow Example:Permissive-Upgrade Strategy function decode(x){ var y = true; var z = true; if (x) y = false; if (y) z = false; return z; } x=falseH x=trueH STUCK falseL

  26. Privatize Partially Leaked Data • The permissive upgrade semantics still results in some stuck executions. • The programmer can add privatization operations (<H>) of values at critical points. • Since the value is made private on both branches, private data remains secure. <H>3P <H>3H 3H <H>3L

  27. Implicit Flow Examplewith Privatization Operation function decode(x){ var y=true; var z=true; if (x) y=false; if ( y) z=false; return z; } x=falseH x=trueH falseP trueL

  28. Privatization Inference • When an execution would get stuck, we infer the needed privatization operation for future reference. • The needed operations can be discovered with minimal developer effort.

  29. Implicit Flow Example:Privatization Inference function decode(x){ var y=true; var z=true; if (x) y=false; if ( y) z=false; return z; } x=falseH x=trueH STUCK falseL

  30. Implicit Flow Example:Privatization Inference function decode(x){ var y=true; var z=true; if (x) y=false; if (<H>y) z=false; return z; } x=falseH x=trueH falseP trueL

  31. Permissive-Upgrade Summary • Accepts more valid program executions than the no-sensitive-upgrade approach. • Privatization operations help prevent stuck executions. • Privatization inference can determine privatization operations automatically.

  32. Challenge: Ease of Use Alternate Proposed Solution: Faceted-Value Evaluation

  33. Faceted-Value Evaluation • Instead of tagging security labels to values, store a high value and a low value. • When a variable is updated in a private context, only its high value is updated. • Authorized channels receive the correct values; untrusted channels receive stale/dummy values. v={"L. McCoy","Dr. L. McCoy"}: • output(v, L)  "L. McCoy) • output(v, H)  "Dr. L. McCoy) • Related to Secure Multi-execution [Devriese & Piessens 2010]

  34. Implicit Flow Example:Faceted-Value Evaluation false function decode(x){ vary=true; varz=true; if (x) y=false; if (y) z=false; return z; } {false,false} {false,true} false {false,true}

  35. Challenge: Performance Our Solution: Sparse Labeling

  36. Does Performance Matter for JavaScript? • Applications have grown in size (Ajax, Gmail, etc.) • Browser designers spend a great of attention on the speed of their JavaScript implementations. JavaScript implementations have grown tremendously faster, but…

  37. SunSpider (Apple’s benchmark) • Shorter is better • http://www2.webkit.org/perf/sunspider-0.9/sunspider.html

  38. Mozilla’s benchmark • http://dromaeo.com • Green is best Safari Firefox Opera IE8

  39. V8 benchmark • http://v8.googlecode.com • Longer is better • Results reported by CNET

  40. Independent test • http://celtickane.com/labs/web-browser-javascript-benchmark/

  41. a = b + c a b join + c

  42. Label Locality: DOM Tree Example <body>: {Top} <div>: {Top} <p>: {Top} <div>: {Bank.com} <h1>: {Top} <a>: {Top} <div>: {Widget.com} <span>: {Bank.com} <table>: {Bank.com} <form>: {Widget.com} <button>: {Widget.com} <strong>: {Bank.com} <td>: {Bank.com} <td>: {Bank.com}

  43. Implicit Labels • By exploiting label locality we can leave labels implicit. • We can omit the label on a value whenever it is subsumed by the program counter (pc). Universal labeling Sparse labeling Labeled data Unlabeled data

  44. Removing Unnecessary Labels <body>: {Top} <div>: {Top} <p>: {Top} <div>: <h1>: {Top} <a>: {Top} <div>: {Bank.com} {Widget.com} <span>: <table>: <form>: <button>: {Bank.com} {Bank.com} {Widget.com} {Widget.com} <strong> <td>: <td>: {Bank.com} {Bank.com} {Bank.com}

  45. Two Cases {Widget.com} First( ) => {Widget.com} 1 1 2 First( ) => 1 1 2

  46. Slow-path vs. Fast-patha = b + c a b a b join + + c c

  47. Semantics of Unary “-” if (JSVAL_IS_INT(rval)&&(i=JSVAL_TO_INT(rval))!=0) { //FAST PATH i = -i; regs.sp[-1] = INT_TO_JSVAL(i); } else { if (JSVAL_IS_DOUBLE(rval)) { //LESS-FAST PATH d = *JSVAL_TO_DOUBLE(rval); } else { //SLOW PATH ... //Implicit conversions //IDEAL SPOT FOR HANDLING LABELED DATA ... //Error handling } d = -d; ... }

  48. Challenge: Information Flow Policy Here there be dragons…

  49. Open Policy Questions • What should the security lattice be? • What data should be confidential? • What channels can an attacker use to leak data? • How can we test these policies?