Emily Stark at Hack Reactor - JavaScript and Web Security

4,081 views

Published on

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

Published in: Technology
1 Comment
4 Likes
Statistics
Notes
  • Free Download : http://gg.gg/114bb
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,081
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
31
Comments
1
Likes
4
Embeds 0
No embeds

No notes for slide

Emily Stark at Hack Reactor - JavaScript and Web Security

  1. 1. Web security 101 Emily Stark, Meteor core dev Web security 101
  2. 2. Common attacks on the web, how to prevent them, and tidbits from Meteor along the way
  3. 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. 4. Why the web is a dangerous place
  5. 5. Same Origin Policy protocol, host, port
  6. 6. Why the web is a dangerous place drive-by code execution
  7. 7. Why the web is a dangerous place drive-by code execution client server request
  8. 8. Why the web is a dangerous place drive-by code execution client server request response
  9. 9. Why the web is a dangerous place drive-by code execution client server request response execute as code
  10. 10. Why the web is a dangerous place stateless client serverrequest response request response
  11. 11. Why the web is a dangerous place
  12. 12. Why the web is a dangerous place meteor uses a stateful protocol client meteor server request response DDP over websockets
  13. 13. Why the web is a dangerous place code + data intermingled client serverrequest response request response
  14. 14. Why the web is a dangerous place meteor: code and data separate client meteor server request response (code) DDP over websockets (data)
  15. 15. Authentication and password storage
  16. 16. Auth flow client serverusername, password session cookie request response
  17. 17. Auth flow client serverusername, password session cookie request response
  18. 18. Auth flow client server username, password H(password)
  19. 19. Password storage What is H?
  20. 20. Password storage How many MD5, SHA1 guesses per second?
  21. 21. Password storage > 60 billion http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to-348-billion-per-second-7000008368/
  22. 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. 23. Password storage ● bcrypt, scrypt ○ password hashes ○ slow, scalable ● General-purpose hashes (SHA, MD5) designed to be fast
  24. 24. Password storage ● bcrypt, scrypt ○ password hashes ○ slow, scalable ● General-purpose hashes (SHA, MD5) designed to be fast
  25. 25. Auth flow client server username, password session cookie
  26. 26. Auth flow ● random, unguessable ● httponly ● secure
  27. 27. Meteor authentication client meteor server DDP over websockets login token (authenticated) store in localStorage
  28. 28. CSRF victimbank.com server victimbank.com login
  29. 29. CSRF victimbank.com server victimbank.com login evil.com transfer $100 million billion to evil.com
  30. 30. No CSRF in meteor apps ● No cookies. ○ Only your app can make authenticated requests to itself. ● Cost: httponly, secure cookie protections.
  31. 31. Crypto diversion: SRP ● Server can’t learn client password. ● Server and client authenticate each other. ● Resistant to man-in-the-middle attacks.
  32. 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. 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. 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. 35. Cross-site scripting
  36. 36. Cross-site scripting (XSS)
  37. 37. Cross-site scripting (XSS)
  38. 38. HTML encoding foils some attacks... < > ' " ` & &lt; &gt; ' &quot; ` &amp;
  39. 39. But not all <a href="{{ userWebsite }}"> {{ username }}'s website </a>
  40. 40. URL sanitization <a href="javascript:alert(localStorage)"> {{ username }}'s website </a>
  41. 41. URL sanitization <a href="javascript:alert(localStorage)"> {{ username }}'s website </a> Can you execute any damaging Javascript when quotes are escaped?
  42. 42. URL sanitization <a href="javascript: eval(String.fromCharCode(77, 101, ...))"> {{ username }}'s website </a>
  43. 43. CSS sanitization <div style="background-color: {{ usersFavoriteColor }}"> </div>
  44. 44. <div style="background-color: expression(alert(localStorage))"> </div> CSS sanitization
  45. 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. 46. Meteor to the rescue? Automatic, contextual sanitization* *in the future, maybe
  47. 47. Conclusion ● The web is a dangerous place. ● Full-stack frameworks, stateful connections: new security territory.
  48. 48. Questions? emily@meteor.com @estark37 security-resources.meteor.com

×