Upload
timothy-brock
View
26
Download
3
Embed Size (px)
DESCRIPTION
Why AJAX Applications Are Far More Likely To Be Insecure (And What To Do About It). Dave Wichers, OWASP Conferences Chair COO, Aspect Security [email protected] 301 604 4882. What Is AJAX?. AJAX is collection of techniques used to improve user experience Dynamic HTML - PowerPoint PPT Presentation
Citation preview
Copyright © 2006 - The OWASP FoundationPermission 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
OWASP
AppSec
Seattle
Oct 2006 http://www.owasp.org/
Why AJAX Applications Are Far More Likely To Be Insecure (And What To Do About It)
Dave Wichers, OWASP Conferences ChairCOO, Aspect [email protected] 604 4882
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 2006 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”
______________________________________________
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 2006 6
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 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.0Accept: */*Referer: http://maps.google.com/Accept-Language: en-usProxy-Connection: Keep-AliveUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0)Host: maps.google.comCookie: PREF=ID=8e2690f29f4050c8:TB=2:TM=1142526213;
OWASP AppSec Seattle 2006 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;
}}
OWASP AppSec Seattle 2006 9
AJAX XmlHttpRequest (XHR)
Same-origin policyCan’t request outside of parent domain
(JavaScript sandbox)
XHR is not new but is relatively untestedXHR introduced in 1998, but use only
recently popularFirst security problems only uncovered
recently Implementations in browsers vary
OWASP AppSec Seattle 2006 10
New AJAX Security Threats to Consider
Developer IssuesTesting IssuesArchitecture Issues
Server Side ANDClient Side
New Technology IssuesAJAX Privacy ConcernsNew and Existing Injection IssuesAJAX Bridges
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 2006 13
How Attackers See AJAX
SniffingInterceptionTampering
Attacks on Client Attacks on Server
Chained Attacks onOther Services or
Other Clients
Attacks onLocal Hosts
and Networks
Service(server-side)
Application(client-side)
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 2006 15
New Threat: Testing Issues
ComplexityMore moving parts in
distributed systemsOnly getting worse with Web
Services/SOA
Hidden codeAJAX code is difficult to
manageGoogle Web Toolkit solves
this problem by compiling Java into JavaScript
Difficulty of testingNo testing tools
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 2006 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 requestsUntrusted Trusted, controlled Secure, controlled Highly protected
Web ServiceXMLRPC
AJAX - JSON
Business logic
SOA layer
Limited state
OWASP AppSec Seattle 2006 18
Attack Surface Change When Moving to AJAX
Present.Layer
AJAX Enabled Web App
Browser(HTML and
Bus.Logic
Browser(HTML andJavaScript)
Client-ServerInterface
AJAX(PL)
DataLayer
Interface Changes
AJAX(DL)
AJAX(BL)
Busin.Logic
Present.Layer
Standard Web App
Browser(HTML andJavaScript)
Client-ServerInterface
DataLayer
Busin.Logic
Data Layer
Pure AJAX Web App
Browser(HTML andJavaScript)
Client-ServerInterface
AJAX(PL)
*Of course, any architecture is possible
Goal: Understand the Server interface and make it as
simple as possible
OWASP AppSec Seattle 2006 19
New Threat: New Technology Issues
JavaScriptLanguage is not greatNot standardStill evolving
Protocols and parsersBrand new
Web servicesStill very new
OWASP AppSec Seattle 2006 20
REST vs. SOAPGET http://ajax.com/getData HTTP/1.0Accept: */*Referer: http://ajax.com/Accept-Language: en-usProxy-Connection: Keep-AliveUser-Agent: Mozilla/4.0Host: ajax.comCookie: JSESSIONID=9ABF9B823A874823A874
HTTP/1.1 200 OKContent-Type: text/xmlDate: Wed, 03 Nov 2004 23:31:00 GMTServer: Apache Coyote/1.0Connection: close
<books> <book> <title>JavaScript Guide</title>
POST /webservices/getData HTTP/1.1Host: ajax.comContent-Type: text/xmlContent-Length: 140Cookie: JSESSIONID=9ABF9B823A874823A874
<?xml version=“1.0” encoding=“utf-8”?><soap:Envelope>… <soap:Body> …xml parameters…
HTTP/1.1 200 OKContent-Type: text/xmlDate: Wed, 03 Nov 2004 23:31:00 GMTServer: Apache Coyote/1.0Connection: close
<?xml version=“1.0” encoding=“utf-8”?><soap:Envelope>…<books> <book> <title>JavaScript Guide</title>
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
OWASP AppSec Seattle 2006 21
XML vs. JSON
{"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> ...
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
OWASP AppSec Seattle 2006 22
AJAX Privacy Concerns
AJAX has client side stateCookiesXML DataDOM
All of these can be manipulated byHostile code injected into clientBy user directlyNot private in any way
OWASP AppSec Seattle 2006 23
Increased Threat: Injection Attacks
Server SideCode Injection – e.g., Most PHP AJAX tool kits (e.g.: AJason, JPSpan and CPAINT) allow remote code injection by allowing client-side server code invocationXML and XPATH injection – just like SQL injection
Client SideScript Injection – i.e., Cross Site Scripting (XSS)DOM injection – client side attacks now much easierJSON injection – be careful how you decode!XML and XSLT injection – access or reformat dataCustom 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 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!!
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 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
OWASP AppSec Seattle 2006 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)
OWASP AppSec Seattle 2006 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
Note:
Almost no built-in security in AJAX environments, so you have to build these yourself
OWASP AppSec Seattle 2006 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?
OWASP AppSec Seattle 2006 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
OWASP AppSec Seattle 2006 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