Ajax Security

Slide 1: Is This On?

Slide 2: A jax S ecurity Douglas Crockford Yahoo! javascript.crockford.com/security.ppt

Slide 3: S ecurity The number 1 biggest problem with the whole World Wide Web.

Slide 4: The browser is not a safe programming environment. It is inherently insecure.

Slide 5: What can an attacker do if he gets some script into your page?

Slide 6: A n attacker can request additional scripts from any server in the world. Once it gets a foothold, it can obtain all of the scripts it needs.

Slide 7: A n attacker can make requests of your server. Y our server cannot detect that the request did not originate with your application.

Slide 8: A n attacker can read the document. The attacker can see everything the user sees.

Slide 9: A n attacker has control over the display and can request information from the user. The user cannot detect that the request did not originate with your application.

Slide 10: A n attacker can send information to servers anywhere in the world.

Slide 11: The browser does not prevent any of these. That's why they happen.

Slide 12: The consequences of a successful attack are horrible. Harm to customers. Loss of trust. Legal liabilities. Possible criminal penalties.

Slide 13: This is not a Web 2.0 problem. A ll of these problems came with Netscape 2 in 1995.

Slide 14: The Turducken Problem • M any L anguages: • HTTP, HTM L , URL , CS S , JavaS cript, X M L , JS ON, plaintext, S QL ... • E ach language has different quoting and commenting conventions. • The languages can be nested inside each other.

Slide 15: A text that is benign in one context might be dangerous in another. S loppy encoding allows injection of evil scripts

Slide 16: A S imple A ttack http://yourdomain.com/ <script>alert(\"XSS\");</script> <html><body> <p>File not found: <script>alert(\"XSS\");</script> </p></body></html> • The script runs with the authority of your site.

Slide 17: A S imple A ttack http://yourdomain.com/ <script>alert(\"XSS\");</script> <html><body> <p>File not found: <script>alert(\"XSS\");</script> </p></body></html> • Proper escapement provides some safety.

Slide 18: A nother E xample • B ad text \" + alert(\"XSS\") + \" • B ad encoding {\"json\": \"\" + alert(\"XSS\") + \"\"} • Good encoding {\"json\": \"\\\" + alert(\\\"XSS\\\") + \\\"\"}

Slide 19: Coding hygiene is critical for avoiding turducken attacks. Use good encoders. json.org/json2.js Do not use simple concatenation. Never trust the browser. V alidate all input.

Slide 20: Cross S ite Data A ccess It is extremely useful to obtain data from other sites and mash it up.

Slide 21: S ame Origin Policy Prevents useful things. A llows dangerous things.

Slide 22: S cript Tag Hack • S cripts (strangely) are exempt from S ame Origin Policy. • A dynamic script tag can make a GE T request from a server. receiver(jsontext); • E xtremely dangerous. It is impossible to assure that the server did not send an evil script.

Slide 23: JavaS cript's Global Object The root cause of X S S attacks. A ll scripts run with the same authority.

Slide 24: JavaS cript is an insecure language. The E S 4 Proposal is even worse. It should be abandoned.

Slide 25: Document Object M odel A ll nodes are linked to all other nodes and to the network.

Slide 26: Cookies A mbient authority leads to confusion and impersonation (X S RF )

Slide 27: Remedy: Crumbs A n explicit secret should be sent with the ambient cookie. F rustrates X S RF attacks. Not effective against X S S attacks.

Slide 28: E xcellent Code Quality If code is clean and readable, it is less likely to contain insecurities.

Slide 29: JS L int • JS L int defines a professional subset of JavaS cript. • It imposes a programming discipline that makes me much more confident in a dynamic, loosely-typed environment. http://www.JSLint.com/

Slide 30: Warning! JS Lint will hurt your feelings.

Slide 31: If the web as been totally screwed up from the beginning, why should we worry about it now? 1. Escalating legal penalties 2. M ashups 3. Competition

Slide 32: M ashups The most interesting innovation in software development in 20 years.

Slide 33: M ashups are insecure. M ashups must not have access to any confidential information.

Slide 34: If there is script from two or more sources, the application is not secure. Period.

Slide 35: A dvertising is a mashup.

Slide 36: Competition to displace the web. S ilverlight. A IR. JavaFX.

Slide 37: That would'nt be the end of the world. It would just be the end of the WWW.

Slide 38: A Three Prong S trategy to Fix the Web 2. S afe JavaS cript subsets. 3. S mall browser improvements. 4. M assive browser improvements. • This could take a while, so we should proceed on all three immediately.

