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

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 environment
github.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

Establish goal(s)
Reconnaissance
Discovery
Exploitation
Brute forcing
Social engineering
Taking control
Pivoting
Evidence collection
Reporting
Remediation

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

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

This is a constantly changing landscape

Communication API's

Web Messaging / Cross Domain Messaging

Validating FQDN's

Storage API's

Storing data in the client

Multithreading API's

WebWorkers

Misc. API's

iFrame's

Misc API's

Offline applications

Machine access API's

WebGL

An attacked WebGL call stack

Testing

Auditing*

* not an auditing crash course

Auditing: Goals (Strategy)

Auditing is asynchronous

You're blind to your own blindness

Penetration Testing

White box vs Blackbox

Penetration test vs Vulnerability scan

Tools

Vulnerability scanning in CI environments

Chef + Metaspolit + Jenkins

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

Pen testing is synchronous

Thanks

@Joe8Bit | github.com/Joe8Bit