Security in the client

New APIs, attacks, mitigation and testing

Friday 9th of May 2014 | Joe Pettersson @ ScotlandJS | joe8bit.github.io/browser-security-talk

Joe Pettersson

@Joe8Bit | github.com/Joe8Bit

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

Strong decoupling

Example

A client side HTTP interface shouldn't inherently trust output from a service it's utilising

Exploited

Generic stored/reflected XSS attacks

An open-redirect was exploited to leverage information leakage via a same-origin include

Learn from decades of network security models and enforce multi-tiered trust boundries

Issue

Thick clients/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 front-end 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

This is a constantly changing landscape

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. Avoid host multiple applications on the same origin that utilise localStorage
• Watch out for cache poisoning when caching assets to localStorage
• SQL injection in WebSQL

Multithreading API's

WebWorkers

• It's trivially easy to perform DOS attacks that exploit resource heavy CPU opertions (e.g. recursive Fibonacci factoring) in WebWorkers, in some 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 is possible. Use HTTPS.
• ServiceWorkers? A potential solution

Machine access API's

WebGL

• A whole new world of attacks targetting insecure GPU drivers form the web
• User mode > Kernel mode
• Chromium/Angle - interesting approach to validating machine instructions
• DOS attacks are trivial and brick the entire environment

An attacked WebGL call stack

Testing

Auditing*

* not an auditing crash course

Auditing: Goals (Strategy)

• Where are your integration points?
• What is the breadth and depth of your attack surface?
• Where are your 'trust' boundries?
• What are the fundmental 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

You're blind to your own blindness

Penetration Testing

White box vs Blackbox

Penetration test vs Vulnerability scan

Tools

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

Vulnerability scanning in CI environments

Chef + Metaspolit + Jenkins

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

Penetration tests

Are always manual

Leverage professional experience

Have unique methodologies

Yield specialised reports

"Amateurs Have Automated Tools; Professionals Have People"

Testing environment

Do not do it in production. It's a shortcut, but a good pen tester will break things

Must accuratley represent your production environment in all ways (code, hardware et al)

Must run with accurate data. Having nothing but Lorem Ipsum's will bite you in the ass. Use production replicas and NDA's

Lifecycle of a pen test

Other considerations

Internal vs. External

• Does the capability exist to pen test? To properly vulnerability scan?
• This is a very specific skill set. Get the best people. They usually aren't internal

Pen testing is synchronous

Thanks

@Joe8Bit | github.com/Joe8Bit