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

1. Web security 101
Emily Stark, Meteor core dev
Web security 101

2. Common attacks on the web, how to
prevent them, and tidbits from Meteor
along the way

3. Outline
1. 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)

4. Why the web is a
dangerous place

5. Same Origin Policy
protocol, host, port

6. Why the web is a
dangerous place
drive-by code execution

7. Why the web is a
dangerous place
drive-by code execution
client server
request

8. Why the web is a
dangerous place
drive-by code execution
client server
request
response

9. Why the web is a
dangerous place
drive-by code execution
client server
request
response
execute as
code

10. Why the web is a
dangerous place
stateless
client serverrequest
response
request
response

11. Why the web is a
dangerous place

12. Why the web is a
dangerous place
meteor uses a stateful
protocol
client meteor
server
request
response
DDP over websockets

13. Why the web is a
dangerous place
code + data intermingled
client serverrequest
response
request
response

14. Why the web is a
dangerous place
meteor: code and data
separate
client meteor
server
request
response (code)
DDP over websockets (data)

15. Authentication and
password storage

16. Auth flow
client serverusername, password
session cookie
request
response

17. Auth flow
client serverusername, password
session cookie
request
response

18. Auth flow
client server
username, password
H(password)

19. Password storage
What is H?

20. Password storage
How many MD5, SHA1 guesses per
second?

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

22. 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/

23. Password storage
● bcrypt, scrypt
○ password hashes
○ slow, scalable
● General-purpose hashes
(SHA, MD5) designed to
be fast

24. Password storage
● bcrypt, scrypt
○ password hashes
○ slow, scalable
● General-purpose hashes
(SHA, MD5) designed to
be fast

25. Auth flow
client server
username, password
session cookie

26. Auth flow
● random,
unguessable
● httponly
● secure

27. Meteor authentication
client
meteor
server
DDP over websockets
login
token
(authenticated)
store in
localStorage

28. CSRF
victimbank.com server
victimbank.com
login

29. CSRF
victimbank.com server
victimbank.com
login
evil.com
transfer $100
million billion to
evil.com

30. No CSRF in meteor apps
● No cookies.
○ Only your app can make
authenticated requests to itself.
● Cost: httponly, secure cookie
protections.

31. Crypto diversion: SRP
● Server can’t learn client password.
● Server and client authenticate each other.
● Resistant to man-in-the-middle attacks.

32. 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)

33. 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.

34. Auth takeaways
● Use a framework’s implementation.
● Use bcrypt.
● Use httponly and secure cookie flags.
● Cookies can be avoided when connections
are stateful.

35. Cross-site scripting

36. Cross-site scripting (XSS)

37. Cross-site scripting (XSS)

38. HTML encoding foils some
attacks...
< > ' " ` &
&lt; &gt; &#x27; &quot; &#x60; &amp;

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

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

41. URL sanitization
<a href="javascript:alert(localStorage)">
{{ username }}'s website
</a>
Can you execute any damaging Javascript
when quotes are escaped?

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

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

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

45. 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 Policy
Ex: Content-Security-Policy: default-src
'self'

46. Meteor to the rescue?
Automatic, contextual sanitization*
*in the future, maybe

47. Conclusion
● The web is a dangerous place.
● Full-stack frameworks, stateful
connections: new security territory.

48. Questions?
emily@meteor.com
@estark37
security-resources.meteor.com