Why AJAX Applications Are Far More Likely To Be Insecure (And What To Do About It)

1. Why AJAX Applications Are Far More Likely To Be Insecure (And What To Do About It) Dave Wichers, OWASP Conferences Chair COO, Aspect Security dave.wichers@aspectsecurity.com 301 604 4882

2. What Is AJAX? • AJAX is collection of techniques used to improve user experience • Dynamic HTML • XmlHttpRequest • JavaScript in browser • Issues asynchronous requests • Handles responses • AJAX causes web applications to extend beyond the server into the browser • AJAX is supposedly not an acronym, but in reality it stands for: • Asynchronous • JavaScript • And • XML The reason for all this: Jesse James Garrett, AJAX pioneer

3. Google Maps – AJAX Killer App • JavaScript is used asynchronously to talk to the server in the background • Browser has no idea the page’s JavaScript is talking to the server • Back/Forward buttons not what you expect since browser does not know about JavaScript’s communications • Normal visual cues that activity is going on are missing

4. Web 1.0 and Web 2.0 Architectures Compared “Web 1.0” Architecture • Traditional Client/Server • Synchronous • Click-Wait-Refresh ______________________________________________ “Web 2.0” Architecture • Used with AJAX/Flash/Applet • Asynchronous • Time or user-driven refreshes • User never has to leave page • Application feels “richer”

5. Why Use AJAX? • More interactive interfaces • More smaller messages may improve network use • Content feeding • Download content from the server and process it • Content can be HTML, JavaScript, XML, pictures, anything • On-demand JavaScript • Download code as needed • Client Prediction • User actions help predict next actions • Queue up data to speed up delivery

6. AJAX Security – Summary “AJAX applications face exactly the same security issuesas all other web applications, plus they add their own particular set of risks that must be correctly managed. By their complex, bidirectional, and asynchronous nature, AJAX applications increase attack surface area.” OWASP Guide 3.0 – Chapter on AJAX and Other “Rich” Interface Technologies

7. AJAX – Nothing New, but … • In one way, nothing new here • Just client-side presentation enhancements • Neat tool for improving interactivity and responsiveness • Simply requires more code on the client side • All HTTP under the covers • All the same security concerns apply function reloadContents() { httpObj = new XMLHttpRequest(); httpObj.onreadystatechange = getAjaxData; httpObj.open( "GET", "/GetContentsServlet", true); httpObj.send(null); } GET http://maps.google.com/GetContentsServlet HTTP/1.0 Accept: */* Referer: http://maps.google.com/ Accept-Language: en-us Proxy-Connection: Keep-Alive User-Agent: Mozilla/4.0 (compatible; MSIE 6.0) Host: maps.google.com Cookie: PREF=ID=8e2690f29f4050c8:TB=2:TM=1142526213;

8. Example AJAX Code function reloadContents() { httpObj = new XMLHttpRequest(); httpObj.onreadystatechange = handleReloadContents; httpObj.open("GET","/GetContentsServlet",true); httpObj.send(null); } function handleReloadContents() { if (httpObj.readyState == 4 || httpObj.readyState=="complete") { var cell = document.getElementById("mainBody"); cell.innerHTML = httpObj.responseText; } }

9. AJAX XmlHttpRequest (XHR) • Same-origin policy • Can’t request outside of parent domain (JavaScript sandbox) • XHR is not new but is relatively untested • XHR introduced in 1998, but use only recently popular • First security problems only uncovered recently • Implementations in browsers vary

10. New AJAX Security Threats to Consider • Developer Issues • Testing Issues • Architecture Issues • Server Side AND • Client Side • New Technology Issues • AJAX Privacy Concerns • New and Existing Injection Issues • AJAX Bridges

11. New Threat: Developer Issues • More wizards and tools • Hide client-server distinction • AJAX applications have larger Attack Surface than traditional web applications • Lack of examples • Developers invent stuff • Many novices • HTML “programmers” now using AJAX (because its cool / popular) • Tools aren’t there • Very hard to debug • Mozilla’s Venkman JS debugger

12. How Developers See AJAX Service (server-side) Application (client-side)

13. How Attackers See AJAX SniffingInterception Tampering Service (server-side) Application (client-side) Chained Attacks on Other Services or Other Clients Attacks on Local Hosts and Networks Attacks on Server Attacks on Client

