9

I was just reading through the "Token sidejacking" of the JWT Cheat Sheet of OWASP (https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet_for_Java.html#token-sidejacking)

At the moment I don't understand how the recommended prevention actually solves the issue.

The solution is to add a context and send this context (e.g. a random value) as a Cookie as well as part of the JWT (then hashed).

However if an attacker is able to steal the JWT by performing a XSS attack and access the sessionStorage, the attacker can also send XHR-requests, so the Cookie is automatically send with it. If the attacker is able to sniff the network traffic, the attacker also has the Cookie value. The only case I can think of where this works is, if the attacker has access to some sort of logs, where the JWT is stored, but this would be another vulnerability (or more).

What did I miss? Thanks

Chris
  • 91
  • 2

3 Answers3

4

if an attacker is able to steal the JWT by performing a XSS attack and access the sessionStorage, the attacker can also send XHR-requests, so the Cookie is automatically send with it

The solution uses SameSite cookies. They won't be sent to the attacker's server.

Greendrake
  • 669
  • 1
  • 8
  • 17
  • Greendrake: And what about IE11 which supports SameSite only partialy. What happens if browser doesn't support SameSite cookie? I guess, the browser sends it as normal cookie? This is what I still don't understand - like @Chris maybee. Thanks for your comment. – Patrik Novotný Jan 06 '20 at 16:07
  • @PatrikNovotný Modern secure browsers will be expected to _only_ send cookies to other sites when `SameSite` is explicitly set to `None`. Browsers not aware of `SameSite` will be considered no longer secure. – Greendrake Jan 19 '20 at 07:14
2

If the attacker is able to sniff the network traffic, the attacker also has the Cookie value.

You are describing an attack where the attacker sniffs your network traffic, and then uses when they find to impersonate you.

Most security analysts consider TLS (ie HTTPS) to be a sufficient protection against this; traffic is encrypted from your browser all the way to the web server that you're talking to (in theory your request could bounce around and be logged in plaintext within the site's backend infrastructure, but that requires getting into the site's backend network)

I have to agree with you that I'm also struggling to come up with a scenario where that advice actually does anything.

If the the attacker can intercept your JWT, then you'd think they can also get the cookie.

If they can inject malicious javascript into the page and read your browser's localstorage, then you'd think they can also send GETs / POSTs and have the cookie attached automatically.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
0

In the OWASP's implementation example, they store the user context in a Secure, HttpOnly, Samesite cookie. This helps to prevent attacker from using XSS to read this Cookie value.

quangh
  • 101