Attack Prevention for JWT Authentication with Single-Page Application

Secure Cookies

Man-In-the-Middle (MITM)

• Use HTTPS/TLS everywhere a cookie will be in transit
  • Set Secure flag on cookies – will prevent cookies from being transmitted in non-secure network

Cross-Site Request Forgery (CSRF)

Attacker can create a page on some host which has some JavaScript code that invokes our token generation URL and gets a JWT token. If you happened to have gotten to my page after you had logged in (which with SSO, it’s more and more likely that you have), then that JavaScript code can get a JWT token and invoke REST services on your behalf.

Another scenario could be that an attacker creates a page with malicious image, for example, <img src=”https://trustyapp.com/transferMoney?to=BadGuy&amount=10000″>. In this case, browser will send cookies for trustyapp.com, and server trusts cookies and assume this was an intended user action.

This is because that HTML tags do not follow the Same-Origin-Policy when making GET requests.

• Synchronizer Token – for form-based web app
• Double-Submit Cookie – for modern apps, like SPA
  • Use two cookies
    • One authentication cookie, like Session ID or JWT token
    • One strong random value, let’s call it csrf-token
  • Client needs to send back the csrf-token cookie in a custom HTTP header, triggering the Same-Origin-Policy
  • Server needs to verify that the custom HTTP header for the csrf-token has the correct value
  • Server needs to have correct Cross-Origin Resource Sharing policy to only receive requests from trusted origin, preferably only from the same host
    • So that we can ensure that the forged page cannot send requests to the server

Cross-Site Scripting (XSS)

• Escape content
  • Escape user input from forms so that user will not be able to inject html/javascript code to the page
• Handling customization with caution
• Set HttpOnly flag on authentication cookies
  • HttpOnly cookies are NOT accessible by JavaScript. These cookies will only be automatically attached to the request header by the browser

Adopt JWT the Right Way

Use the claims body wisely

• Include role information in “scope” part to handle client side UI authorization locally

Use OAuth2 + JWT

• Access & Refresh Tokens
  • Access token expires before refresh token
  • Access token is stateless, trusted by signature, used for client-server communication
  • Refresh token is stateful, can be revoked, used to get more access token
• For example
  • Super-secure banking application (want to force user out often)
    • Access token TTL – 1 min
    • Refresh token TTL – 30 mins
  • Mobile/social app (user should always stay logged in)
    • Access token TTL – 1 hour
    • Refresh token TTL – 1 year

Storing & Transmitting JWTs – in the browser

• Local storage is XSS vulnerable
• Cookies with HttpOnly and Secure flags, and other CSRF prevention, are secure
  • However this will prevent us from being able to inject the token as HTTP request header
  • Will need to pass the token as part of the cookie
    • Existing framework might not support that (OWSM multi_token_rest_service_policy)
• Avoid cross-domain requests where possible

References

JWT Authentication with AngularJS – https://www.youtube.com/watch?v=mecILj3p4VA