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>

src/main/resources/lessons/jwt/documentation/JWT_decode.adoc

@@ -0,0 +1,12 @@
+== Decoding a JWT token
+
+Let's try decoding a JWT token, for this you can use the webWolfLink:JWT[target=jwt] functionality inside WebWolf.
+Given the following token:
+
+[source]
+----
+eyJhbGciOiJIUzI1NiJ9.ew0KICAiYXV0aG9yaXRpZXMiIDogWyAiUk9MRV9BRE1JTiIsICJST0xFX1VTRVIiIF0sDQogICJjbGllbnRfaWQiIDogIm15LWNsaWVudC13aXRoLXNlY3JldCIsDQogICJleHAiIDogMTYwNzA5OTYwOCwNCiAgImp0aSIgOiAiOWJjOTJhNDQtMGIxYS00YzVlLWJlNzAtZGE1MjA3NWI5YTg0IiwNCiAgInNjb3BlIiA6IFsgInJlYWQiLCAid3JpdGUiIF0sDQogICJ1c2VyX25hbWUiIDogInVzZXIiDQp9.9lYaULTuoIDJ86-zKDSntJQyHPpJ2mZAbnWRfel99iI
+----
+
+Copy and paste the following token and decode the token, can you find the user inside the token?
+

src/main/resources/lessons/jwt/documentation/JWT_final.adoc

@@ -0,0 +1,5 @@
+== Final challenge
+
+Below you see two accounts, one of Jerry and one of Tom. Jerry wants to remove Tom's account from Twitter, but his token
+can only delete his account. Can you try to help him and delete Toms account?
+

src/main/resources/lessons/jwt/documentation/JWT_libraries.adoc

@@ -0,0 +1,68 @@
+== JWT libraries
+
+There are a number of JWT libraries available in the Java ecosystem. Let's look at one of them:
+
+
+The contents of our token is:
+
+[source]
+----
+header:
+
+{
+  "alg": "HS256",
+  "typ": "JWT"
+}
+
+claims:
+
+{
+  "sub": "1234567890",
+  "name": "John Doe",
+  "iat": 1516239022
+}
+----
+
+[source]
+----
+var token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.NFvYpuwbF6YWbPyaNAGEPw9wbhiQSovvSrD89B8K7Ng";
+
+Jwts.parser().setSigningKey("test").parseClaimsJws(token);
+----
+
+will work!
+
+Let's change the header to `{"alg":"none","typ":"JWT"}`
+Using the same source as above gives:
+
+[source]
+----
+var token = " eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.NFvYpuwbF6YWbPyaNAGEPw9wbhiQSovvSrD89B8K7Ng";
+
+Jwts.parser().setSigningKey("test").parseClaimsJws(token);
+----
+
+will result in:
+
+[souce]
+----
+io.jsonwebtoken.MalformedJwtException: JWT string has a digest/signature, but the header does not reference a valid signature algorithm.
+----
+
+removing the signature completely (leaving the last `.`)
+
+[source]
+----
+var token = "eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.";
+
+Jwts.parser().setSigningKey("test").parseClaimsJws(token);
+----
+
+will result in:
+
+[source]
+----
+io.jsonwebtoken.UnsupportedJwtException: Unsigned Claims JWTs are not supported.
+----
+
+This is what you would expect from the library!

src/main/resources/lessons/jwt/documentation/JWT_libraries_assignment.adoc

@@ -0,0 +1,61 @@
+== Code review
+
+Now let's look at a code review and try to think on an attack with the `alg: none`, so we use the following token:
+
+[source]
+----
+eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwidXNlciI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.
+----
+
+which after decoding becomes:
+
+[source]
+----
+{
+  "alg" : "none",
+  "typ" : "JWT"
+},
+{
+  "admin" : true,
+  "iat" : 1516239022,
+  "sub" : "1234567890",
+  "user" : "John Doe"
+}
+----
+
+[source%linenums, java]
+----
+try {
+   Jwt jwt = Jwts.parser().setSigningKey(JWT_PASSWORD).parseClaimsJws(accessToken);
+   Claims claims = (Claims) jwt.getBody();
+   String user = (String) claims.get("user");
+   boolean isAdmin = Boolean.valueOf((String) claims.get("admin"));
+   if (isAdmin) {
+     removeAllUsers();
+   } else {
+     log.error("You are not an admin user");
+   }
+} catch (JwtException e) {
+  throw new InvalidTokenException(e);
+}
+----
+
+[source%linenums, java]
+----
+try {
+   Jwt jwt = Jwts.parser().setSigningKey(JWT_PASSWORD).parse(accessToken);
+   Claims claims = (Claims) jwt.getBody();
+   String user = (String) claims.get("user");
+   booelean isAdmin = Boolean.valueOf((String) claims.get("admin"));
+   if (isAdmin) {
+     removeAllUsers();
+   } else {
+     log.error("You are not an admin user");
+   }
+} catch (JwtException e) {
+  throw new InvalidTokenException(e);
+}
+----
+
+Can you spot the weakness?
+

