Be Afraid. Be Very Afraid. Javascript security, XSS & CSRF

Be Afraid, Be Very Afraid
JavaScript Security, XSS, CSRF and Clickjacking
Mark Stanton - Gruden

Definitions
•  XSS – Cross Site Scripting
•  CSRF – Cross Site Request Forgery

Cross Site Scripting: MySpace
How Samy became very popular
Samy’s script made everyone who viewed his profile:
•  Add him as a friend
•  Embed the script in their profiles

Cross Site Scripting: MySpace
How did it work?
<div id=quot;mycodequot; style=quot;background:url('java
script:eval(document.all.mycode.expr)')quot; expr=quot;...lots of JS here...quot; >

•  JS inside CSS URL
•  Line break in the word “javascript”
•  Evaluation of a expression

Cross Site Scripting
What is Cross Site Scripting?
•  Untrusted data enters the system
–  URL, Form or Cookie data
–  HTTP Header
–  Syndicated feed
–  other offline system
•  Data then presented to the user & executed in their browser
•  Interferes with the intended interaction between a user and a site

How is it possible?
•  Browser environment is insecure by design
–  Multiple contexts, multiple parsers
–  XML, HTML, CSS, JavaScript, DOM, Cookie, URI, VBScript
–  All interacting in semi-structured ways
•  This makes AJAX and Web 2.0 Mash ups so powerful

Context Switching
•  HTML to JS
<script>alert(‘XSS’)</script>
<body onload=alert(‘XSS’)>

•  URL to JS
<iframe src=javascript:alert(‘XSS’)>

•  CSS to JS
background:url(javascript:alert(‘XSS’))

Same-origin Policy
•  Prevents document from one site setting or getting properties of a document
from another
•  Same origin means same protocol, port and host
•  So if I frame another site - I can’t modify or read it

But...
•  Included JS runs in the context of the current page
•  Scripts running in the page context have “root” access to a site

What can happen if an attacker gets a script on your page?
•  Perform action against website as if they are the user
•  Read the contents of pages and cookies
•  Control the display & show fake content to user
•  Send information to any server in the world
•  Request additional scripts from anywhere

What can happen if an attacker gets a script on your page?
•  SSL is no protection
•  Logins are no protection

Cross Site Scripting: Demo
What happened?
•  Cookies stolen
•  Interface vandalised
•  Users prompted to download malware
•  DB poisoned - other users affected

Cross Site Request Forgery: GMail
GMail vulnerability used to steal a domain
•  Visits evil site while logged into GMail
•  Evil site POSTs to GMail creating a new filter
•  Filter forwards all mail to attacker and deletes mail
•  Attacker initiates domain
transfer process

Cross Site Request Forgery
Session riding
•  Uses persistent sessions to execute actions against a service
•  Many Web 2.0 services are vulnerable

Clickjacking
UI Redressing
•  User is tricked into inadvertent
actions
–  A dummy button is shown, then
target page is loaded over the top
in a transparent iframe
–  User thinks they are clicking the
dummy button, but are interacting
with a site they can’t see

Clickjacking: Twitter
Don’t Click
•  Mischievous page loads transparent
iframe containing Twitter post
•  User shown a button saying “Don’t
Click”
•  Click takes place in iframe and
results in tweet being sent
•  Grows exponentially
•  Twitter implements frame buster

Solutions
Sanitise Input
•  Whitelists
–  Allow <strong>, <em> and <br> only
–  Does help, but not 100%
•  Blacklists
–  Block <script> and friends
–  Extremely common attack vector
–  Extremely difficult to block most attacks
–  Coldfusion’s XSS protection = FAIL!

Solutions
Escape Output
•  HTML Entity Encoding - HTMLEditFormat()
•  Doesn’t always work
–  In <script>
–  In onmouseover=
–  In CSS
–  In URLs
•  Need to be aware of your context

Solutions
The OWASP ESAPI
•  5 Rules for escaping output
#1 - HTML Escape before inserting into element content
#2 - Attribute Escape before inserting into attributes
#3 - JavaScript Escape before inserting into JavaScript data values
#4 - CSS Escape before inserting into style property values
#5 - URL Escape before inserting into URL attributes
•  Java API that implements these rules
•  100% safe?

Solutions
The OWASP ESAPI
<cfset ESAPI = createObject('Java','org.owasp.esapi.ESAPI')>

<cfsavecontent variable=quot;evilStringquot;>
<div id=quot;mycodequot; style=quot;background:url('java
script:eval(document.all.mycode.expr)')quot; expr=quot;alert('XSSed')quot;>
</cfsavecontent>

<cfoutput>
#evilString#
#ESAPI.encoder().encodeForHTML(evilString)#
#ESAPI.encoder().encodeForHTMLAttribute(evilString)#
#ESAPI.encoder().encodeForCSS(evilString)#
#ESAPI.encoder().encodeForJavascript(evilString)#
#ESAPI.encoder().encodeForURL(evilString)#
</cfoutput>

Solutions
Minimise Attack Surface
•  Don’t allow GET to modify data
•  Strict server-side validation of all input
•  Check referrer
•  Use transaction tokens or “crumbs” - derived from timestamp & user id
•  Double submit cookies
•  Use frame busting scripts
•  Short session timeouts / in-memory cookies

Solutions
Design for a breach
•  Assume some portion of your users’ accounts will be hijacked at some point
•  What if a users email account is hacked?
•  Forgotten password functions should use secret question
•  Two factor authentication where appropriate
•  Can you rollback or recover?
•  Do you have an audit trail?

Solutions
Think very carefully about 3rd party scripts
•  Google Analytics
•  Hosted Libraries
•  Digg
•  AddThis

Would you give Telstra the keys to your house?
What about your cleaner?

Solutions
Must allow untrusted 3rd party JavaScript?
Use safe sub-sets:
•  Adsafe
•  Caja

Solutions
Browsers are getting better
•  Many exploits depend on bugs in browser parsers
•  Holes are being rapidly closed
•  IE6 is still horribly broken and has market share

Using Flash and PDF?
They each have their own issues to consider
•  Certain version of the Acrobat Reader have serious vulnerabilities
http://path/to/pdf/file.pdf#foo=javascript:code_here

•  Flash is also some potential weak points:
<cross-domain-policy>
<allow-access-from domain=quot;*quot;/>
</cross-domain-policy>

Conclusion
•  A lot of responsibility lies with developers
•  Use a holistic, multi-pronged approach

Thanks
Links
•  http://blog.gruden.com/category/js-security
•  http://delicious.com/markstanton/js-security
•  http://twitter.com/MarkStanto

Thanks to pierre_tourigny (http://www.flickr.com/photos/pierre_tourigny/367078204/)

Be Afraid. Be Very Afraid. Javascript security, XSS & CSRF

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (14)

Similar to Be Afraid. Be Very Afraid. Javascript security, XSS & CSRF

Similar to Be Afraid. Be Very Afraid. Javascript security, XSS & CSRF (20)

Recently uploaded

Recently uploaded (20)

Be Afraid. Be Very Afraid. Javascript security, XSS & CSRF