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