src/main/resources/lessons/jwt/documentation/JWT_libraries_assignment2.adoc

@@ -0,0 +1,37 @@
+== Code review (2)
+
+Same as before but now we are only removing the signature part, leaving the algorithm as is.
+
+[source]
+----
+eyJhbGciOiJIUzI1NiJ9.ew0KICAiYWRtaW4iIDogdHJ1ZSwNCiAgImlhdCIgOiAxNTE2MjM5MDIyLA0KICAic3ViIiA6ICIxMjM0NTY3ODkwIiwNCiAgInVzZXIiIDogIkpvaG4gRG9lIg0KfQ.
+
+{
+  "alg" : "HS256"
+},
+{
+  "admin" : true,
+  "iat" : 1516239022,
+  "sub" : "1234567890",
+  "user" : "John Doe"
+}
+----
+
+Using the following `parse` method we are still able to skip the signature check.
+
+[source%linenums, java]
+----
+try {
+   Jwt jwt = Jwts.parser().setSigningKey(JWT_PASSWORD).parse(accessToken);
+   Claims claims = (Claims) jwt.getBody();
+   String user = (String) claims.get("user");
+   boolean isAdmin = Boolean.valueOf((String) claims.get("admin"));
+   if (isAdmin) {
+     removeAllUsers();
+   } else {
+     log.error("You are not an admin user");
+   }
+} catch (JwtException e) {
+  throw new InvalidTokenException(e);
+}
+----

src/main/resources/lessons/jwt/documentation/JWT_libraries_solution.adoc

@@ -0,0 +1,46 @@
+=== 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%]

src/main/resources/lessons/jwt/documentation/JWT_login_to_token.adoc

@@ -0,0 +1,19 @@
+== Authentication and getting a JWT token
+
+A basic sequence of getting a token is as follows:
+
+image::images/jwt_diagram.png[style="lesson-image"]
+
+{nbsp} +
+
+In this flow, you can see the user logs in with a username and password on successful authentication the server
+returns. The server creates a new token and returns this one to the client. When the client makes a successive
+call toward the server it attaches the new token in the "Authorization" header.
+The server reads the token and first validates the signature after a successful verification the server uses the
+information in the token to identify the user.
+
+=== Claims
+
+The token contains claims to identify the user and all other information necessary for the server to fulfill the request.
+Be aware not to store sensitive information in the token and always send it over a secure channel.
+

src/main/resources/lessons/jwt/documentation/JWT_mitigation.adoc

@@ -0,0 +1,9 @@
+=== Best practices
+
+Some best practices when working with JWT:
+
+- Fix the algorithm, do not allow a client to switch the algorithm.
+- Make sure you use an appropriate key length when using a symmetric key for signing the token.
+- Make sure the claims added to the token do not contain personal information. If you need to add more information opt for encrypting the token as well.
+- Add sufficient test cases to your project to verify invalid tokens actually do not work. Integration with a third party to check your token does not mean you do not have test your application at all.
+- Take a look at the best practices mentioned in https://tools.ietf.org/html/rfc8725#section-2

src/main/resources/lessons/jwt/documentation/JWT_plan.adoc

@@ -0,0 +1,38 @@
+= JWT Tokens
+ 
+== Concept 
+
+This lesson teaches about using JSON Web Tokens (JWT) for authentication and the common pitfalls you need to be aware of
+ when using JWT.
+
+== Goals
+
+Teach how to securely implement the usage of tokens and validation of those tokens.
+
+== Introduction
+
+Many application use JSON Web Tokens (JWT) to allow the client to indicate is identity for further exchange after authentication.
+
+From https://jwt.io/introduction:
+-------------------------------------------------------
+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. This information can be
+verified and trusted because it is digitally signed. JWTs can be signed using
+a secret (with the HMAC algorithm) or a public/private key pair using RSA.
+
+JSON Web Token is used to carry information related to the identity and
+characteristics (claims) of a client. This "container" is signed by the server
+in order to avoid that a client tamper it in order to change, for example,
+the identity or any characteristics (example: change the role from simple
+user to admin or change the client login). This token is created during
+authentication (is provided in case of successful authentication) and is
+verified by the server before any processing. It is used by an application
+to allow a client to present a token representing his "identity card" (container
+with all user information about him) to server and allow the server to verify
+the validity and integrity of the token in a secure way, all of this in a stateless
+and portable approach (portable in the way that client and server technologies can
+be different including also the transport channel even if HTTP is the most often used)
+-------------------------------------------------------
+
+

