1 / 69

The Inherent Insecurity of Browsers and the Consequences of Attacks

This presentation highlights the inherent insecurity of browsers and the potential consequences of attacks. It covers the Turducken problem, XSS attacks, cross-site data access, JavaScript's global object, the Document Object Model, cookies, and the importance of excellent code quality. It also discusses the need for safe JavaScript subsets, small browser improvements, and massive browser improvements to fix the web.

afuentes
Download Presentation

The Inherent Insecurity of Browsers and the Consequences of Attacks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ajax Security Douglas Crockford Yahoo! javascript.crockford.com/security.ppt

  2. Security The number 1 biggest problem with the whole World Wide Web.

  3. The browser is not a safe programming environment. It is inherently insecure.

  4. What can an attacker do if he gets some script into your page?

  5. An 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.

  6. An attacker can make requests of your server. Your server cannot detect that the request did not originate with your application.

  7. An attacker can read the document. The attacker can see everything the user sees.

  8. An 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.

  9. An attacker can send information to servers anywhere in the world.

  10. The browser does not prevent any of these. That's why they happen.

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

  12. This is not a Web 2.0 problem. All of these problems came with Netscape 2 in 1995.

  13. The Turducken Problem • Many Languages: • HTTP, HTML, URL, CSS, JavaScript, XML, JSON, plaintext, SQL... • Each language has different quoting and commenting conventions. • The languages can be nested inside each other.

  14. A text that is benign in one context might be dangerous in another. Sloppy encoding allows injection of evil scripts

  15. A Simple Attack 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.

  16. A Simple Attack 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.

  17. Another Example • Bad text " + alert("XSS") + " • Bad encoding {"json": "" + alert("XSS") + ""} • Good encoding {"json": "\" + alert(\"XSS\") + \""}

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

  19. Cross Site Data Access It is extremely useful to obtain data from other sites and mash it up.

  20. Same Origin Policy Prevents useful things.Allows dangerous things.

  21. Script Tag Hack • Scripts (strangely) are exempt from Same Origin Policy. • A dynamic script tag can make a GET request from a server. • receiver(jsontext); • Extremely dangerous. It is impossible to assure that the server did not send an evil script.

  22. JavaScript's Global Object The root cause of XSS attacks. All scripts run with the same authority.

  23. JavaScript is an insecure language. The ES4 Proposal is even worse. It should be abandoned.

  24. Document Object Model All nodes are linked to all other nodes and to the network.

  25. Cookies Ambient authority leads to confusion and impersonation (XSRF)

  26. Remedy: Crumbs An explicit secret should be sent with the ambient cookie. Frustrates XSRF attacks. Not effective against XSS attacks.

  27. Excellent Code Quality If code is clean and readable, it is less likely to contain insecurities.

  28. JSLint • JSLint defines a professional subset of JavaScript. • It imposes a programming discipline that makes me much more confident in a dynamic, loosely-typed environment. http://www.JSLint.com/

  29. Warning! JSLint will hurt your feelings.

  30. If the web as been totally screwed up from the beginning, why should we worry about it now? 1. Escalating legal penalties 2. Mashups 3. Competition

  31. Mashups The most interesting innovation in software development in 20 years.

  32. Mashups are insecure. Mashups must not have access to any confidential information.

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

  34. Advertising is a mashup.

  35. Competition to displace the web. Silverlight. AIR. JavaFX.

  36. That wouldn't be the end of the world. It would just be the end of the WWW.

  37. A Three Prong Strategy to Fix the Web • Safe JavaScript subsets. • Small browser improvements. • Massive browser improvements. • This could take a while, so we should proceed on all three immediately.

  38. 1. Safe JavaScript Subsets. The easiest way to improve JavaScript is to make it smaller.

  39. ADsafe • A JSLint option. • It defines a safe HTML/JavaScript subset. • Removes from JavaScript all features that are unsafe or suspect. • Allows foreign ads and widgets to safely interact.

  40. ADsafe • 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 constructor eval new prototype this watch • Words starting with _ cannot be used.

  41. Dangers • There may still be undiscovered weaknesses in ECMAScript and its many implementations. • Browser implementations are changing, introducing new weaknesses. • The DOM wrappers must be flawless. • We are still subject to XSS attacks.

  42. 2. Add Simple Features to the Browsers. Even simple improvements can take a long time to distribute.

  43. JSONRequest for safe data interchange.

  44. Vats Communicating computational containment vessels

  45. HTML Provides No Modules • It was conceived to be a document format. • We are using it as an application format. • Applications requires modules. • Modules protect their contents. • Modules communicate by exposing clean interfaces.

  46. Vats • Adapting Google's Gears or Adobe's AIR to provide communicating containment. • Provides cooperation under mutual suspicion. • Heavyweight. • Distribution is difficult. • Still subject to XSS attacks.

  47. 3. We need to replace JavaScript and the DOM. As long as we are using insecure languages, we will be subject to XSS attacks.

  48. Start with the ADsafe subset, and then carefully add features to enhance expressiveness.

  49. A is an Object. Object A has state and behavior.

  50. has-a Object A has a reference to Object B. An object can have references to other objects.

More Related