711649924b
* 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>
46 lines
1.7 KiB
Plaintext
46 lines
1.7 KiB
Plaintext
=== Solution
|
|
|
|
In the past assignments we learned to **NOT** trust the libraries to do the correct thing for us. In both cases we saw that even specifying the JWT key and passing the correct algorithm. Even using the token:
|
|
|
|
[source]
|
|
----
|
|
eyJhbGciOiJIUzI1NiJ9.ew0KICAiYWRtaW4iIDogdHJ1ZSwNCiAgImlhdCIgOiAxNTE2MjM5MDIyLA0KICAic3ViIiA6ICIxMjM0NTY3ODkwIiwNCiAgInVzZXIiIDogIkpvaG4gRG9lIg0KfQ.
|
|
|
|
{
|
|
"alg" : "HS256"
|
|
},
|
|
{
|
|
"admin" : true,
|
|
"iat" : 1516239022,
|
|
"sub" : "1234567890",
|
|
"user" : "John Doe"
|
|
}
|
|
----
|
|
|
|
And the following Java code:
|
|
|
|
[source]
|
|
----
|
|
Jwt jwt = Jwts.parser().setSigningKey(JWT_PASSWORD).parse(accessToken);
|
|
----
|
|
|
|
You see we set the signing key with `setSigningKey` the library still skips the validation of the signature.
|
|
|
|
It is not only limited to the traditional `alg: none` attack, but it also works with the `alg: HS256`.
|
|
|
|
=== Conclusion
|
|
|
|
When you have chosen a library to help dealing with JWT tokens make sure to:
|
|
|
|
- use the correct method in your code when validating tokens.
|
|
- add test cases and validate the algorithm confusion is not possible.
|
|
- as a security team write a utility methods to be used by the teams which encapsulate the library to make sure the teams use the correct parsing logic.
|
|
|
|
=== Alternative: Paseto
|
|
|
|
The algorithm confusion is a real problem when dealing with JWTs it can be avoided by using PASETO (**P**latform-**A**gnostic **SE**curity **TO**kens), which is currently implemented in 10 programming languages.
|
|
One of the drawbacks of using this method is that JWT is widely spread for example think about using OAuth, so it might not be the best solution to use.
|
|
|
|
For more information take a look at the following video:
|
|
|
|
video::RijGNytjbOI[youtube, height=480, width=100%] |