Loading...
Flash Player 9 (or above) is needed to view slideshows. We have detected that you do not have it on your computer.To install it, go here
 
Post to Twitter Post to Twitter
Myspace Hi5 Friendster Xanga LiveJournal Facebook Blogger Tagged Typepad Freewebs BlackPlanet gigya icons
SlideShare is now available on LinkedIn. Add it to your LinkedIn profile.

Ajax Security

From douglascrockford, 9 months ago Add as contact

Presented at Web Directions North

5702 views | 0 comments | 9 favorites | 159 downloads | 7 embeds (Stats)

Categories

Technology

Tags

Groups/Events

Embed in your blog options close
Embed (wordpress.com) Exclude related slideshows Embed in your blog

More Info

This slideshow is Public
Total Views: 5702 on Slideshare: 5002 from embeds: 700
Flagged as inappropriate Flag as inappropriate

Flag as inappropriate

Select your reason for flagging this slideshow as inappropriate.

If needed, use the feedback form to let us know more details.

Slideshow Transcript

  1. Slide 1: Is This On?
  2. Slide 2: A jax S ecurity Douglas Crockford Yahoo! javascript.crockford.com/security.ppt
  3. Slide 3: S ecurity The number 1 biggest problem with the whole World Wide Web.
  4. Slide 4: The browser is not a safe programming environment. It is inherently insecure.
  5. Slide 5: What can an attacker do if he gets some script into your page?
  6. 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.
  7. 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.
  8. Slide 8: A n attacker can read the document. The attacker can see everything the user sees.
  9. 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.
  10. Slide 10: A n attacker can send information to servers anywhere in the world.
  11. Slide 11: The browser does not prevent any of these. That's why they happen.
  12. Slide 12: The consequences of a successful attack are horrible. Harm to customers. Loss of trust. Legal liabilities. Possible criminal penalties.
  13. Slide 13: This is not a Web 2.0 problem. A ll of these problems came with Netscape 2 in 1995.
  14. 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.
  15. Slide 15: A text that is benign in one context might be dangerous in another. S loppy encoding allows injection of evil scripts
  16. 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.
  17. Slide 17: A S imple A ttack http://yourdomain.com/ <script>alert(\"XSS\");</script> <html><body> <p>File not found: &lt;script>alert(\"XSS\");&lt;/script> </p></body></html> • Proper escapement provides some safety.
  18. Slide 18: A nother E xample • B ad text \" + alert(\"XSS\") + \" • B ad encoding {\"json\": \"\" + alert(\"XSS\") + \"\"} • Good encoding {\"json\": \"\\\" + alert(\\\"XSS\\\") + \\\"\"}
  19. 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.
  20. Slide 20: Cross S ite Data A ccess It is extremely useful to obtain data from other sites and mash it up.
  21. Slide 21: S ame Origin Policy Prevents useful things. A llows dangerous things.
  22. 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.
  23. Slide 23: JavaS cript's Global Object The root cause of X S S attacks. A ll scripts run with the same authority.
  24. Slide 24: JavaS cript is an insecure language. The E S 4 Proposal is even worse. It should be abandoned.
  25. Slide 25: Document Object M odel A ll nodes are linked to all other nodes and to the network.
  26. Slide 26: Cookies A mbient authority leads to confusion and impersonation (X S RF )
  27. 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.
  28. Slide 28: E xcellent Code Quality If code is clean and readable, it is less likely to contain insecurities.
  29. 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/
  30. Slide 30: Warning! JS Lint will hurt your feelings.
  31. 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
  32. Slide 32: M ashups The most interesting innovation in software development in 20 years.
  33. Slide 33: M ashups are insecure. M ashups must not have access to any confidential information.
  34. Slide 34: If there is script from two or more sources, the application is not secure. Period.
  35. Slide 35: A dvertising is a mashup.
  36. Slide 36: Competition to displace the web. S ilverlight. A IR. JavaFX.
  37. Slide 37: That would'nt be the end of the world. It would just be the end of the WWW.
  38. 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.
  39. Slide 39: 1. S afe JavaS cript S ubsets. The easiest way to improve JavaS cript is to make it smaller.
  40. 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.
  41. 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.
  42. 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.
  43. Slide 43: 2. A dd S imple Features to the B rowsers. E ven simple improvements can take a long time to distribute.
  44. Slide 44: JS ONRequest for safe data interchange.
  45. Slide 45: V ats Communicating computational containment vessels
  46. 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.
  47. 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.
  48. 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.
  49. Slide 49: S tart with the A Dsafe subset, and then carefully add features to enhance expressiveness.
  50. Slide 50: A is an Object. Object A has state A and behavior.
  51. Slide 51: has-a A B Object A has a reference to A n object can have Object B . references to other objects.
  52. Slide 52: Object A can communicate with Object B ... A B ...because it has a reference to Object B .
  53. 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.
  54. 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
  55. 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.
  56. Slide 56: There are exactly three ways to obtain a reference. 2. B y Creation. 4. B y Construction. 6. B y Introduction.
  57. Slide 57: 1. B y Creation If a function creates an object, it gets a reference to that object.
  58. 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.
  59. 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
  60. Slide 60: 3. B y Introduction A calls B , passing a reference to C. A C B
  61. Slide 61: 3. B y Introduction B is now able to communicate with C. A C B It has the capability.
  62. Slide 62: Weaknesses to avoid include 1. A rrogation. 2. Corruption. 3. Confusion. 4. Collusion.
  63. Slide 63: There is no security in obscurity Tricks and puzzles are not effective. S peed bumps are not effective.
  64. Slide 64: False security increases the danger. Ineffective measures make things worse.
  65. Slide 65: The security problems are not new. The problems are getting harder to ignore.
  66. 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.
  67. 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.
  68. 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.
  69. Slide 69: B e Rigorous • S loppiness aids the E nemy. • Neatness counts. • Use good encoders. • A void concatenation. • B e paranoid.
  70. Slide 70: Turducken
© 2008 SlideShare Inc. All Rights Reserved.
App06 is serving you