#cwc2015

Security in the client

How the ecosystem is changing and so should we

Saturday 21st of February 2015 joe8bit.com/talk/chicagowebconf/

Joe Pettersson

@Joe8Bit | github.com/Joe8Bit

McKinsey & Company

Why?

We don't think about security enough

The fundamental problem

The 'Client' Environment

An environment where your code runs that you don't control is a fundamentally untrustworthy one

Something you know already

Strong decoupling

e.g. never trust the client

Something you need to think about

Bi-directional decoupling

e.g. never trust the data layer either

Blackbox Blackbox

Anti-pattern

A client side HTTP interface inherently trusting output from a service it's utilising


Attack vector

Stored/reflected XSS

We need to learn from decades of network security models and enforce multi-tiered trust boundries

Topics to consider

  • Coherent network topologies
  • DMZ's
  • Sanitised communication channels
  • Standardised and verifiable interfaces

Modular apps need modular security

Model View Controller
Model View Controller

Anti-pattern

A view implicitly trusting output from a model

Pattern

The DOM provides a big attack surface for XSS attacks so all interactions with it should be sanitised, regardless of their source

The concepts in clientside security are getting more complex

Purely clientside attacks

  • Content spoofing
  • Cross Site Scripting (XSS)
  • Cross Site Request Forgery (CSRF)
  • Information disclosure/leakage
  • Path traversal attacks
  • Authentication attacks
  • Cache poisoning
  • ...
  • A new generation of APIs

Communication API's

Web Messaging / Cross Domain Messaging

  • Sender: explicitly state the expected origin as the second argument to postMessage rather than *
  • Receiver: always check the origin attribute of the sender to verify the data is originating from the expected location

Validating FQDN's


if (message.origin.indexOf("foo.com") !== -1) { /* ... */ }

This is very insecure as foo.com.attacker.com will match, this goes for validating all FQDN's

Storage API's

Storing data in the client

  • Don't store sensitive information in localStorage/IndexDB (dump and pump attacks, no content protection like cookies)
  • Use sessionStorage instead of localStorage if persistent storage is not needed
  • Every object is shared within an origin and protected with the Same Origin Policy. Be careful when hosting multiple applications on the same origin that utilise localStorage
  • Watch out for cache poisoning when caching assets to localStorage

Multithreading API's

WebWorkers

  • It's relativley easy to perform DOS attacks that exploit resource heavy CPU opertions (e.g. recursive Fibonacci/prime factoring) in WebWorkers, in some extreme cases bricking the client

Misc. API's

iFrame's

  • Since their inception have been a massive attack vector
  • Use the sandbox attribute of an iframe for untrusted content (allow-forms, allow-popups, allow-pointer-lock, allow-same-origin, allow-scripts, allow-top-navigation)

Misc API's

Offline applications

  • Cache poisoning manifest files through MITM attacks over insecure networks. Use HTTPS.
  • ServiceWorkers? A potential solution

Watch out for Joe8Bit/metaspolit-manifest-poisoning in the coming days

Misc API's

Hardware API's

  • Battery API / Vibration API
  • Phone dialler API / Message API / Settings API / Contacts API (FirefoxOS)

WebGL

WebGL is a cross-platform, royalty-free web standard for a low-level 3D graphics API based on OpenGL ES 2.0, exposed through the HTML5 Canvas element as Document Object Model interfaces.

Punching a big hole through the sandbox, it needs to be "secure"

Security as part of the spec design

  • Undefined behaviours as part of OpenGL ES spec (e.g. readPixels API, extending outside the framebuffer)
  • Strict definition of out of range memory access (not in OpenGL specs)
  • All GPU resources allocated by a WebGL application are initially cleared to zero, in OpenGL these buffers are not zero'd before allocation
  • Strong OpenGL ES Shading Language (ESSL) validation, imposed limitations on loops and indexing expressions
  • DOS mitigation via GL_ARB_robustness

GPU drivers are awful1

1gpu_driver_bug_list_json.cc

GPU drivers are often out of date1

125% of Steam users using DirectX 10 capabale

Angle

  • code.google.com/p/angleproject/
  • The default WebGL backend for Chrome and Firefox
  • OpenGL to DirectX transpiler on Windows
  • Shader validation and translation on OSX and Linux

Driver blacklisting

khronos.org/webgl/wiki/BlacklistsAndWhitelists

Which leads to the fundamental challenge...

Classic browser execution context

Sandboxes all the way down

  • Process/tab isolation
  • The browser sandbox
  • OS process isolation
  • General user mode protections

WebGL execution context

Not so much with the sandboxes

  • "Process/tab isolation"
  • Browser sandbox
  • WebGL backend
  • Kernel mode

An attacked WebGL call stack

WebGL

WebGL is awesome

Testing

How security can fit into your process

Auditing

Security as a requirement for quality

  • Where are your integration points?
  • Where are your 'trust' boundries?
  • What is the breadth and depth of your attack surface?
  • What are the fundamental security implications of your technology choices?
  • Auditing === understanding risk

Auditing is asynchronous

Fits perfectly into the 'Github flow' model. Merger takes co-ownership of security consequences of merged code, as they should with quality and regressions

Automated Scanning

Penetration test vs Vulnerability scan


Venn

Tools

  • AppScan from IBM ($$$$)
  • WebInspect from HP ($$$$)
  • Burp Suite from Portswigger ($$)
  • Metasploit (Free or $$)

Scanning and regression testing in CI environments

Chef + Metaspolit + Jenkins

Security regression testing in your CI environment
github.com/rapid7/Chef-Metasploit

Testing environment

Seriously

  • Do not do it in production. It's a shortcut, but you will break things
  • But must accuratley represent your production environment in all ways

Thanks

@Joe8Bit | github.com/Joe8Bit