Wstg: Add Testing for JSON Web Token (JWT)

[kousha1999]

There are some types of attacks in JWT. I think it is nice to add a test case scenario for that.

[ThunderSon]

Yes, definitely. I think this fits in sessions chapter. It was to be implemented as new additions were coming to APIs.

@kingthorin @scalzava do you agree on the location of this? What are your thoughts on it?

Note: This will impact #370 and allow that test to link to the JWT test scenario.

[scalzava]

Yeah, it should definitely belong to the session management chapter. That would be a great addition to the guide, which I look forward to read! Yet, the right presentation is far from obvious IMHO.

We should be careful on the definition of JWT security. If JWTs are stored in cookies, they largely inherit the same weaknesses of traditional cookie-based sessions. The concern is really providing suggestions on how to craft these JWTs correctly. But if JWTs are saved in web storage, the threat model changes considerably: for example, CSRF is not a concern anymore and one (obviously) cannot rely on standard cookie defenses like HttpOnly and Secure. To sum up:

1. JWTs have inherent subtleties related to their creation, e.g., appropriate content and right use of cryptography. This should be discussed somewhere in the guide. It is something which I never investigated much and a bit outside of my area of expertise, but I'd love to learn more about these issues. @kousha1999 were you referring to this?
2. Authentication credentials saved in local storage (most often JWTs, but not necessarily!) have different security properties with respect to cookies, hence deserve a separate treatment in the session management chapter. Shameless self promotion, but really for the sake of discussion: we have a research paper which touches on this topic. We also discuss how cookies and web storage can be combined in a single authentication scheme which offers greater security, which would be a nice addition to the guide. You can find the paper here.

Incidentally, Section 3.1 (Misconceptions) of the paper formalizes my prior point on this discussion in nice academic writing. All things considered, we probably need two separate sections for 1 and 2 above, since the concerns are different. What do you think, @ThunderSon?

[ThunderSon]

I agree with both points. When I say let's discuss JWT, it means the weaknesses in that implementation, so point number 1.

For point number 2, the closest I found in the guide was CLNT-12, but it doesn't discuss in details the differences for sessions.

No worries about self plugs, at least we know they're good content :)

Does this feel like a section dedicated for JWT would be good, or should we handle them as "session tokens" and discuss different types (opaque tokens would be another one)?

@rbsec what do you think about this?

[kingthorin]

Let’s not confuse JWT with session tokens, there are lots of arguments against using them as such. (Though I’m happy to be proven wrong.)

Just search something like “ jwt are not session tokens”.

Given the number and variety of attacks/weaknesses I’d almost be happy with a separate section. Although maybe we are better with deeper split sections like SQLi?

[rbsec]

My thoughts would be that there are a lot of JWT specific issues that need to be tested for, such as:

• Is the signature actually verified?
• Can you use the none (or NoNe signature algorithm)?
• Is the HMAC using a weak key?
• Can you mix up the RSA and HMAC methods?
• Can you use a publicly available key to encrypt with RSA?
• etc

I think that these could easily justify a section of the guide - and these issues aren't really specific to how the JWT is stored.

In terms of the issues related to using local/session storage for tokens, is there anything specific that isn't already covered in guide linked to by @ThunderSon? If so, it probably wants adding there, rather than to a JWT page.

In terms of arguments about whether you should use JWTs or the merits of browser storage vs cookies, that seems like it would be outside of the scope of a project like this? I wouldn't consider any of them to be fundamentally broken to the point that a pentester should be recommending "Do not use JWTs" or "Do not use browser storage" - so as long as we have a methodology to test the security of all of them then I think a discussion of their merits is better left to other projects.

[kingthorin]

so as long as we have a methodology to test the security of all of them then I think a discussion of their merits is better left to other projects.

I agree, whole heartedly.

[scalzava]

So, if I get the discussion correctly, it seems that:

1. We agree that JWTs require a dedicated section in the guide, in particular focused on best crypto practices.
2. We might consider extending the "Testing browser storage" section to include additional information on using web storage for sessions

Is this an appropriate summary? Also, I agree with the final statement of @rbsec: we don't want to start a cookie vs storage fight. However, the choice of the storage does have security implications. This impacts security testing strategies and should be taken into account in the threat modeling phase. I'm unsure we should consider this as out of scope, but I trust @kingthorin and @ThunderSon as chief editors on this.

[rbsec]

@scalzava do you think there's anything significant that you feel is missing from the existing browser storage testing guide that should be added? If so, it's probably worth opening a separate issue/PR for that - so this issue doesn't get too mixed up with not-JWT stuff.

[scalzava]

I'd say the "browser storage testing guide" is not really a testing guide :) Of course, no offense meant to anyone - it just sounds more like a general introduction to client-side storage. I think it can be improved, though I would need to reason about it more formally. I do agree that we should reserve this issue to JWTs alone and open a new issue for authentication credentials in web storage if we feel the need (not sure it's a top priority right now).

[kousha1999]

As JWT Website said: JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. Also it can be use for authentication and authorization and even mostly in API for authentication. So it is hard to tell exactly which chapter is better for this. I'm agreed that it should be separated in different parts like SQL Injection.

[ThunderSon]

I think my comment made things go into various directions. Let me go into more details.

1. The linked test guide was created in a way to help the tester to look into client-side storage. It didn't go into the pros and cons of each one. It mainly goes on to say "Look into these storage types, what can you find, and are they sharing any sensitive data?". I was the main revamper of that test section, it was something different previously. If it can be improved, let's work on that.
2. What I discussed is the token type, which can be a JWT, an opaque value, etc. There are numerous types, not gonna go grab all possible examples for the sake of the discussion.
3. Where a session is stored is definitely a different discussion, it is not what I am aiming for from this issue.
4. Where a session is stored _should_ be part of the WSTG. We are not allowed to say what is good and what is bad of course, we will be saying what each technology benefits the developer and how they can be exploited. I wrote about those things in a blog post a year or two ago. If a token is stored in session storage, what are the issues behind it? What comes out of it? How can they secure it? etc. Let's have another issue on this and discuss why it might or might not be something that the WSTG cares about.

One thing is that we're all in agreement about JWT testing. The bad implementations, how it can be messed up, etc.

JWT can be part of AuthN, AuthZ, APIs, and Sessions. Once the test scenario is written, it can be referenced in other sections. But, this is just "modeling". Let's see where it fits later while work is happening on it.

I suggest that work starts happening, and we'll see how we can make it grow. I don't mind starting with one document, and then see if it should be split up. Again, this is something similar to "Testing JWT Implementations", and not their storage techniques in the browser. Mainly relying on rbsec's comment.

If we're in agreement on the final suggestion, @kousha1999 would you like to work on this?

[rbsec]

Worth noting that there's already some (fairly high level) JWT testing guidance, but it's not in the main document:

https://github.com/OWASP/wstg/blob/master/Testing_for_APIs.md#specific-testing--token-based-authentication

[kousha1999]

@ThunderSon I would love to but I'm not fluent in English, So it is so hard for me to write something like that by myself, thus I need so much help. I think it is better to someone work on it and I'll help him.

[DotDotSlashRepo]

@ThunderSon @kousha1999 I can help with this issue. I am fairly new in terms of contributions but I think I can manage this section.