Is Secure Ajax an Oxymoron
-
Upload
sampetruda -
Category
Documents
-
view
588 -
download
3
description
Transcript of Is Secure Ajax an Oxymoron
Is Secure Ajax an Oxymoron
Scott Matsumoto
Principal Consultant
Cigital, Inc
Dulles, VA
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