src/main/resources/lessons/jwt/documentation/JWT_refresh.adoc

@@ -0,0 +1,88 @@
+:linkattrs:
+
+
+== Refreshing a token
+
+=== Introduction
+
+In this section we touch upon refreshing an access token.
+
+=== Types of tokens
+
+In general there are two types of tokens: an access token and a refresh token. The access token is used for making API
+calls towards the server. Access tokens have a limited life span, that's where the refresh token comes in. Once
+the access token is no longer valid a request can be made towards the server to get a new access token by presenting
+the refresh token. The refresh token can expire but their life span is much longer. This solves the problem of a user
+having to authenticate again with their credentials. Whether you should use a refresh token and an access token depends,
+below can find a couple of points to keep in mind while choosing which tokens to use.
+
+So a normal flow can look like:
+
+```
+curl -X POST -H -d 'username=webgoat&password=webgoat' localhost:8080/WebGoat/login
+```
+
+The server returns:
+
+```
+{
+    "token_type":"bearer",
+    "access_token":"XXXX.YYYY.ZZZZ",
+    "expires_in":10,
+    "refresh_token":"4a9a0b1eac1a34201b3c5659944e8b7"
+}
+```
+
+As you can see the refresh token is a random string which the server can keep track of (in memory or store in a database)
+in order to match the refresh token to the user the refresh token was granted to.
+So in this case whenever the access token is still valid we can speak of a "stateless" session, there is
+no burden on the server side to setup the user session, the token is self contained.
+When the access token is no longer valid the server needs to query for the stored refresh token to make sure the token
+is not blocked in any way.
+
+Whenever the attacker gets a hold on an access token it is only valid for a certain amount of time (say 10 minutes). The
+attacker then needs the refresh token to get a new access token. That is why the refresh token needs better protection.
+It is also possible to make the refresh token stateless but this means it will become more difficult to see if
+the user revoked the tokens.
+After the server made all the validations it must return a new refresh token and a new access token to the client. The
+client can use the new access token to make the API call.
+
+
+=== What should you check for?
+
+Regardless of the chosen solution you should store enough information on the server side to validate whether the user
+is still trusted. You can think of many things, like store the ip address, keep track of how many times the refresh
+token is used (using the refresh token multiple times in the valid time window of the access token might indicate strange
+behavior, you can revoke all the tokens and let the user authenticate again).
+Also keep track of which access token belonged to which refresh token otherwise an attacker might
+be able to get a new access token for a different user with the refresh token of the attacker
+(see https://emtunc.org/blog/11/2017/jwt-refresh-token-manipulation/ for a nice write up about how this attack works)
+Also a good thing to check for is the ip address or geolocation of the user. If you need to give out a new token check
+whether the location is still the same if not revoke all the tokens and let the user authenticate again.
+
+=== Need for refresh tokens
+
+Does it make sense to use a refresh token in a modern single page application (SPA)? As we have seen in the section
+about storing tokens there are two options: web storage or a cookie which mean a refresh token is right beside an
+access token, so if the access token is leaked chances are the refresh token will also be compromised. Most of the time
+there is a difference of course. The access token is sent when you make an API call, the refresh token is only sent
+when a new access token should be obtained, which in most cases is a different endpoint. If you end up on the same
+server you can choose to only use the access token.
+
+As stated above using an access token and a separate refresh token gives some leverage for the server not to check
+the access token over and over. Only perform the check when the user needs a new access token.
+It is certainly possible to only use an access token. At the server you store the exact same information you would
+store for a refresh token, see previous paragraph. This way you need to check the token each time but this might
+be suitable depending on the application. In the case the refresh tokens are stored for validation it is important to protect these tokens as well (at least
+use a hash function to store them in your database).
+
+=== JWT a good idea?
+
+There are a lot of resources available which question the usecase for using JWT token for client to server authentication
+with regards to cookies. The best place to use a JWT token is between server to server communication. In a normal web
+application you are better of using plain old cookies. See for more information:
+
+- http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/[stop-using-jwt-for-sessions, window="_blank"]
+- http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/[stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work, window="_blank"]
+- http://cryto.net/~joepie91/blog/attachments/jwt-flowchart.png[flowchart, window="_blank"]
+

src/main/resources/lessons/jwt/documentation/JWT_refresh_assignment.adoc

@@ -0,0 +1,13 @@
+:linkattrs:
+
+== Refreshing a token
+
+It is important to implement a good strategy for refreshing an access token. This assignment is based on a vulnerability
+found in a private bug bounty program on Bugcrowd, you can read the full write up https://emtunc.org/blog/11/2017/jwt-refresh-token-manipulation/[here, window="_blank"]
+
+=== Assignment
+
+From a breach of last year the following logfile is available link:images/logs.txt[here]
+Can you find a way to order the books but let *Tom* pay for them?
+
+

src/main/resources/lessons/jwt/documentation/JWT_signing.adoc

@@ -0,0 +1,20 @@
+== JWT signing
+
+Each JWT token should at least be signed before sending it to a client, if a token is not signed the client application
+would be able to change the contents of the token. The signing specifications are defined https://tools.ietf.org/html/rfc7515[here]
+the specific algorithms you can use are described https://tools.ietf.org/html/rfc7518[here]
+It basically comes down you use "HMAC with SHA-2 Functions" or "Digital Signature with RSASSA-PKCS1-v1_5/ECDSA/RSASSA-PSS" function
+for signing the token.
+
+=== Checking the signature
+
+One important step is to *verify the signature* before performing any other action, let's try to see some things you need
+to be aware of before validating the token.
+
+== Assignment
+
+Try to change the token you receive and become an admin user by changing the token and once you are admin reset the votes
+
+
+
+

src/main/resources/lessons/jwt/documentation/JWT_signing_solution.adoc

@@ -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%]
+
+
+