14. Dangerous Developer Assumptions • Nobody can find my service • If the client knows, then the hacker knows • Where my code runs doesn’t have a security impact • Security decisions must not be made on the client • Frameworks and code generators handle security • Making things talk is easy, making them secure can’t be automated • The only way to access my service is with my client • You cannot do security testing with a browser • My code is too tricky to understand • Attackers can reverse engineer anything

15. New Threat: Testing Issues • Complexity • More moving parts in distributed systems • Only getting worse with Web Services/SOA • Hidden code • AJAX code is difficult to manage • Google Web Toolkit solves this problem by compiling Java into JavaScript • Difficulty of testing • No testing tools

16. Google Web Toolkit (GWT) • An example of • ‘Why it can be hard for developer to define server interface’ • In GWT, all code is written in Java • Its then translated into Java code and JavaScript • Java code stays on server (defining server interface) • JavaScript goes to browser • Magically Deployed (nasty details hidden) • This is really cool!! • But … developer has no idea where client-server boundary is • Therefore, developer doesn’t know where its safe to put security checks

17. New Threat: Architecture Issues • Must synchronize security checks on both client and server • Must keep the business logic on the server (IP issues) • New client-side attack surface • Server-side attack surface closer to backend • Now function calls instead of simpler requests

18. Attack Surface Change When Moving to AJAX Goal: Understand the Server interface and make it as simple as possible *Of course, any architecture is possible

19. New Threat: New Technology Issues • JavaScript • Language is not great • Not standard • Still evolving • Protocols and parsers • Brand new • Web services • Still very new

20. REST vs. SOAP GET http://ajax.com/getData HTTP/1.0 Accept: */* Referer: http://ajax.com/ Accept-Language: en-us Proxy-Connection: Keep-Alive User-Agent: Mozilla/4.0 Host: ajax.com Cookie: JSESSIONID=9ABF9B823A874823A874 • Deciding on a protocol • REST • Simple HTTP requests (generally GET) • Simple HTTP response containing XML in body • 80% of exposed Web Services traffic is REST • SOAP • POST protocol • SOAP headers • XML in request body, XML in response body • SOAP more capable and robust, but harder to build HTTP/1.1 200 OK Content-Type: text/xml Date: Wed, 03 Nov 2004 23:31:00 GMT Server: Apache Coyote/1.0 Connection: close <books> <book> <title>JavaScript Guide</title> POST /webservices/getData HTTP/1.1 Host: ajax.com Content-Type: text/xml Content-Length: 140 Cookie: JSESSIONID=9ABF9B823A874823A874 <?xml version=“1.0” encoding=“utf-8”?> <soap:Envelope>… <soap:Body> …xml parameters… HTTP/1.1 200 OK Content-Type: text/xml Date: Wed, 03 Nov 2004 23:31:00 GMT Server: Apache Coyote/1.0 Connection: close <?xml version=“1.0” encoding=“utf-8”?> <soap:Envelope>… <books> <book> <title>JavaScript Guide</title>

