Web security 101 Emily Stark, Meteor core dev Web security 101
Emily Stark at Hack Reactor - JavaScript and Web Security
Sep 01, 2014
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
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
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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...
< > ' " ` &
< > ' " ` &
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.
@estark37
security-resources.meteor.com
Related Documents
