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