why ajax applications are far more likely to be insecure (and what to do about it)

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


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


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”

______________________________________________


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


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


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;


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;

}}


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


New AJAX Security Threats to Consider

Developer IssuesTesting IssuesArchitecture Issues

Server Side ANDClient Side

New Technology IssuesAJAX Privacy ConcernsNew and Existing Injection IssuesAJAX Bridges


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


How Developers See AJAX

Service(server-side)

Application(client-side)


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)


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


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


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


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


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



DataLayer

Busin.Logic

Data Layer

Pure AJAX Web App



AJAX(PL)

*Of course, any architecture is possible

Goal: Understand the Server interface and make it as

simple as possible


New Threat: New Technology Issues

JavaScriptLanguage is not greatNot standardStill evolving

Protocols and parsersBrand new

Web servicesStill very new


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


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


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


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


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!!


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


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


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


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


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)


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


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?


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


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

OWASP AppSec Seattle 2006

AQ&Q U E S T I O N SQ U E S T I O N S

A N S W E R SA N S W E R S

Questions and Answers

why ajax applications are far more likely to be insecure (and what to do about it)

Documents