Security for javascript


Published on

Published in: Technology
  • Be the first to comment

Security for javascript

  1. 1. Ajax Security DouglasCrockford Yahoo!
  2. 2. Security Thenumber 1 biggest problem with thewholeWorld WideWeb.
  3. 3. Thebrowser isnot asafe programming environment. It isinherently insecure.
  4. 4. What can an attacker do if he getssomescript into your page?
  5. 5. An attacker can request additional scriptsfrom any server in theworld. Onceit getsafoothold, it can obtain all of thescriptsit needs.
  6. 6. An attacker can makerequestsof your server. Your server cannot detect that the request did not originatewith your application.
  7. 7. An attacker can read the document. Theattacker can seeeverything the user sees.
  8. 8. An attacker hascontrol over the display and can request information from theuser. Theuser cannot detect that the request did not originatewith your application.
  9. 9. An attacker can send information to serversanywherein theworld.
  10. 10. Thebrowser doesnot prevent any of these. That'swhy they happen.
  11. 11. Theconsequencesof asuccessful attack arehorrible. Harm to customers. Lossof trust. Legal liabilities. Possiblecriminal penalties.
  12. 12. Thisisnot aWeb 2.0 problem. All of theseproblemscamewith Netscape2 in 1995.
  13. 13. TheTurducken Problem • Many Languages: HTTP, HTML, URL, CSS, JavaScript, XML, JSON, plaintext, SQL... • Each languagehasdifferent quoting and commenting conventions. • Thelanguagescan benested insideeach other.
  14. 14. A text that isbenign in onecontext might bedangerousin another. Sloppy encoding allowsinjection of evil scripts
  15. 15. A SimpleAttack <script>alert("XSS");</script> <html><body> <p>File not found: <script>alert("XSS");</script> </p></body></html> • Thescript runswith theauthority of your site.
  16. 16. A SimpleAttack <script>alert("XSS");</script> <html><body> <p>File not found: &lt;script>alert("XSS");&lt;/script> </p></body></html> • Proper escapement providessomesafety.
  17. 17. Another Example • Bad text " + alert("XSS") + " • Bad encoding {"json": "" + alert("XSS") + ""} • Good encoding {"json": "" + alert("XSS") + ""}
  18. 18. Coding hygieneiscritical for avoiding turducken attacks. Usegood encoders. Do not usesimpleconcatenation. Never trust thebrowser. Validateall input.
  19. 19. CrossSiteDataAccess It isextremely useful to obtain datafrom other sitesand mash it up.
  20. 20. SameOrigin Policy Preventsuseful things. Allowsdangerousthings.
  21. 21. Script Tag Hack • Scripts(strangely) areexempt from Same Origin Policy. • A dynamic script tag can makeaGET request from aserver. receiver(jsontext); • Extremely dangerous. It isimpossibleto assurethat theserver did not send an evil script.
  22. 22. JavaScript'sGlobal Object Theroot causeof XSSattacks. All scriptsrun with thesame authority.
  23. 23. JavaScript isan insecure language. TheES4 Proposal iseven worse. It should beabandoned.
  24. 24. Document Object Model All nodesarelinked to all other nodes and to thenetwork.
  25. 25. Cookies Ambient authority leadsto confusion and impersonation (XSRF)
  26. 26. Remedy: Crumbs An explicit secret should besent with theambient cookie. FrustratesXSRF attacks. Not effectiveagainst XSSattacks.
  27. 27. Excellent CodeQuality If codeisclean and readable, it isless likely to contain insecurities.
  28. 28. JSLint • JSLint definesaprofessional subset of JavaScript. • It imposesaprogramming disciplinethat makesmemuch moreconfident in adynamic, loosely-typed environment.
  29. 29. Warning! JSLint will hurt your feelings.
  30. 30. If theweb asbeen totally screwed up from thebeginning, why should we worry about it now? 1. Escalating legal penalties 2. Mashups 3. Competition
  31. 31. Mashups Themost interesting innovation in softwaredevelopment in 20 years.
  32. 32. Mashupsareinsecure. Mashupsmust not haveaccessto any confidential information.
  33. 33. If thereisscript from two or more sources, theapplication isnot secure. Period.
  34. 34. Advertising isamashup.
  35. 35. Competition to displacetheweb. Silverlight. AIR. JavaFX.
  36. 36. That wouldn't betheend of the world. It would just betheend of theWWW.
  37. 37. A ThreeProng Strategy to Fix theWeb 1. SafeJavaScript subsets. 2. Small browser improvements. 3. Massivebrowser improvements. Thiscould takeawhile, so weshould proceed on all threeimmediately.
  38. 38. 1. SafeJavaScript Subsets. Theeasiest way to improve JavaScript isto makeit smaller.
  39. 39. ADsafe • A JSLint option. • It definesasafeHTML/JavaScript subset. • Removesfrom JavaScript all featuresthat are unsafeor suspect. • Allowsforeign adsand widgetsto safely interact.
  40. 40. ADsafe • No global variablesor functionsmay be defined. • No global variablesor functionscan be accessed except theADSAFE object. • The[] subscript operator may not beused. • Thesewordscannot beused: apply call callee caller constructor eval new prototype this watch • Wordsstarting with _ cannot beused.
  41. 41. Dangers • Theremay still beundiscovered weaknessesin ECMAScript and itsmany implementations. • Browser implementationsarechanging, introducing new weaknesses. • TheDOM wrappersmust beflawless. • Wearestill subject to XSSattacks.
  42. 42. 2. Add SimpleFeatures to theBrowsers. Even simpleimprovementscan takea long timeto distribute.
  43. 43. JSONRequest for safedata interchange.
  44. 44. Vats Communicating computational containment vessels
  45. 45. HTML ProvidesNo Modules • It wasconceived to beadocument format. • Weareusing it asan application format. • Applicationsrequiresmodules. • Modulesprotect their contents. • Modulescommunicateby exposing clean interfaces.
  46. 46. Vats • Adapting Google'sGearsor Adobe'sAIR to providecommunicating containment. • Providescooperation under mutual suspicion. • Heavyweight. • Distribution isdifficult. • Still subject to XSSattacks.
  47. 47. 3. Weneed to replaceJavaScript and theDOM. Aslong asweareusing insecure languages, wewill besubject to XSS attacks.
  48. 48. Start with theADsafesubset, and then carefully add featuresto enhanceexpressiveness.
  49. 49. A isan Object. Object A hasstate and behavior.
  50. 50. Object A hasa referenceto Object B. An object can have referencesto other objects. has-a
  51. 51. ...becauseit hasa referenceto Object B. Object A can communicatewith Object B...
  52. 52. Object B provides an interfacethat constrainsaccess to itsown state and references. Every object isamicro vat.
  53. 53. Object A doesnot haveareferenceto Object C, so Object A cannot communicatewith Object C. In an Object Capability System, an object can only communicatewith objects that it hasreferencesto.
  54. 54. An Object Capability System is produced by constraining theways that referencesareobtained. A referencecannot beobtained simply by knowing thenameof a global variableor apublic class.
  55. 55. Thereareexactly threewaysto obtain areference. 1. By Creation. 2. By Construction. 3. By Introduction.
  56. 56. 1. By Creation If afunction createsan object, it gets areferenceto that object.
  57. 57. 2. By Construction An object may beendowed by itsconstructor with references. Thiscan includereferencesin theconstructor's context and inherited references.
  58. 58. 3. By Introduction A hasareferencesto B and C. B hasno references, so it cannot communicatewith A or C. C hasno references, so it cannot communicatewith A or B.
  59. 59. 3. By Introduction A callsB, passing areferenceto C.
  60. 60. 3. By Introduction B isnow ableto communicatewith C. It hasthecapability.
  61. 61. Weaknessesto avoid include 1. Arrogation. 2. Corruption. 3. Confusion. 4. Collusion.
  62. 62. Thereisno security in obscurity Tricksand puzzlesarenot effective. Speed bumpsarenot effective.
  63. 63. Falsesecurity increasesthe danger. Ineffectivemeasuresmakethings worse.
  64. 64. Thesecurity problemsarenot new. Theproblemsaregetting harder to ignore.
  65. 65. Ultimately • Weneed to replaceJavaScript with asecure language. • Thecurrent ES4 proposal isnot that language. • Weneed to replaceHTML and theDOM with asecureapplication delivery system. • Thecurrent HTML5 proposal isnot that either.
  66. 66. Ultimately • Secureprogramming languageto replace JavaScript. • A modular application framework to replace theDOM and CSS. • A common text representation and protocol to replaceHTTPand theAjax stack. • Otherwise, theweb may fall to newer proprietary systems.
  67. 67. Meanwhile • Never trust thebrowser. • Formally validateeverything you receivefrom the browser. • Properly encodeeverything you send to thebrowser or database. • Do not circumvent what littlesecurity thebrowser offers. • Never put dataon thewireunlessyou want it to be delivered. • Don't takeineffectivemeasures.
  68. 68. BeRigorous • SloppinessaidstheEnemy. • Neatnesscounts. • Usegood encoders. • Avoid concatenation. • Beparanoid.
  69. 69. Turducken