The Dark Side of Ajax.pptVIP

* * * * * * * * * * Two Defenses Against JavaScript Hijacking Prevent CSRF Default to POST not enough Developers add GET so that result can be cached Checking for a known HTTP header is not enough (Flash CSRF vulnerability) Prevent execution of JavaScript while(1); /* ... */ Relying on object notation {} rather than array notation [] is silly calling parseJSON() rather than eval() does not help How the Popular Frameworks Responded Head-in-the-sand defense JavaScript Hijacking Myths and Misunderstandings This is a server administration problem. It’s a programming problem. Yeah yeah, but somebody could just do ‘view source’ and accomplish the same thing. The attacker is not the one running the web browser But if you’ve got CSRF vulns, you’re toast anyway. CSRF is bad, but this is worse: it adds breach of confidentiality This relies on some XSS vuln or a bug in the browser. Not so, this is how the browser is supposed to work! Mashups Aren’t Secure Scripts from multiple domains == security problem Often use JavaScript callbacks and auto-generated script tags Might be fine for Google maps, but not okay for confidential data Pink FloydDark Side of the Moon AJAX all purpose cleaner The Future of Ajax Better frameworks offer a chance to build security in Prevent CSRF Provide secure defaults Opportunity for better validation Better separation between display and controller Better definition for browser/server interaction Better Web standards Cookies: broken, need *working* HTTP only cookies Browsers: broken, need to distinguish between scripts from different domains Flash? Documented security best-practices Hard to mistake data and code Well-defined system for cross-domain communication Summary Ajax: a difference of degree Attack techniques improving quickly Technology pushed well past original design goals Old best practices still apply Don’t trust the client Protect the client New challenges Harder to test More complexity == more room for error A new ally Good opport