Handling Authentication Secrets in the Browser

This talk was given at Fluent 2017 on June 21st, 2017.

In the new world of JavaScript UIs, REST APIs, and microservices, applications that run in the highly insecure browser environment must handle tokens and other secrets to have access to backend services. Drawing on his experience at Rackspace, Miguel Grinberg discusses the risks and shares best practices to avoid them.

Transcript

1. Handling Authentication Secrets in the Browser Miguel Grinberg
2. About Me • Software Dev @ Rackspace • Author of O’Reilly’s book “Flask Web Development” • APIs, Microservices, Socket.IO • Python, JavaScript, C++ • @miguelgrinberg • blog.miguelgrinberg.com • github.com/miguelgrinberg
3. The Basics
4. The Web is Stateless • HTTP servers cannot “remember” clients from one request to the next • Clients must provide some form of identification with every single request • The concept of logging in and out is a high-level abstraction
5. Authentication with Username and Password • The client gets credentials from the user and sends them with the request • Most apps exchange username/password for a token or authentication cookie
6. Authentication with a Token • The client obtains a token, then includes it in all requests as a header • The token represents a user session • Popular choice for rich-client web applications
7. Authentication Cookies • The server sets a cookie with the client after successful authentication • The browser sends the cookie back to the server in subsequent requests • The cookie references a user session • Traditional approach for thin-client web applications
8. Passwords vs Tokens • Passwords ◦ Are created by humans ◦ Generally give full access to the user’s account ◦ Generally do not expire or have a long expirations • Tokens ◦ Are generated by servers ◦ Can have a scope associated with them ◦ Generally have a relatively short expiration • Cookies ◦ A storage mechanism, so nothing like passwords or tokens ◦ Convenient to use for authentication, because the browser sends them by itself ◦ An authentication cookie normally stores a token
9. User Sessions • Servers remember clients by creating “user sessions” for them • A user session is a protected storage where the server stores user information • Server-side user sessions are stored in databases or disk files ◦ The server returns a reference to the session as a token, possibly in a cookie • Client-side user sessions are returned to the client in a token or cookie ◦ The contents of the session are cryptographically signed to prevent tampering ◦ JSON Web Tokens is a popular standard for creating this type of session
10. Basic Protection Of Secrets
11. Use HTTPS (aka HTTP over TLS) • This encrypts all traffic between the client and the server, with a key only known to these two parties • User credentials cannot be intercepted while in transit, as long as all authentication cookies have the secure flag set • Man in the middle attacks become much more difficult to pull off • You can get free SSL certificates!
12. Harden the Server • Strong passwords for all accounts, or disable password logins altogether • No root logins • Only expose necessary services on the public network ◦ Your web and SSH servers will obviously need to be accessible ◦ Databases, session stores, etc. can usually listen only on localhost or a private network ◦ Add a firewall or set security group rules on your host(s) • Application crashes should not expose internal information to the client • Routinely install security updates
13. Browser Attacks
14. Cross-Site Scripting Attacks (XSS) • An attacker injects random JavaScript code in posts or comments on your site • When the victim views the affected page the attacker’s code executes • The rogue script can upload cookies, local storage, DOM contents, etc. to an attacker controlled server
15. Mitigating XSS Attacks • Treat all input received from clients as unsafe and needing sanitizing • Use authentication cookies with the httpOnly flag set, so that they are not accessible to JavaScript • Use tokens with short expiration time
16. XSS Attacks and Access Tokens • With a compromised access token, an attacker can impersonate the user on the identity provider’s site • Mitigation ◦ Never expose shared secrets to a web browser application ◦ Use a proxy endpoint in your server as intermediary ◦ If you need to sign requests, let the server create “pre-signed” URLs
17. Cross-Site Request Forgery (CSRF) • An attacker-controlled site issues requests to your server on behalf of the user • When the user visits the malicious site, requests to your API go out with valid authentication cookies stored by the browser in a previous session
18. Mitigating CSRF Attacks • Check that the Origin and/or Referer HTTP headers have the expected value ◦ These headers cannot be set from JavaScript in modern browsers • Add a “synchronizer” token to all web forms and XHR requests • Use a JWT or similarly signed token for authentication ◦ Do not store it in a cookie!
19. Dealing with Compromised Credentials
20. There Is No 100% Foolproof Security • All systems are subject to attacks or leaks • We developers are human and make mistakes • Users are also human, and tend to be careless ◦ They tweet out their passwords by mistake! ◦ They use the same password on many sites, so they can be compromised elsewhere ◦ They install dubious browser extensions that are spyware ◦ They access your site from a compromised computer
21. Responding to a Leak or Attack • You should have a plan in place, so that attacks are handled swiftly • If a token is compromised, revoke it immediately ◦ You should have an easy way to revoke tokens, don’t edit your database by hand! • If a user reports suspicious activity on their account, reset the account ◦ Revoke all active tokens for the user ◦ Ensure that user information hasn’t been altered as part of the attack ◦ Force the user to reset their password on the next login • If you think your server was compromised, use the “nuclear option” ◦ Revoke your current SSL certificate and request a new one ◦ Force all users to set a new password on their next login ◦ Change your token signing key (this will effectively revoke all active tokens for all users) • Make sure you have automated tests in place for all the above measures!
22. Summary
23. Summary • Use secure HTTP and harden your server • Routinely audit your application to detect code injection vulnerabilities • If XSS attacks are possible or if you are not sure ◦ Store authentication credentials in a httpOnly and secure cookie (XSS protection) ◦ Validate the Origin and Referer headers (base level CSRF protection) ◦ Add a CSRF token to all web forms and ajax requests (strong CSRF protection) • If XSS attacks are not possible (users cannot post content that others can see) ◦ Do not store credentials in a cookie. Pass auth tokens in a header (CSRF protection) • Do not use signing keys, access tokens or other secrets in the browser • If you use JWTs, validate the signing algorithm • Know that you are still vulnerable, and have a mitigation plan in place!
24. Thank You! @miguelgrinberg Slides: bit.ly/auth-secrets Blog post: bit.ly/auth-secrets-blog