Security for javascript
Download as PPT, PDF1 like348 views
An attacker can inject malicious scripts into a web page by exploiting security vulnerabilities in the browser environment. Once a foothold is gained, an attacker can access additional scripts from any server, make unauthorized requests to the vulnerable server, read data in the document, and send data to other servers. These attacks have been issues since Netscape 2 in 1995. Ultimately, JavaScript and the DOM need to be replaced with more secure alternatives to prevent cross-site scripting (XSS) attacks.
![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.](https://image.slidesharecdn.com/security-140315131839-phpapp01/85/Security-for-javascript-40-320.jpg)
Security for javascript
- 2. Security Thenumber 1 biggest problem with thewholeWorld WideWeb.
- 3. Thebrowser isnot asafe programming environment. It isinherently insecure.
- 4. What can an attacker do if he getssomescript into your page?
- 5. An attacker can request additional scriptsfrom any server in theworld. Onceit getsafoothold, it can obtain all of thescriptsit needs.
- 6. An attacker can makerequestsof your server. Your server cannot detect that the request did not originatewith your application.
- 7. An attacker can read the document. Theattacker can seeeverything the user sees.
- 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. An attacker can send information to serversanywherein theworld.
- 10. Thebrowser doesnot prevent any of these. That'swhy they happen.
- 11. Theconsequencesof asuccessful attack arehorrible. Harm to customers. Lossof trust. Legal liabilities. Possiblecriminal penalties.
- 12. Thisisnot aWeb 2.0 problem. All of theseproblemscamewith Netscape2 in 1995.
- 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. A text that isbenign in onecontext might bedangerousin another. Sloppy encoding allowsinjection of evil scripts
- 15. A SimpleAttack http://yourdomain.com/ <script>alert("XSS");</script> <html><body> <p>File not found: <script>alert("XSS");</script> </p></body></html> • Thescript runswith theauthority of your site.
- 16. A SimpleAttack http://yourdomain.com/ <script>alert("XSS");</script> <html><body> <p>File not found: <script>alert("XSS");</script> </p></body></html> • Proper escapement providessomesafety.
- 17. Another Example • Bad text " + alert("XSS") + " • Bad encoding {"json": "" + alert("XSS") + ""} • Good encoding {"json": "" + alert("XSS") + ""}
- 18. Coding hygieneiscritical for avoiding turducken attacks. Usegood encoders. json.org/json2.js Do not usesimpleconcatenation. Never trust thebrowser. Validateall input.
- 19. CrossSiteDataAccess It isextremely useful to obtain datafrom other sitesand mash it up.
- 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. JavaScript'sGlobal Object Theroot causeof XSSattacks. All scriptsrun with thesame authority.
- 23. JavaScript isan insecure language. TheES4 Proposal iseven worse. It should beabandoned.
- 24. Document Object Model All nodesarelinked to all other nodes and to thenetwork.
- 25. Cookies Ambient authority leadsto confusion and impersonation (XSRF)
- 26. Remedy: Crumbs An explicit secret should besent with theambient cookie. FrustratesXSRF attacks. Not effectiveagainst XSSattacks.
- 27. Excellent CodeQuality If codeisclean and readable, it isless likely to contain insecurities.
- 28. JSLint • JSLint definesaprofessional subset of JavaScript. • It imposesaprogramming disciplinethat makesmemuch moreconfident in adynamic, loosely-typed environment. http://www.JSLint.com/
- 29. Warning! JSLint will hurt your feelings.
- 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. Mashups Themost interesting innovation in softwaredevelopment in 20 years.
- 32. Mashupsareinsecure. Mashupsmust not haveaccessto any confidential information.
- 33. If thereisscript from two or more sources, theapplication isnot secure. Period.
- 36. That wouldn't betheend of the world. It would just betheend of theWWW.
- 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. 1. SafeJavaScript Subsets. Theeasiest way to improve JavaScript isto makeit smaller.
- 39. ADsafe • A JSLint option. • It definesasafeHTML/JavaScript subset. • Removesfrom JavaScript all featuresthat are unsafeor suspect. • Allowsforeign adsand widgetsto safely interact.
- 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. Dangers • Theremay still beundiscovered weaknessesin ECMAScript and itsmany implementations. • Browser implementationsarechanging, introducing new weaknesses. • TheDOM wrappersmust beflawless. • Wearestill subject to XSSattacks.
- 42. 2. Add SimpleFeatures to theBrowsers. Even simpleimprovementscan takea long timeto distribute.
- 44. Vats Communicating computational containment vessels
- 45. HTML ProvidesNo Modules • It wasconceived to beadocument format. • Weareusing it asan application format. • Applicationsrequiresmodules. • Modulesprotect their contents. • Modulescommunicateby exposing clean interfaces.
- 46. Vats • Adapting Google'sGearsor Adobe'sAIR to providecommunicating containment. • Providescooperation under mutual suspicion. • Heavyweight. • Distribution isdifficult. • Still subject to XSSattacks.
- 47. 3. Weneed to replaceJavaScript and theDOM. Aslong asweareusing insecure languages, wewill besubject to XSS attacks.
- 48. Start with theADsafesubset, and then carefully add featuresto enhanceexpressiveness.
- 49. A isan Object. Object A hasstate and behavior.
- 50. Object A hasa referenceto Object B. An object can have referencesto other objects. has-a
- 51. ...becauseit hasa referenceto Object B. Object A can communicatewith Object B...
- 52. Object B provides an interfacethat constrainsaccess to itsown state and references. Every object isamicro vat.
- 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. An Object Capability System is produced by constraining theways that referencesareobtained. A referencecannot beobtained simply by knowing thenameof a global variableor apublic class.
- 55. Thereareexactly threewaysto obtain areference. 1. By Creation. 2. By Construction. 3. By Introduction.
- 56. 1. By Creation If afunction createsan object, it gets areferenceto that object.
- 57. 2. By Construction An object may beendowed by itsconstructor with references. Thiscan includereferencesin theconstructor's context and inherited references.
- 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. 3. By Introduction A callsB, passing areferenceto C.
- 60. 3. By Introduction B isnow ableto communicatewith C. It hasthecapability.
- 61. Weaknessesto avoid include 1. Arrogation. 2. Corruption. 3. Confusion. 4. Collusion.
- 62. Thereisno security in obscurity Tricksand puzzlesarenot effective. Speed bumpsarenot effective.
- 64. Thesecurity problemsarenot new. Theproblemsaregetting harder to ignore.
- 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. 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. 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. BeRigorous • SloppinessaidstheEnemy. • Neatnesscounts. • Usegood encoders. • Avoid concatenation. • Beparanoid.
- 69. Turducken