Is Secure Ajax an Oxymoron

30
Is Secure Ajax an Oxymoron Scott Matsumoto Principal Consultant Cigital, Inc Dulles, VA [email protected]

description

 

Transcript of Is Secure Ajax an Oxymoron

Is Secure Ajax an Oxymoron

Scott Matsumoto

Principal Consultant

Cigital, Inc

Dulles, VA

[email protected]

Course Objectives

• Have you write more secure Ajax applications

• Give you and appreciation of how Ajax is insecure

• Provide you with guidance about how to work around Ajax security problems

Ajax Applications Are Cool

• We want our

application UIs to be

as cool as Google

maps and Netflix

• Real end-user benefit

from more responsive

apps

Ajax Pushes Code and Data to the

Client

Ajax Applications

• Fine-grained APIs

• Client-side state and logic

Traditional Web Applications

• Coarse-grained APIs

• State and Logic on Server

It Sounded Like a Good Idea at the

Time…

• Why are you adopting Ajax?

– Competitive advantage

– Better, faster user experience

– Higher user satisfaction

– Lower abandonment rates

• Is adopting Ajax free?

[in]Security is Part of the Price

� Integrity of the client-side business logic

� Integrity of the client-side data

� Integrity and confidentiality of communication channel

� Integrity of the data exchanged between the client and server (both directions)

Resist attacks on the:

12 3

4

End User

View

DOM

Controller

Client Trust

Zone

Securing the Client Is Hard

• The attacker owns the

machine and local network

• Client state cannot be

secured; all sensitive

information must remain

opaque

• Javascript is just text with

no way of validating the

integrity of the code

• Same problems as

securing a MMOG

12 3

Fine-Grained Server API Woes

• Overall increased attack surface

• Allows for more sophisticated cross-site scripting attacks by abusing your server API

• Denial of Service through use

The Dangers of Exposing Server

Side Objects

1

23

Enables more

sophisticated

XSS attacks

Overload

server with too

many requests

(DoS)

Increases the overall attack surface

Ajax Enables More Sophisticated

XSS Attacks

• The application has created a richer server API to support Ajax

• The application has a cross-site scripting (XSS) vulnerability (not necessarily) related to the Ajax APIs

• An attacker can also use that rich Ajax API as part of the XSS exploit

Overload the Server with Too Many

Requests

• Fine-grained APIs require more requests to get work done

• Extreme case is Google Search Suggest API

– Incremental search on each character you

type

• Inadvertently design in Denial of Service

Increased Attack Surface

• Server-side

– Heightens the need for a comprehensive

approach to input validation and output

encoding in your application design

• Client-side injections

– JSON

– DOM

Client-side Injections

1

Attacker can inject

1. Javascript

2. JSON

3. XML

Injected code

is stored in

the model

Javascript

gets injected

into dynamic

pages

Injected Javascript

subverts to client-

side logic

Injected JSON

subverts client-

side objects

Injected JSON

and XML are

written into the

DOM by the

Javascript

Remediation Through Better API

Design

• Use Façade objects to reduce attack surface

• Design a systemic way of handling input validation and output encoding

• Ensure that all entry points require proper authentication

Use Façade Objects to Reduce

Attack Surface

• Better separation of concerns

• Simplified interface

• Coarse-grained

Mashup – A Tale of Two Servers

• Mycoolmashup.com

• Want to integrate store locations with Google maps

• You make the following call:xmlhttp.open(“maps.google.com/…”)

• ARG ! – Same origin policy

app.cigital.com

End User

browser

app.cigital.com

app.cigital.com

sandbox

cigital.com

app.youtoo.com

youtoo.com

app.youtoo.com

app.youtoo.com

sandbox

app2.cigital.com

Javascript Same Origin Policy

(Simplified) app2 would

get its own

sandbox

Browser maintains a

separate Javascript

sandbox for each

server

The same origin policy

prevents cross server

Javascript requests

Building Your Mashup

Solution 1: Subvert the browser security

– <script> will load cross site code

Solution 2: Write the mashup code on the server

– Proxying doesn’t scale well

Solution 3: Wait for new HTML tags

– IE8/Firefox3…?

Subverting Same Origin Policy

Insecure, Bad Practice*

* Gmail got bit by this type of bug

Page is from

app.cigital.com

The same origin policy

doesn’t apply to HTML

tags!

youtoo( <JSON object> )

The same origin policy

prevents cross server

Javascript requests

Mashup on the Server

(Not Perfect, but Recommended)

• Disadvantages

– Additional server resources to scale

• Advantages

– Write business logic in a trusted environment

– More mature development, execution and

testing environment

CSRF Solution Using Ajax

• Cross-site Request Forgery (CSRF) attacks can be mitigated using Ajax

• Best mitigation involves a one-time-use token

• Solutions vary the scope of the token during “action” creation

• Leverages the Single Origin Policy

Double Submit the Cookie PatternThe same origin policy prevents

Javascript in the app.cigital.com

sandbox from reading the

app.youtoo.com session cookie

Compare session cookie

parameter against session

cookie HTTP Header

Pass the session cookie as part

of the data in forms and URIs

1

2 3

Toolkits

How Do You Choose?Front End Toolkits

• Cross Browser Libraries

– CPaint

– Dojo

– Sarissa

– Prototype

• Widgets

– Scriptaculous

– Rico

– Rialto

Back End

• Small Frameworks

– DWR

– SAJAX

– JSON-RPC

• GWT

• Atlas

• Backbase

Support for

Client and

Server?

Supported

Languages?

Which

Widgets?

Which

Browsers?

Toolkit Security Checklist

• Server side

– API Authorization mechanism integrated with

platform

– Session Management managed as part of the

framework

– XSS and/or CRSF prevention

• Client side

– Integration with the server-side

Software Security Checklist

• Ajax just re-arranges where code lives

• Ajax Security is just Software Security

• Security of your Ajax application depends on you

– Tools and Toolkits help, but are not silver

bullets

– Practice good secure development hygiene

• Be careful with sample code

Sample Code Is Not SecureWhat’s Wrong with this Code?

function OnFailed(error)

{

var stackTrace = error.get_stackTrace();

var message = error.get_message();

var statusCode = error.get_statusCode();

var exceptionType = error.get_exceptionType();

var timedout = error.get_timedOut();

// Display the error.

var RsltElem = document.getElementById("Results");

RsltElem.innerHTML = "Stack Trace: " + stackTrace + "<br/>" +

"Service Error: " + message + "<br/>" +

"Status Code: " + statusCode + "<br/>" +

"Exception Type: " + exceptionType + "<br/>" +

"Timedout: " + timedout;

}

Printing a Stack Trace is not

“Failing Securely” – one of the

Ten Principles of Secure Design

Is Ajax Less Secure?

• How much code and data is being moved to the client?

• What code and data is being moved to the client?

12 3

4

Ajax Is As Secure As You Design

and Code It

• Does your SDLC already handle secure development practices?

– Abuse Cases and Security Requirements

– Secure Design Analysis

– Secure Code Review

– Risk-based Security Testing

Wrap Up

• Ajax presents an application development paradigm that provides benefit

• Ajax presents software security challenges that build on you web application security hygiene

• Your Ajax application will be as secure as you make it

Thank You for Your Time

Scott Matsumoto

Principal Consultant

Cigital, Inc

Dulles, VA

[email protected]