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

Why?

We don't think about security enough

The fundamental problem

The 'Client' Environment

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

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

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

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 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

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 environmentgithub.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