src/main/resources/lessons/jwt/documentation/JWT_storing.adoc

@@ -0,0 +1,35 @@
+== Storing JWT tokens
+
+When receiving a JWT token you need to store it at the client side. There are basically two options:
+
+- Store the token in a cookie
+- Store the token in local/session storage
+
+=== Cookies
+
+Cookies is the most simplest form, every browser supports cookies for a long time. A best practise is to mark the
+cookie with the `HttpOnly` to guarantee scripts cannot read the cookie and with `Secure` to make sure the cookie
+is only sent over HTTPs.
+
+Note: using a cookie does not mean you have maintain a state stored on the server, like the old session cookies worked
+before. The JWT token is self contained and can/should contain all the information necessary to be completely stateless the
+cookie is just used as the transport mechanism.
+
+=== Web storage
+
+In this case you store the token in on the client side in HTML5 Web Storage.
+
+=== Choices, security risks
+
+Web storage is accessible through JavaScript running on the same domain, so the script will have access to the
+web storage. So if the site is vulnerable to a cross-site scripting attack the script is able to read the token
+from the web storage. See XSS lesson for more about how this attack works.
+
+On the other hand using cookies have a different problem namely they are vulnerable to a cross-site request forgery
+attack. In this case the attacker tries to invoke an action on the website you have a token for. See CSRF lesson for more
+information about how this attack works.
+
+The best recommendation is to choose for the cookie based approach. In practise it is easier to defend against a CSRF
+attack. On the other hand many JavaScript frameworks are protecting the user for a XSS attack by applying the right
+encoding, this protection comes out of the box. A CSRF protection sometimes is not provided by default and requires work.
+In the end take a look at what the framework is offering you, but most of the time a XSS attack gives the attacker more leverage.

src/main/resources/lessons/jwt/documentation/JWT_structure.adoc

@@ -0,0 +1,17 @@
+== Structure of a JWT token
+
+Let's take a look at the structure of a JWT token:
+
+[role="lesson-image"]
+image::images/jwt_token.png[JWT]
+
+The token is base64 encoded and consists of three parts:
+
+ - header
+ - claims
+ - signature
+
+Both header and claims consist are respresented by a JSON object. The header describes the cryptographic operations applied to the JWT and optionally, additional properties of the JWT.
+The claims represent a JSON object whose members are the claims conveyed by the JWT.
+
+

src/main/resources/lessons/jwt/documentation/JWT_weak_keys

@@ -0,0 +1,10 @@
+== JWT cracking
+
+With the HMAC with SHA-2 Functions you use a secret key to sign and verify the token. Once we figure out this key
+we can create a new token and sign it. So it is very important the key is strong enough so a brute force or
+dictionary attack is not feasible. Once you have a token you can start an offline brute force or dictionary attack.
+
+=== Assignment
+
+Given we have the following token try to find out secret key and submit a new key with the username changed to WebGoat.
+