Introduction

• I'm Mark Goodwin

• I work for Mozilla

• I work on web security and some products (e.g. Firefox)

Overview

This talk is not about Browser security...

(though I'll talk about some browser features)

... it is about developers and how we can help them

(and a little bit about what I'm doing at Mozilla too)

We Have a Problem

The web is growing (fast)

Active domains: 313 to 677 million in year to April 2012 (Netcraft)

New sites, new developers

Many of these aren't well trained in security

There is a legacy of broken stuff

Many active sites are infrequently maintained

Developers, Developers, etc.

BSIMM - 2% of devs should be security pros

• A nice ideal, works well for larger orgs / fewer technologies
• Feels a stretch for smaller / more varied environments

Life is easier for all if the rest improve

Relying on Frameworks

Adoption takes time

e.g. PHP

• PDO shipped with PHP 5.1 (2005) - it's rare to see it in PHP code
• $wpdb->prepare shipped with WordPress 2.5 (2005) - it's rare to see it in WP extensions

Relying on Frameworks (2)

Relying on Frameworks (3)

Source: langpop.com

Relying on Libraries

• OWASP ESAPI, etc.

  Provide tools when a framework doesn't deliver

• Again, portability is an issue

  • Even if you use the same language... (e.g. Python, WSGI and Tornado)
  • Reinventing the wheel... again... and again...

Relying on Tools / Services

• These are beyond the reach of many developers.

• 'Developer focused' security tools (e.g. ZAP)

  popular among pentesters, less so with devs

What about the Browser?

Less diverse, easier to learn

There are many, many server technologies - fewer browsers

Implementation knowlege is transferrable

I can say 'set this header' to Django / Java / .NET devs - they'll all know what I mean

can only help with a subset of issues

any help is welcome, right?

Vulnerability: XSS

• A well known attack

  occurs when an attacker is able to inject malicious script into a victim's browser in the context of a target site.

• Comes in 3 main varieties (plus self-xss)

  • Reflected
  • Stored
  • DOM - for example:
    Click me!

In Browser: XSS Filter

• Excellent browser support

  IE, Chrome (60-72% of users) - also on the Firefox roadmap

• Prevents reflected XSS

• Enabled by default

  Can be controlled with a header:

  X-XSS-Protection: 1; mode=block

In Browser: CSP

• Primarily to prevent XSS

  also useful in other scenarios

• Quite well supported

  Chrome and Firefox have support (38-55% of users)

• Can be tricky to implement

  though excellent documentation is available

In Browser: CSP (2)

is enabled by setting a header

X-Content-Security-Policy: default-src 'self'; img-src *; script-src 'self' *.example.com

has a report-only mode

X-Content-Security-Policy-Report-Only: default-src 'self'; img-src *; script-src 'self' *.example.com; report-uri /csp/report
			

Clickjacking, etc.

• Clickjacking / UI Redressing

  Attackers 'hide' the target site and fool the user into clicking or typing

• Other attacks (e.g. XFS)

  IE prior to IE8 - framing document could steal keypresses intended for framed

In Browser: X-Frame-Options

• It's been around since IE8

  Supported in current version of all major browsers (95% of users)

• Prevents a site from being framed

  (mostly to prevent clickjacking)

• Simple to implement (response header)

  x-frame-options: DENY

Attacks: MITM

• Many sites do little to protect their users

  Makes use of untrusted networks, untrusted proxies (TOR?) dangerous

• Many potential causes

  • Mixed content
  • Cookies without 'secure' attribute
  • Dropping HTTPS post-auth (remember FireSheep?)

In Browser: STS

• Is intended to make MITM attacks harder

• STS is set with a response header

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

  Once set, a browser knows only to visit that site via HTTPS

• STS has some privacy issues.

Vulnerability: CSRF

• CSRF: Cross Site Request Forgery

• A common, serious vulnerability

  occurs when an attacker is able to use a victim's browser to forge requests to a target site

• Let's have a demo

Soon: SameDomain Cookies

• An idea I'm working on at Mozilla

  intended as a simple, reliable fix for CSRF

• It's a simple cookie attribute

  simple for most cases, completely opt in

• Intended to complement existing mitigation

• Let's have a demo

So who uses this stuff?

• Adoption takes time

  Some of these features are harder to implement than others

• There's a whole lot of web out there

  Existing sites have a huge investment in current systems

• Everyone will be making an effort...

  ...surely? Actually, no.

Header survey

Why?

• Lazy / Uninterested?

  (probably not)

• Unaware?

  (more likely)

• Busy / Preoccupied?

  (almost certainly)

Why?

• This stuff takes time to learn...

Developer Tools

• Developers live in their developer tools

  Good tools can expose things in interesting ways

Firefox Devtools

• CSP / Mixed Content Warnings (demo)

• User Specified CSP (demo)

  Read more here.

• More to follow...

  (passive tests only)

• Your Idea?

Summary

Developer awareness is a good thing

• Many developers don't have access to training or dedicated security resources
• Many developers don't have the time or opportunity to learn about security
• Exposing Security information in the tools they already use may help

Thanks!

Questions?

Contact:

• @mr_goodwin (twitter)
• mgoodwin (irc.mozilla.org)