Slide 39: 1. S afe JavaS cript S ubsets. The easiest way to improve JavaS cript is to make it smaller.

Slide 40: A Dsafe • A JS L int option. • It defines a safe HTM L /JavaS cript subset. • Removes from JavaS cript all features that are unsafe or suspect. • A llows foreign ads and widgets to safely interact.

Slide 41: A Dsafe • No global variables or functions may be defined. • No global variables or functions can be accessed except the ADSAFE object. • The [] subscript operator may not be used. • These words cannot be used: apply call callee caller clone constructor eval new prototype source this toSource toString watch • Words starting with _ cannot be used.

Slide 42: Dangers • There may still be undiscovered weaknesses in E CM A S cript and its many implementations. • B rowser implementations are changing, introducing new weaknesses. • The DOM wrappers must be flawless. • We are still subject to X S S attacks.

Slide 43: 2. A dd S imple Features to the B rowsers. E ven simple improvements can take a long time to distribute.

Slide 44: JS ONRequest for safe data interchange.

Slide 45: V ats Communicating computational containment vessels

Slide 46: HTM L Provides No M odules • It was conceived to be a document format. • We are using it as an application format. • A pplications requires modules. • M odules protect their contents. • M odules communicate by exposing clean interfaces.

Slide 47: V ats • A dapting Google's Gears or A dobe's A IR to provide communicating containment. • Provides cooperation under mutual suspicion. • Heavyweight. • Distribution is difficult. • S till subject to X S S attacks.

Slide 48: 3. We need to replace JavaS cript and the DOM . A s long as we are using insecure languages, we will be subject to X S S attacks.

Slide 49: S tart with the A Dsafe subset, and then carefully add features to enhance expressiveness.

Slide 50: A is an Object. Object A has state A and behavior.

Slide 51: has-a A B Object A has a reference to A n object can have Object B . references to other objects.

Slide 52: Object A can communicate with Object B ... A B ...because it has a reference to Object B .

Slide 53: Object B provides an interface that constrains access to its own state A and references. B E very object is a micro vat.

Slide 54: Object A does not have a reference to Object C, so Object A cannot communicate with Object C. A B In an Object Capability S ystem, an object can only communicate with objects that it has references to. C

Slide 55: A n Object Capability S ystem is produced by constraining the ways that references are obtained. A reference cannot be obtained simply by knowing the name of a global variable or a public class.

Slide 56: There are exactly three ways to obtain a reference. 2. B y Creation. 4. B y Construction. 6. B y Introduction.

Slide 57: 1. B y Creation If a function creates an object, it gets a reference to that object.

Slide 58: 2. B y Construction A n object may be endowed by its constructor with references. This can include references in the constructor's context and inherited references.

Slide 59: 3. B y Introduction A has a references to B and C. B has no references, so it cannot communicate with A or C. C has no references, so it cannot communicate with A or B . A C B

Slide 60: 3. B y Introduction A calls B , passing a reference to C. A C B

Slide 61: 3. B y Introduction B is now able to communicate with C. A C B It has the capability.

Slide 62: Weaknesses to avoid include 1. A rrogation. 2. Corruption. 3. Confusion. 4. Collusion.

Slide 63: There is no security in obscurity Tricks and puzzles are not effective. S peed bumps are not effective.

Slide 64: False security increases the danger. Ineffective measures make things worse.

Slide 65: The security problems are not new. The problems are getting harder to ignore.

Slide 66: Ultimately • We need to replace JavaS cript with a secure language. • The current E S 4 proposal is not that language. • We need to replace HTM L and the DOM with a secure application delivery system. • The current HTM L 5 proposal is not that either.

Slide 67: Ultimately • S ecure programming language to replace JavaS cript. • A modular application framework to replace the DOM and CS S . • A common text representation and protocol to replace HTTP and the A jax stack. • Otherwise, the web may fall to newer proprietary systems.

Slide 68: M eanwhile • Never trust the browser. • Formally validate everything you receive from the browser. • Properly encode everything you send to the browser or database. • Do not circumvent what little security the browser offers. • Never put data on the wire unless you want it ot be delivered. • Don't take ineffective measures.

Slide 69: B e Rigorous • S loppiness aids the E nemy. • Neatness counts. • Use good encoders. • A void concatenation. • B e paranoid.

Slide 70: Turducken

Slideshare.net (beta)