21. XML vs. JSON • Deciding on a data format • JSON • JavaScript Object Notation • Message format for passing JavaScript objects between client and server • Interpreted in the browser using eval() • XSS attacks on clients possible through JSON messages • XML • Extensible Markup Language • Universal - many parsers available • Many known attacks associated with parsers and validators {"books":[{"book": { "title":"JavaScript Guide", "publisher":"O'Reilly", "author":"David Flanagan", "cover":"/images/cover_defguide.jpg", "blurb":"Lorem ipsum." } }, ... var data = eval('(' + req.responseText + ')'); <books> <book> <title>JavaScript, Definitive Guide</title> <publisher>O'Reilly</publisher> <author>David Flanagan</author> <cover src="/images/cover_defguide.jpg" /> <blurb>Lorem ipsum.</blurb> </book> <book> ...

22. AJAX Privacy Concerns • AJAX has client side state • Cookies • XML Data • DOM • All of these can be manipulated by • Hostile code injected into client • By user directly • Not private in any way

23. Increased Threat: Injection Attacks • Server Side • Code Injection – e.g., Most PHP AJAX tool kits (e.g.: AJason, JPSpan and CPAINT) allow remote code injection by allowing client-side server code invocation • XML and XPATH injection – just like SQL injection • Client Side • Script Injection – i.e., Cross Site Scripting (XSS) • DOM injection – client side attacks now much easier • JSON injection – be careful how you decode! • XML and XSLT injection – access or reformat data • Custom AJAX Engine Injection – If AJAX client includes an interpreter • Probably more … * Source: Many of these points came from Andrew Van Der Stock’s Ajax Security presentation from OWASP EU 2006

24. Lets Look at Client Side Injection Threats • XSS – Any such flaw completely compromises the client side • Can access any client side data • Can modify any client side code (its all in the DOM) • DOM Injection • Introduces XSS of the 3rd kind and exposes private data • JSON/XML/XSLT Injection • Access or reformat data or kill parser • Custom AJAX Engine Injection (New!!) • Can inject commands into engine • Can modify engine itself • Complete client side compromise!!

25. New Type of Application: Mashups • Mashup - Web Application that combines data from multiple sources (typically different Web Services) • E.g., Google Maps with locations of all OWASP Chapters • AJAX frequently used to implement Mashups • Problem - Browser prevents client application from accessing more than one Web Service (due to source-of-origin rule) • Solutions • One Web Service serves as proxy to the other (allowing client to only talk to one site). Introduces Trust Relationship. • Ask user for ‘permission’ to access second site • Problems with both approaches • Client side can’t gain access to other site’s data (authentication?) • Server side may pass malicious requests through to other service

26. Browser Sandbox • Currently, most only allow access to original site • But lots of developers are pushing for cross-domain XHR • Means your client could request data from some other site • They want “mashups” to happen on the client • If “other site” is outside your control • No opportunity to validate or encode data • Could include bad data or malicious scripts • Could encourage passing sensitive data unprotected • If successful, attacker script could… • Drive the client and do anything the user could do • Steal data • Disclose session cookie

27. New Threat: AJAX Bridges • AJAX Bridge: Proxy AJAX Requests through one Server to Another • Bridge can be used to anonymously attack other service • Bridge might have more privileges that normal user • Service might trust bridge more than normal user • If service detects attacks from bridge, might cut off the bridge, thus causing denial of service to bridging app • Service might prohibit access through Bridge (against rules of use) • User might not trust Bridge to access his info on the target service (e.g., financial analysis bridge not allowed to access user’s actual account, but mixing data directly on client might be OK, if cross domain XHR were allowed) • Many AJAX Frameworks include Bridges * Source: Many of these points came from Billy Hoffman’s Ajax (in)security presentation from Black Hat 2006

28. High Level Recommendations (Server Side) • As always, never trust anything done on Client • Clearly understand the Server Interface (i.e., your attack surface) • If AJAX framework includes server side code, carefully validate it, or avoid using it (i.e., write your own) • Many AJAX frameworks are 100% client based, which is good (since they don’t introduce server side risks), but there are still other issues (as discussed later) • E.g., Tibco, Atlas, Backbase • Warning: There are LOTS of frameworks (and they are all different) • See: http://ajaxpatterns.org/Ajax_Frameworks • Ensure proper protections on Server Interface • See AJAX Security Checklist

29. High Level Recommendations (Client Side) • Don’t Store Sensitive Data • Minimize Business Logic (easily tampered with) • Be Extra Careful about XSS Flaws • Since more likely to have sensitive data • Could modify AJAX interpreter • Identify All Client Side Interpreters and Parsers • Be careful to avoid ANY injection attacks against these • Particularly any fancy new AJAX Engine (on client or server)

30.  AJAX Security Checklist • Security Areas (Client and Server Side) • Secure Communications • Authentication and Sessions • Access Control • Data Protection • Input Validation and Output Encoding • Error Handling • Logging & Intrusion Detection • Availability • Concurrency Note: Almost no built-in security in AJAX environments, so you have to build these yourself

31. Other Types of Rich Internet Applications (Like AJAX) • Flash • Runs .swf files in browser VM plugin • Many known flaws in Flash Player • Java applets • All Java security benefits • Not as integrated in browser • Java web-start applications • More like a desktop application • Strong security • ActiveX controls • Windows only • Powerful - no sandbox! • User interface languages (XUL) • future?

32. Summary • Some new interesting problems in AJAX / Web 2.0 • Make sure developers know trust boundaries and security issues • With good coding policy and good design, risk can be mitigated

33. AJAX Security Resources • Guide to Building Secure Web Applications and Web Services • Chapter: Ajax and Other "Rich" Interface Technologies • http://www.owasp.org/index.php/Ajax_and_Other_%22Rich%22_Interface_Technologies • AJAX Patterns Site Security Links: • http://ajaxpatterns.org/Security_Links • Andrew Van der Stock’s forthcoming book 

34. Q & Q U E S T I O N S A N S W E R S Questions and Answers A