Who am I?

• Work as a developer
• Leader of the Security Competency group at BEKK
• OWASP Norway Chapter lead
• Member of Norwegian Honeynet Project
• Above average interest in security

The need for cross domain communication

• Mashups
• Reading data from subdomains
• Reading data from trusted third-parties
  

Frames

Frames

Script

$.get("http://domain-b.com/", function(data) { ... });

Same Origin Policy

• the same protocol
• the same port number
• the same host name

Proxying

$.get("http://domain-a.com/proxy?url=http://domain-b.com", 
	function(data) { ... }
);

• Browser-support
• Third-party domains
• Server-side validation

• Cannot reuse existing authentication

• Whitelist the hostnames allowed for proxying

Frames - document.domain

SOP Hacks

• FrameElementTransport (FF1-FF2) - frameElement
• NIX (IE6/7) - window.opener
• FIM - Fragment identifier
• WindowNameTransport - window.name

• They are hacks - not necessarily future-proof
• Little or no control over receiver/sender

JSONP - JSON with Padding

• Loading data from third-party through <script>-tag:

  <script>
  function setData(data) {
  	//handle data
  }
  </script>
  <script src="http://domain-b.com/data"></script>

• The loaded script automatically calls a predefined function delivering the data:

  setData({"some":"data", ...});

JSONP - JSON with Padding

• evil.com:

  <script>
  function setData(data) {
    stealData(data);
  }
  </script>
  <script src="http://domain-b.com/data"></script>

JSONP - JSON with Padding

• Reuse existing authentication/session
• Easy to setup

• Not secure for private data - any site can add the same script tag
• It's script - not data → trust

Flash

• Flash can communicate with javascript:

  ExternalInterface.call("setData", data);

• Flash can make cross domain HTTP requests
• Policy-based - Data provider must have /crossdomain.xml

  <?xml version="1.0" encoding="UTF-8"?>
  <cross-domain-policy>
    <allow-access-from domain="domain-a.com" />
  </cross-domain-policy>

• Works

• A bit cumbersome to setup
• Requires flash - will not work on iOS

Open crossdomain.xmls

Alexa top 100 local domains:

	27
	30
	31

Silverlight

• Can communicate with javascript:

  HtmlPage.Window.Invoke("setData", data);

• Silverlight can make cross domain HTTP requests
• Policy-based - uses clientaccesspolicy.xml
• Fallback to crossdomain.xml

• Works

• A bit cumbersome to setup
• Requires Silverlight - limited platform support

HTML5 - postMessage

var targetFrame = document.getElementById("theIframe").contentWindow;
targetFrame.postMessage(data, "http://domain-b.com");

if (window.addEventListener) {
        window.addEventListener("message", receiveMessage, false);
} else {
        window.attachEvent("onmessage", receiveMessage);
}
function receiveMessage(event) {
	if (event.origin !== "http://domain-a.com") { //IMPORTANT: always check origin
		return;
	}
	// handle message
}

HTML5 - postMessage

• Built for security and SOP - not a hack
• Supports third-party domains

• Support in older browsers

• Do NOT use * as target for messages
• Always check origin of message before processing

Cross domain XHR

• Ajax request towards third-party domains
• Access to the response controlled by response headers: Access-control-*

Cross domain XHR

• Pattern for:
  • application/x-www-form-urlencoded, multipart/form-data, or text/plain
  • no custom headers

GET http://domain-b.com/some/resource
...

200 OK
Access-Control-Allow-Origin: http://domain-a.com
...

Cross domain XHR - preflight

OPTIONS http://domain-b.com/some/resource
...

200 OK
Access-Control-Allow-Origin: http://domain-a.com
...

POST http://domain-b.com/some/resource
Content-Type: application/json
...

200 OK
Access-Control-Allow-Origin: http://domain-a.com
...

Cross domain XHR - more headers

• Allowed verbs:
  Access-Control-Request-Method: POST
Access-Control-Allow-Methods: POST, GET, OPTIONS
• Allowed custom headers:
  Access-Control-Request-Headers: X-PINGOTHER
Access-Control-Allow-Headers: X-PINGOTHER
• For how long can the client cache the preflight:
  Access-Control-Max-Age: 1728000
• Is the client allowed to include credentials (authentication cookies etc.):
  Access-Control-Allow-Credentials: true

Cross domain XHR

• Built for security and SOP - not a hack
• Supports third-party domains

• Support in older browsers

• Do NOT use for private data:
  Access-control-allow-origin: *
Access-control-allow-credentials: true
• http://www.shodanhq.com/search?q=%22access-control-allow-credentials%3A+true%22+AND+%22access-control-allow-origin%3A+%22

Cross domain XHR

• http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html

