Why AJAX Applications Are Far More Likely To Be Insecure (And What To Do About It) OWASP AppSec Seattle Oct 2006 Dave Wichers, OWASP Conferences Chair COO, Aspect.
Download ReportTranscript Why AJAX Applications Are Far More Likely To Be Insecure (And What To Do About It) OWASP AppSec Seattle Oct 2006 Dave Wichers, OWASP Conferences Chair COO, Aspect.
Why AJAX Applications Are Far More Likely To Be Insecure (And What To Do About It) OWASP AppSec Seattle Oct 2006 Dave Wichers, OWASP Conferences Chair COO, Aspect Security [email protected] 301 604 4882 Copyright © 2006 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the Creative Commons Attribution-ShareAlike 2.5 License. To view this license, visit http://creativecommons.org/licenses/by-sa/2.5/ The OWASP Foundation http://www.owasp.org/ 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 OWASP AppSec Seattle 2006 2 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 OWASP AppSec Seattle 2006 3 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” OWASP AppSec Seattle 2006 4 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 OWASP AppSec Seattle 2006 5 AJAX Security – Summary “AJAX applications face exactly the same security issues as 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 OWASP AppSec Seattle 2006 6 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; OWASP AppSec Seattle 2006 7 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; } } OWASP AppSec Seattle 2006 8 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 OWASP AppSec Seattle 2006 9 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 OWASP AppSec Seattle 2006 10 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 OWASP AppSec Seattle 2006 11 How Developers See AJAX Service (server-side) Application (client-side) OWASP AppSec Seattle 2006 12 How Attackers See AJAX Sniffing Interception Tampering Service (server-side) Application (client-side) Chained Attacks on Other Services or Other Clients Attacks on Local Hosts and Networks Attacks on Client Attacks on Server OWASP AppSec Seattle 2006 13 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 OWASP AppSec Seattle 2006 14 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 OWASP AppSec Seattle 2006 15 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 OWASP AppSec Seattle 2006 security checks 16 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 Untrusted Trusted, controlled Secure, controlled Highly protected Business logic Limited state Web Service XMLRPC AJAX - JSON SOA layer OWASP AppSec Seattle 2006 17 Attack Surface Change When Moving to AJAX Enabled Web App AJAX Standard Web App Browser (HTML and JavaScript) (PL) Data Layer AJAX (BL) AJAX (DL) Browser (HTML and Browser (HTML and JavaScript) Present. Layer Client-Server Interface Interface Changes AJAX Busin. Logic Pure AJAX Web App AJAX Bus. Logic Data Layer Present. Layer Client-Server Interface Busin. Logic (PL) Goal: Understand the Server interface and make it as simple as possible Browser (HTML and JavaScript) Data Layer Client-Server Interface *Of course, any architecture is possible OWASP AppSec Seattle 2006 18 New Threat: New Technology Issues JavaScript Language is not great Not standard Still evolving Protocols and parsers Brand new Web services Still very new OWASP AppSec Seattle 2006 19 REST vs. SOAP 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 GET http://ajax.com/getData HTTP/1.0 Accept: */* Referer: http://ajax.com/ Accept-Language: en-us HTTP/1.1 200Keep-Alive OK Proxy-Connection: Content-Type: text/xml User-Agent: Mozilla/4.0 Date: Wed, 03 Nov 2004 23:31:00 GMT Host: ajax.com Server: Apache Coyote/1.0 Cookie: JSESSIONID=9ABF9B823A874823A874 Connection: close <books> <book> <title>JavaScript Guide</title> POST /webservices/getData HTTP/1.1 Host: ajax.com Content-Type: text/xml Content-Length: 140 200 OK Cookie:HTTP/1.1 JSESSIONID=9ABF9B823A874823A874 Content-Type: text/xml Date: Wed, 03 encoding=“utf-8”?> Nov 2004 23:31:00 GMT <?xml version=“1.0” Server: Apache Coyote/1.0 <soap:Envelope>… Connection: close <soap:Body> …xml parameters… <?xml version=“1.0” encoding=“utf-8”?> <soap:Envelope>… <books> <book> <title>JavaScript Guide</title> OWASP AppSec Seattle 2006 20 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> ... OWASP AppSec Seattle 2006 21 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 OWASP AppSec Seattle 2006 22 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 OWASP AppSec Seattle 2006 23 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!! OWASP AppSec Seattle 2006 24 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 OWASP AppSec Seattle 2006 25 Browser Sandbox Currently, most only allow access to original site But lots of developers are pushing for crossdomain 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 OWASP AppSec Seattle 2006 26 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 OWASP AppSec Seattle 2006 27 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 OWASP AppSec Seattle 2006 28 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) OWASP AppSec Seattle 2006 29 AJAX Security Checklist Security Areas (Client and Server Note: Side) Secure Communications Almost no built-in security in AJAX Authentication and Sessions environments, so you have to build Access Control these yourself Data Protection Input Validation and Output Encoding Error Handling Logging & Intrusion Detection Availability Concurrency OWASP AppSec Seattle 2006 30 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? OWASP AppSec Seattle 2006 31 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 OWASP AppSec Seattle 2006 32 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_%2 2Rich%22_Interface_Technologies AJAX Patterns Site Security Links: http://ajaxpatterns.org/Security_Links Andrew Van der Stock’s forthcoming book OWASP AppSec Seattle 2006 33 Questions and Answers QUESTIONS ANSWERS OWASP AppSec Seattle 2006