Is Secure Ajax an Oxymoron - Scott Matsumoto Principal Consultant Cigital, Inc Dulles, VA
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Is Secure Ajax an Oxymoron
Scott Matsumoto
Principal Consultant
Cigital, Inc
Dulles, VA
smatsumoto@cigital.com
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
• Real end-user benefit
from more responsive
apps
• We want our
application UIs to be
as cool as Google
maps and NetflixAjax Pushes Code and Data to the
Client
Traditional Web Applications
• Coarse-grained APIs
• State and Logic on Server
Ajax Applications
• Fine-grained APIs
• Client-side state and logicIt 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
Resist attacks on the:
Integrity of the client-
side business logic
4 Integrity of the client-
1
2 3 side data
Integrity and
confidentiality of
communication
channel
Integrity of the data
exchanged between
the client and server
(both directions)Securing the Client Is Hard
• The attacker owns the
Client Trust
machine and local network
Zone
• Client state cannot be
1 3
2
secured; all sensitive
information must remain
DOM
View
opaque
Controller
End User
• Javascript is just text with
no way of validating the
integrity of the code
• Same problems as
securing a MMOGFine-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
3 Increases the overall attack surface
Overload 2
server with too
many requests
(DoS)
Enables more 1
sophisticated
XSS attacksAjax 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 exploitOverload 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 ServiceIncreased 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
– DOMClient-side Injections
Attacker can inject Injected code
1. Javascript 1 is stored in
2. JSON the model
3. XML
Injected JSON
subverts client-
side objects
Javascript
Injected JSON gets injected
and XML are into dynamic
written into the pages
DOM by the
Javascript
Injected Javascript
subverts to client-
side logicRemediation 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
authenticationUse Façade Objects to Reduce
Attack Surface
• Better separation of concerns
• Simplified interface
• Coarse-grainedMashup – 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
Javascript Same Origin Policy
(Simplified) app2 would
get its own
cigital.com
sandbox
app.youtoo.com app.cigital.com
sandbox sandbox
browser
app.cigital.com app2.cigital.com
youtoo.com
app.youtoo.com app.cigital.com
End User
app.youtoo.com
Browser maintains a The same origin policy
separate Javascript prevents cross server
sandbox for each Javascript requests
serverBuilding Your Mashup
Solution 1: Subvert the browser security
– 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*
The same origin policy Page is from
prevents cross server app.cigital.com
Javascript requests
youtoo( )
The same origin policy
doesn’t apply to HTML
* Gmail got bit by this type of bug
tags!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 environmentCSRF 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 Pattern
The same origin policy prevents
1 Javascript in the app.cigital.com
sandbox from reading the
app.youtoo.com session cookie
Compare session cookie
Pass the session cookie as part 3 parameter against session
2
of the data in forms and URIs cookie HTTP HeaderToolkits
How Do You Choose?
Back End Front End Toolkits
• Small Frameworks • Cross Browser Libraries
– DWR Supported
– CPaint Which
Browsers?
– SAJAX Languages? – Dojo
– JSON-RPC – Sarissa
• GWT – Prototype Which
Widgets?
• Atlas Support for • Widgets
Client and
• Backbase Server? – Scriptaculous
– Rico
– RialtoToolkit 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-sideSoftware 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 codeSample Code Is Not Secure
What’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 + "" +
"Service Error: " + message + "" +
"Status Code: " + statusCode + "" +
"Exception Type: " + exceptionType + "" +
"Timedout: " + timedout;
}
Printing a Stack Trace is not
“Failing Securely” – one of the
Ten Principles of Secure DesignIs Ajax Less Secure?
• How much code and data is being moved
to the client?
• What code and data is being moved to the
client?
4
1 3
2Ajax 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 TestingWrap 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
smatsumoto@cigital.comYou can also read
