emily stark at hack reactor - javascript and web security

Post on 01-Sep-2014

1.345 Views

Category:

Technology

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

Emily Stark is a core developer at Meteor Development Group and an expert in JavaScript security and cryptography (see her bio at http://www.meteor.com/about/people). On September 12, 2013, Emily gave a guest lecture at Hack Reactor, a San Francisco-based coding academy (http://hackreactor.com). She covered several topics in JavaScript and Web Security, including: • Secure password storage and authentication • SRP protocol (http://srp.stanford.edu) • Common JS security threats and injection techniques

TRANSCRIPT

Web security 101Emily Stark, Meteor core dev

Web security 101

Common attacks on the web, how to prevent them, and tidbits from Meteor

along the way

Outline1. Why the web is a dangerous place

2. Web security in the traditional world and the meteor world:- Authentication and password storage - cross-site request forgery (CSRF)

- SRP- Cross-site scripting (XSS)

Why the web is a dangerous place

Same Origin Policy

protocol, host, port

Why the web is a dangerous place

drive-by code execution

Why the web is a dangerous place

drive-by code execution

client serverrequest

Why the web is a dangerous place

drive-by code execution

client serverrequest

response

Why the web is a dangerous place

drive-by code execution

client serverrequest

response

execute as code

Why the web is a dangerous place

stateless

client serverrequest

response

request

response

Why the web is a dangerous place

Why the web is a dangerous place

meteor uses a stateful protocol

client meteorserver

request

response

DDP over websockets

Why the web is a dangerous place

code + data intermingled

client serverrequest

response

request

response

Why the web is a dangerous place

meteor: code and data separate

client meteorserver

request

response (code)

DDP over websockets (data)

Authentication and password storage

Auth flow

client serverusername, password

session cookie

request

response

Auth flow

client serverusername, password

session cookie

request

response

Auth flow

client server

username, passwordH(password)

Password storage

What is H?

Password storage

How many MD5, SHA1 guesses per second?

Password storage

> 60 billion

http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to-348-billion-per-second-7000008368/

Password storage

> 60 billion

(<1 min to crack a 7 character alphanumeric password)

http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to-348-billion-per-second-7000008368/

Password storage● bcrypt, scrypt

○ password hashes○ slow, scalable

● General-purpose hashes (SHA, MD5) designed to be fast

Password storage● bcrypt, scrypt

○ password hashes○ slow, scalable

● General-purpose hashes (SHA, MD5) designed to be fast

Auth flow

client server

username, password

session cookie

Auth flow

● random, unguessable

● httponly

● secure

Meteor authentication

client meteorserver

DDP over websockets

login

token

(authenticated)store in

localStorage

CSRF

victimbank.com server

victimbank.comlogin

CSRF

victimbank.com server

victimbank.comlogin

evil.com

transfer $100 million billion to evil.com

No CSRF in meteor apps● No cookies.

○ Only your app can make authenticated requests to itself.

● Cost: httponly, secure cookie protections.

Crypto diversion: SRP

● Server can’t learn client password.

● Server and client authenticate each other.

● Resistant to man-in-the-middle attacks.

Crypto diversion: SRP in one cramped slide

client server

username, random value r1

salt, g^H(salt, password)

salt, another random value r2

use password to compute shared key

use g^H(salt, password) to compute

shared key

password

H(shared key || r1 || r2)

H(message from client || shared key)

Crypto diversion: SRP

Why don’t all web apps use it?

● Client-side crypto is almost always useless.

● Meteor uses it in anticipation of non-browser DDP clients.

Auth takeaways● Use a framework’s implementation.

● Use bcrypt.

● Use httponly and secure cookie flags.

● Cookies can be avoided when connections are stateful.

Cross-site scripting

Cross-site scripting (XSS)

Cross-site scripting (XSS)

HTML encoding foils some attacks...

< > ' " ` &

&lt; &gt; &#x27; &quot; &#x60; &amp;

But not all<a href="{{ userWebsite }}"> {{ username }}'s website</a>

URL sanitization<a href="javascript:alert(localStorage)"> {{ username }}'s website</a>

URL sanitization<a href="javascript:alert(localStorage)"> {{ username }}'s website</a>

Can you execute any damaging Javascript when quotes are escaped?

URL sanitization<a href="javascript:eval(String.fromCharCode(77, 101, ...))"> {{ username }}'s website</a>

CSS sanitization<div style="background-color:{{ usersFavoriteColor }}"></div>

<div style="background-color:expression(alert(localStorage))"></div>

CSS sanitization

Sanitize untrusted URLs and CSS○ Don't try to filter out "javascript:",

"expression", etc.

○ Do strict checking: urls start with http, css values come from a list of safe values

○ Use Content Security PolicyEx: Content-Security-Policy: default-src 'self'

Meteor to the rescue?

Automatic, contextual sanitization*

*in the future, maybe

Conclusion● The web is a dangerous place.

● Full-stack frameworks, stateful connections: new security territory.

Questions?emily@meteor.com

@estark37

security-resources.meteor.com

top related