Transcript The Dark Side of Ajax Brian Chess, Ph.D. Chief Scientist Fortify Software [email protected] 6th OWASP AppSec Conference Milan - May 2007 Copyright © 2007 - The OWASP Foundation Permission is.

The Dark Side of Ajax
Brian Chess, Ph.D.
Chief Scientist
Fortify Software
[email protected]
6th OWASP
AppSec
Conference
Milan - May 2007
Copyright © 2007 - The OWASP Foundation
Permission 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
http://www.owasp.org/
Mashup
Pink Floyd
Dark Side of the Moon
AJAX all purpose cleaner
6th OWASP AppSec Conference – Milan – May 2007
Ajax
Fancier and easier-to-use web applications using open
standards
Asynchronous
JavaScript
And
XML
Web 1.0
Server
(smart)
Ajax is a matter of degree, not kind
Security implications?
Server
(smart)
Web page
(dumb)
Ajax
Web page
(smart)
6th OWASP AppSec Conference – Milan – May 2007
Success is foreseeing failure.
– Henry Petroski
6th OWASP AppSec Conference – Milan – May 2007
What’s wrong with Ajax?
Something smells funny ...
Today’s programming craze is tomorrow’s security disaster
Could more JavaScript possibly be better?
A sampling of the almost 400 CVE entries that mention
JavaScript:
CVE-2007-1794
The Javascript engine in Mozilla 1.7 and earlier on Sun Solaris 8,
9, and 10 might allow remote attackers to execute arbitrary code via vectors involving
garbage collection that causes deletion of a temporary object that is still being used.
CVE-2006-4571
Multiple unspecified vulnerabilities in Firefox before 1.5.0.7,
Thunderbird before 1.5.0.7, and SeaMonkey before 1.0.5 allow remote attackers to
cause a denial of service (crash), corrupt memory, and possibly execute arbitrary code
via unspecified vectors, some of which involve JavaScript, and possibly large images or
plugin data.
CVE-1999-0793
Internet Explorer allows remote attackers to read files
by redirecting data to a Javascript applet.
CVE-1999-0790
A remote attacker can read from a Netscape user's cache via
JavaScript.
CVE-1999-0347
Internet Explorer 4.01 allows remote attackers to read local files
and spoof web pages via a "%01" character in an "about:" Javascript URL, which causes
Internet Explorer to use the domain specified after the character
6th OWASP AppSec Conference – Milan – May 2007
Developers say the darndest things
<c:if test="${param.sayHello}">
<!-- Let's welcome the user ${param.name} -->
Hello ${param.name}!
</c:if>
“We never intended the code
that's in there to actually be
production-ready code.”
Ryan Asleson
6th OWASP AppSec Conference – Milan – May 2007
Overview
Ajax from the programmer’s perspective
Ajax for malware
Old risks reconsidered
New risks on the horizon
The future of Ajax
6th OWASP AppSec Conference – Milan – May 2007
Ajax From the Programmer’s Perspective
Increased complexity makes frameworks attractive
Popular toolkits for Ajax development include
Google Web Toolkit (GWT)
Direct Web Remoting (DWR)
Microsoft ASP.net AJAX (formerly known as Microsoft Atlas)
Client-side libraries such as Prototype and Dojo
Also popular: ad-hoc (roll your own) Ajax
6th OWASP AppSec Conference – Milan – May 2007
Analysis of AJAX Frameworks
high
Ad-hoc
Very flexible, but hardest to get right
Client-side toolkits help
GWT
Very strict, but easy to get right
Flexibility
Ad-hoc
Atlas
DWR
Atlas
GWT
Very flexible and easy to get right
low
Ease of getting to work right
Uses regular ASP.NET features: controls, authentication, authorization
Uses regular .NET web service calls
DWR
Quite flexible, but not easy to get right
By default, all methods are exposed
6th OWASP AppSec Conference – Milan – May 2007
high
The Case of the Vanishing “X”
XML is disappearing from Ajax
Replaced by transporting data using JavaScript syntax
JavaScript Object Notation (JSON)
<book>
<title>JavaScript, the Definitive Guide</title>
<publisher>O'Reilly</publisher>
<author>David Flanagan</author>
<cover src="/images/cover_defguide.jpg" />
<blurb>elit.</blurb>
XML
</book>
JSON
{ "book":
{
"title":"JavaScript, the Definitive Guide",
"publisher":"O'Reilly",
"author":"David Flanagan",
"cover":"/images/cover_defguide.jpg",
"blurb":”elit."
}
}
6th OWASP AppSec Conference – Milan – May 2007
Example: DWR HTTP request
GET
/servlets/examples/dwr/exec/ApartmentDAO.findApartments.dwr?c
allCount=1&c0-scriptName=ApartmentDAO&c0methodName=findApartments&c0-id=3412_1178137104170&c0param0=string%3A2&c0-param1=string%3A2&c0param2=string%3A1500&xml=true& HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.
9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://localhost:8080/servlets-examples/dwrexample/dwr.html
6th OWASP AppSec Conference – Milan – May 2007
Example: DWR HTTP response
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/plain;charset=ISO-8859-1
Date: Wed, 02 May 2007 20:18:24 GMT
Content-Length: 1906
var s0=[];var s1={};var s2="93 Lombard St.";s1.address=s2;
var s3=2;s1.bathrooms=s3;var s4=2;s1.bedrooms=s4;var
s5="Toronto";s1.city=s5;var s6=16010;s1.id=s6;var
s7=1050;s1.price=s7;var s8="ON";s1.province=s8;
s0[0]=s1;var s9={};var s10="27 Winchester St.";s9.address=s10;
var s11=2;s9.bathrooms=s11;var s12=2;s9.bedrooms=s12;var
s13="Toronto";s9.city=s13;var s14=16003;s9.id=s14;var
s15=1050;s9.price=s15;var s16="ON";s9.province=s16;
s0[1]=s9;var s17={};var s18="352 Dufferin St";s17.address=s18;
...
DWREngine._handleResponse('3412_1178137104170', s0);
6th OWASP AppSec Conference – Milan – May 2007
Example: DWR client code
<script src='dwr/interface/ApartmentDAO.js'></script>
<script src='dwr/engine.js'></script>
<script src='dwr/util.js'></script>
...
function updateResults() {
DWRUtil.removeAllRows("apartmentsbody");
var bedrooms = document.getElementById("bedrooms").value;
var baths = document.getElementById("bathrooms").value;
var price = document.getElementById("price").value;
ApartmentDAO.findApartments(fill, bedrooms, baths, price);
$("resultTable").style.display = '';
}
6th OWASP AppSec Conference – Milan – May 2007
Example: DWR server configuration
<dwr>
<allow>
<convert converter="bean” match="dwr.sample.Apartment"/>
<create creator="new" javascript="ApartmentDAO"
class="dwr.sample.ApartmentDAO">
<include method="findApartments"/>
<include method="countApartments"/>
</create>
</allow>
</dwr>
6th OWASP AppSec Conference – Milan – May 2007
Example: Atlas server code
[System.Web.Script.Services.ScriptService]
[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class ApartmentDAO : System.Web.Services.WebService
{
[WebMethod]
public ArrayList findApartments(int bedrooms, int
bathrooms, int price)
{
// implementation
...
}
...
6th OWASP AppSec Conference – Milan – May 2007
Ajax For Malware
Exploit writers buy JavaScript books too
Web 2.0 exploits for Web 1.0 vulnerabilities
MySpace worm
Port scanning behind your firewall
Jikto
Cross-site scripting looks more and more like buffer overflow
Buffer Overflow
Cross-site Scripting
Allows Arbitrary Code Execution
Exploit is hard to write
Easy mistake to make in C/C++
Well known problem for decades
Allows Arbitrary Code Execution
Exploit is easy to write
Easy mistake to make in any language
Well known problem for a decade
6th OWASP AppSec Conference – Milan – May 2007
MySpace Worm
MySpace does bad input validation
Users to post a subset of HTML on their pages
no <script> tags, no use of the word “javascript”, etc
Users to add other users as “friends”
User “Samy” discovers some holes
Some browsers allow JavaScript in style attributes
Some browsers interpret “java\nscript” as “javascript”
...
All of the MySpace efforts to prevent JavaScript can be circumvented
Samy adds JavaScript to his page
Any visitor to his page automatically adds Samy as a friend: “Samy is my
hero”
Any visitor to a page where Samy is a friend will add Samy to their page
Worm!
MySpace goes down
6th OWASP AppSec Conference – Milan – May 2007
Port scanning behind your firewall
JavaScript can:
Request images from internal IP addresses, e.g.
<img src=“192.168.0.4:8080”/>
Use timeout/onerror to determine success/failure
Fingerprint webapps using known image names
Server
1) “show me dancing pigs!”
Malicious
Web page
2) “check this out”
3) port scan results
scan
Browser
scan
scan
6th OWASP
AppSec Conference – Milan – May 2007
Firewall
Jikto
JavaScript vulnerability scanner
Written by Billy Hoffman (with credit to Petko Petkov)
Capable of spreading like a worm through new XSS
vulnerabilities it discovers
Uses proxy to bypass same origin policy
Target
Site
attack
Mal
page
Google
Translate
response analyzer
Malicious
Site
6th OWASP AppSec Conference – Milan – May 2007
Moral to the story
No new vulnerabilities here, just better exploits
Good offense makes good defense more important
Good offense is making fast progress
6th OWASP AppSec Conference – Milan – May 2007
Defending Ajax Applications: Old Risks
Reconsidered
A new name for the same game
Same vulnerabilities, new programming language
Input validation
Exposing the server
6th OWASP AppSec Conference – Milan – May 2007
Same Vulnerabilities, New Programming Language
A cross-site scripting vulnerability entirely in JavaScript
q = location.search.split(“q=“)[1];
q = unescape(q);
div.innerHTML = “searching for “ + q;
6th OWASP AppSec Conference – Milan – May 2007
Old Risks Reconsidered: Input validation
Possible to lose track of where validation is performed
Server
Client
More entry points on the server
More, smaller, requests
Decentralized design
Easy to over-expose
More subtle entry points on the server
Looks like Web services
Hard to tell if method call initiated locally (safe) or remotely (dangerous)
Harder to tell what can be trusted
6th OWASP AppSec Conference – Milan – May 2007
Exposing Yourself with DWR
<dwr>
<allow>
…
<create creator=”new”
javascript=”ApartmentDAO”
class=”dwr.sample.ApartmentDAO”>
<exclude method=”countApartments”/>
</create>
</allow>
</dwr>
6th OWASP AppSec Conference – Milan – May 2007
Exposing Yourself with DWR
<dwr>
<allow>
…
<create creator=”new”
javascript=”ApartmentDAO”
class=”dwr.sample.ApartmentDAO”>
</create>
</allow>
</dwr>
6th OWASP AppSec Conference – Milan – May 2007
New Problem: Harder to Test
Dirty data shooters rely on Web 1.0 conventions
HTTP
HTML forms
1 parameter = 1 application variable
Ajax = more complex data structures
Ajax requires sophisticated browser emulation
How do you spider an Ajax application?
Looks much more like testing conventional software
6th OWASP AppSec Conference – Milan – May 2007
New Risk: JavaScript Hijacking
Basic Web browser security: Same Origin Policy
Can’t use JavaScript to peek at HTML from other domains
Protects Web sites from each other
Fundamental to Web security
Cross-site request forgery (CSRF)
JavaScript can submit a form request to another site
Not prevented by Same Origin policy
Weakness of cookie-based session management
Pervasive vulnerability
Attack against data integrity
JavaScript Hijacking breaks confidentiality too
If server responds to HTTP GET requests
If response is JavaScript syntax (arrays, function calls)
Attacker can use a <script> tag and witness execution of JavaScript
First vulnerability specific to Ajax
6th OWASP AppSec Conference – Milan – May 2007
JavaScript Hijacking in Action
Ajax app server
Malicious Server
1) “show me dancing pigs!”
GET
2) “check this out”
3) confidential data
Mal page
{ witness code }
<script src=“...”>
JavaScript
Browser
Firewall
6th OWASP AppSec Conference – Milan – May 2007
How the Popular Frameworks Stack Up
Framework
Dojo
DWR 1.1.4
GWT
jQuery
Microsoft A tlas
MochiKit
Moo.fx
Prototype
Rico
Script.aculo.us
xajax
Yahoo! UI
Summary
Supports JSON. Defaults to PO ST, but does not explicitly prev ent
JavaScript Hijacking.
Uses an expanded version of JSON. Does not implement any
JavaScript Hijacking prevention mechanisms.
Supports JSON. Uses POST by default; howev er, documentation
describes how to mak e GET requests instead and does not
mention any security ramifications.
Supports JSON. Defaults to GET.
Supports JSON. Uses POST by default, but allows programmers to
easily change PO ST to GET and encourages doing so for
performance and caching.
Supports JSON. Defaults to GET.
Supports JSON. Defaults to PO ST, but can easily be configured to
use GET.
Supports JSON. Defaults to PO ST when no method is specified, but
is easily customizable for using either POST or GET.
Does not currently support JSON, but will in the future. Supports
XML as a data transfer format. Defaults to GET.
Supports JSON. Prov ides additional UI controls and uses the
Prototype library for generating requests.
Does not currently support JSON, but will in the future. Supports
XML as a data transfer format.
Supports JSON. Responds to GET requests.
Prevents
JavaScript
Hijack ing?
No
No
No
No
No
No
No
No
N/A
No
N/A
No
6th OWASP AppSec Conference – Milan – May 2007
JavaScript Hijacking Exploit
function Object() {
this.province setter = captureObject;
}
function captureObject(x) {
var index = 0;
for (fld in this) {
var comma = (index != 0) ? ", " : "";
var value = ('province' == fld) ? x : this[fld];
objString += comma + fld + ": " + value;
index++;
}
objString +="<br>";
// add code to send data to attacker here
}
if (DWREngine == null) var DWREngine = {};
DWREngine._handleResponse = function(a, b) {}
<script src="http://localhost:8080/servletsexamples/dwr/exec/ApartmentDAO.findApartments.dwr?callCount=1&c0scriptName=ApartmentDAO&c0-methodName=findApartments&c0id=676_1176490045131&c0-param0=string%3A1&c0-param1=string%3A1&c0param2=string%3A1500&xml=true& HTTP/1.1"></script>
6th OWASP AppSec Conference – Milan – May 2007
Two Defenses Against JavaScript Hijacking
1.
Prevent CSRF
Default to POST not enough
Developers add GET so that result can be cached
Checking for a known HTTP header is not enough (Flash CSRF
vulnerability)
2.
Prevent execution of JavaScript
while(1);
/* ... */
Relying on object notation {} rather than array notation [] is silly
calling parseJSON() rather than eval() does not help
6th OWASP AppSec Conference – Milan – May 2007
How the Popular Frameworks Responded
Framew ork
Dojo
DWR 2.0
GWT
jQuery
Microsoft Atlas
MochiKit
Moo.fx
Prototype
Rico
Script.aculo.us
xajax
Yahoo! UI
Fixed in Next Release
Yes
Yes
Yes
No
No
Yes
No
Yes
N/A
Yes
N/A
added security docs
Head-in-the-sand defense
6th OWASP AppSec Conference – Milan – May 2007
JavaScript Hijacking Myths and Misunderstandings
This is a server administration problem.
It’s a programming problem.
Yeah yeah, but somebody could just do ‘view source’ and
accomplish the same thing.
The attacker is not the one running the web browser
But if you’ve got CSRF vulns, you’re toast anyway.
CSRF is bad, but this is worse: it adds breach of
confidentiality
This relies on some XSS vuln or a bug in the browser.
Not so, this is how the browser is supposed to work!
6th OWASP AppSec Conference – Milan – May 2007
Mashups Aren’t Secure
Scripts from multiple domains == security problem
Often use JavaScript callbacks and auto-generated <script> tags
Might be fine for Google maps, but not okay for confidential data
Pink Floyd
Dark Side of the Moon
AJAX all purpose cleaner
6th OWASP AppSec Conference – Milan – May 2007
The Future of Ajax
Better frameworks offer a chance to build security in
Prevent CSRF
Provide secure defaults
Opportunity for better validation
Better separation between display and controller
Better definition for browser/server interaction
Better Web standards
Cookies: broken, need *working* HTTP only cookies
Browsers: broken, need to distinguish between scripts from different
domains
Flash?
Documented security best-practices
Hard to mistake data and code
Well-defined system for cross-domain communication
6th OWASP AppSec Conference – Milan – May 2007
Summary
Ajax: a difference of degree
Attack techniques improving quickly
Technology pushed well past original design goals
Old best practices still apply
Don’t trust the client
Protect the client
New challenges
Harder to test
More complexity == more room for error
A new ally
Good opportunity to build security into Ajax frameworks
6th OWASP AppSec Conference – Milan – May 2007