Web 2.0 Expo: The Dark Side of Ajax

Room is huge and darn near packed. I get the feeling this is gonna be a good one. I think I’m going to have to type quickly for this one.

Presenter: Jacob West (Fortify Software)

  • Jacob runs the security research group
  • First off, the ubiquitous “what is Ajax” shtick
  • It’s trivial to make the mistake, such as echoing a request parameter (easy to slip scripting into the request string)
  • There are over 400 JavaScript CVE (Common Vulnerability Enumeration) problems
  • Lots of different libraries, but few actually get them “right”. GWT and Atlas are the two best.
  • Examples of bad Ajax:
    • MySpace allowed input of subset of HTML, which included poorly formatted HTML (java\nscript) to execute code; Samy worm brought down MySpace
    • Port scanning behind firewalls
      • request images from internal IPs (192.168.x.x) — if timer doesn’t time out, you know a server is there
    • Jikto
      • Billy Hoffman built a vulnerability scanner in JS
      • Looks for XSS, uses Google as a proxy to bypass same origin policy
        • Loaded his script, and the victim’s page inside Google Translate, where they became the same domain
      • Allowed to operate as a worm by inserting it as a snippet into a vulnerability
  • No new vulnerabilities — XSS has existed a long time — just better exploits
  • Basic rule: echoing parameters recieved through URL strings is pretty much as bad as it gets
  • Input validations on the client side can be a serious risk — important that validation is handled carefully
  • Dirty-data shooters use known exploits, SQL injection, etc. that use Web 1.0 conventions to show exploits
    • Looks like conventional testing software
  • Cross-Site Request Forgery allows attacker to submit request on behalf of the victim
    • It can make requests, but can’t see the data (security remains intact for responses); it hopes the attack is malicious
  • JavaScript hijacking
    • Builds on CSRF
    • Breaks confientiality through loophole in SOP
    • Has some very subtle approaches that include modifying the constructor
    • NOTE: Need to engage a couple of brains on this for white paper; there are some potentially serious dangers I think we’re not handling well
  • Prevent CSRF
    • Require unique tokens to allow execution
    • Default to POST not enough, nor checking known HTTP header (e.g. referrer) not enough
  • Prevent execution of JavaScript
    • while(1);/* … */, etc. at the beginning of the returning scripts to ensure they won’t run
  • State of the frameworks
    • Most do NOT prevent hijacking (including Prototype, jQuery)
    • When contact, most of the libs didn’t care
    • JSON standard doesn’t cover any security, and Fortify’s suggestions have been largely decried as unnecessary and/or bad
  • Libs fixed:
    • Dojo 0.4.3 (JSON only, not JS), DWR 2.0, Prototype 1.5.1
    • All use the comment trick (/* … */) to protect the code
    • GWT, Mochikit, Script.aculo.us are coming soon
    • Microsoft and Yahoo said they will not fix it
  • There are ways of setting up tests to check for vulnerabilities; they are non-trivial, but important in cases of transactional Ajax
  • Frameworks need to put more security in them to prevent hijacking
  • Need better web standards
    • cookies need to be HTTP-only headers
    • browsers have to distinguish between scripts from different domains
    • Note: Flash has most of these issues already addressed
  • Result: mashups aren’t secure. Maps okay, but confidential data is vulnerable

Leave a Reply

Your email address will not be published. Required fields are marked *