function fileUpload(url, fileData, fileName) {
   var fileSize = fileData.length,
     boundary = "xxxxxxxxx",
     xhr = new XMLHttpRequest();
   xhr.open("POST", url, true);
   xhr.setRequestHeader("Content-Type", 
	"multipart/form-data, boundary="+boundary);
   xhr.setRequestHeader("Content-Length", fileSize);
   var body = "--" + boundary + "\r\n";
   body += 'Content-Disposition: form-data; name="contents";" + 
		"filename="' + fileName + '"\r\n';
   body += "Content-Type: application/octet-stream\r\n\r\n";
   body += fileData + "\r\n";
   body += "--" + boundary + "--";
   xhr.send(body);
}

XDomainRequest

• Reuses the Access-control-allow-origin-header

var xdr = new XDomainRequest(); 
xdr.open("get", "http://domain-b.com/some/resource");
xdr.send();

• Built for security and SOP - not a hack
• Supports third-party domains

• IE-only
• Text/plain and no custom headers
• No authentication cookie reuse

WebSockets

• Establish socket between server and browser from javascript
• Socket is established using HTTP

• Server push
• Third-party domains

• New browsers only

• Keeps connection open
• First version found to be flawed security-wise

easyXDM

• http://easyxdm.net/wp/
• Abstraction over message transports

• Works in all browsers

• Uses hacks in older browsers

New browser security features

CSP - Content Security Policy

• First implemented in Firefox
• Later supported also in Chrome
• Now a w3c standard

• Server instructs browser
• Header based: Content-Security-Policy
• Can use <meta http-equiv="Content-Security-Policy" content="">
• Firefox: X-Content-Security-Policy
• Chrome: X-Webkit-CSP

CSP - Directives

Content-Security-Policy: default-src *; script-src 'self' *.google.com https://www.owasp.org:443

• default-src - the default
• script-src - javascript
• object-src - flash, java etc.
• style-src - stylesheets (CSS)
• img-src - pictures
• media-src - video and audio
• frame-src - iframes
• font-src - fonts
• connect-src - websockets, xhr-requests

CSP - special sources

• 'self' - same origin as website
• 'none' - no sources allowed
• 'unsafe-inline'
  • valid for style-src and script-src
  • allows inline script tags and event handlers in the page
  • disables a major defense against reflected and persisted XSS
• 'unsafe-eval'
  • valid for script-src
  • allows eval(),setTimeout() and Function()
  • disables a defense against one kind of DOM-based XSS

CSP - support

• http://erlend.oftedal.no/blog/csp/readiness/
• Chrome - 100%
• Firefox - 'unsafe-inline' and 'unsafe-eval' ++ does not work

• http://code.google.com/p/chromium/issues/detail?id=93196

• Actual header name in the spec is Content-Security-Policy but no browser yet supports it

CSP - reporting

• report-uri - this directive instructs browser to send a json report when content conflicts with the given CSP
• X-Content-Security-Policy-Report-Only - no actual blocking - just reporting

CSP - is it being used

• http://www.shodanhq.com/search?q=x-content-security-policy
• http://www.shodanhq.com/search?q=x-webkit-csp

HSTS - Strict Transport Security

Strict-Transport-Security: max-age=14400

Strict-Transport-Security: max-age=14400; includeSubDomains

• If received over https, the browser will always use https regardless of URLs for the given number of seconds
• Supported in Chrome, FF4+,

• http://erlend.oftedal.no/blog/tools/hsts/

X-Frame-Options

• Clickjacking defense
• Policy for whether a website can appear within an iframe

X-Frame-Options: deny

X-Frame-Options: sameorigin

X-Frame-Options: allow-from http://erlend.oftedal.no

• Supported in IE8+, Chrome, Firefox, Safari, Opera

• http://erlend.oftedal.no/blog/tools/xframeoptions/

Iframe sandboxing

<iframe sandbox src="..." ></iframe>

<iframe sandbox="allow-scripts" src="..." ></iframe>

• Sandbox-directives:
  • Allow-scripts
  • Allow-sameorigin
  • Allow-top-navigation
  • Allow-forms
• IE-only:

  <iframe security="restricted" src="..." ></iframe>

• http://erlend.oftedal.no/blog/tools/iframe/

X-Content-Type-Options

X-Content-Type-Options: nosniff

• Asks browser to stop guessing the content type

XSS-filtering

• Introduced in IE8
• Later supported in Chrome
• Checks if an attack from a URL parameter is reflected in the page
• Only a defense against reflected XSS attacks and simple DOM-based XSS

• Weird false positives - IE8 could not load http://www.google.com/search?q=<script>

• Erlend Oftedal - @webtonull
• erlend@oftedal.no

MalaRIA

• Malicious and Rich Internet Application
• Exploits insecure crossdomain.xmls
• Uses a malicioius client side flash or silverlight application on a web page
• Attacker can use the victims browser as a proxy and surf using the victims session

• http://erlend.oftedal.no/blog/?id=107

MalaRIA

Demo:

HTML5 = MalaRIA + CORS

• Extension to MalaRIA
• Exploits Access-Control-Allow-Origin: *
• Uses websockets to connect back to proxy

• http://koto.github.com/cors-proxy-browser/malaria.html