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/logging/documentation/logReading_Task.adoc

@@ -0,0 +1,5 @@
+=== Let's try
+
+- Some servers provide Administrator credentials at the boot-up of the server.
+- The goal of this challenge is to find the secret in the application log of the WebGoat server to login as the Admin user.
+- Note that we tried to "protect" it. Can you decode it?

src/main/resources/lessons/logging/documentation/logSpoofing_Task.adoc

@@ -0,0 +1,5 @@
+=== Let's try
+
+- The goal of this challenge is to make it look like username "admin" succeeded in logging in.
+- The red area below shows what will be logged in the web server's log file.
+- Want to go beyond? Try to elevate your attack by adding a script to the log file.

src/main/resources/lessons/logging/documentation/logging_intro.adoc

@@ -0,0 +1,13 @@
+
+== Concept
+Logging is very important for modern systems. We use it for various reasons:
+
+- Application monitoring and debugging.
+- Audit logging: E.g. record specific actions of your users and systems.
+- Security Event Monitoring: e.g. provide information to a SIEM or SOAR system that will trigger based on the information provided in these logs.
+
+== Goals
+* The user should have a basic understanding of logging and where to log for.
+* The user understands the risks of log spoofing and leaking log information.
+* The user will be able to do a simple log spoofing attack.
+* The user will be able to tell the basic risks involved in logging.

src/main/resources/lessons/logging/documentation/more_logging.adoc

@@ -0,0 +1,32 @@
+=== More About Logging (2)
+
+By now it should be clear that using simple encoding/decoding is not a way to protect sensitive information in a log. Instead, it is better to use different techniques: not logging the data at all, blanking it out, or encrypting it with another shared secret.
+
+There are a few more topics we might want to cover here:
+
+- How to work with log-levels
+- How to do Exception Handling
+- How to use logging for other purposes
+- Some resources to read up on.
+
+==== Log Levels
+Explain log levels
+
+==== Exception Handling
+ exception handling (maybe an example of logging exception towards the client with cryptography and why this is a bad idea)
+
+
+==== Audit Logging, Security Event Monitoring, and Application Logs
+Note that logging is often used for more than just application debugging. Application logs are often used as a feed for other purposes, think of:
+
+ - *Audit logging*: Specific events need to be recorded by your application log to create a trail that can be used to reconstruct the actions done on behalf of/by your user. This can later be used, for instance, in court to prove what happened in case of a dispute.
+ - *Security Event Monitoring (SEM)*: Events generated by your application can often be used by your security department to understand what is going on in the application landscape of the organization. There are various types of events as well as various attributes that can play a role to detect whether the organization is in trouble. For instance: a privileged administrative logon that is only used as a break-glass procedure can already be a very valuable event for them. Another example: While frequently used administrative logons are good to record, they might not trigger an event at the security department by themselves, unless a completely different location is used for that administrative role. A threat model exercise with your security department can often help to understand which types of logs they require, and what they should trigger a security alert on immediately.
+ - *Fraud Detection*: your application logs can help in fraud detection. For instance: logs that show that someone is trying to move around more money than that they have, could indicate something is going wrong.
+ - *Business Process Monitoring*: your application logs can be used to see if the business processes are still progressing as they should. For instance: the lack of new events further down a process could indicate that the business process has stopped. This can be valuable information to the business when it comes to steering the company.
+ - *And many more*...
+
+Note that a lot of these logging purposes differ quite a lot from each other! Therefore it is best to separate your application (debug) logging, from your SEM, and audit logs in terms of output by your application, storage and processing of the logs within your organization.
+
+==== More reading
+
+- link:https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html[The OWASP Logging Cheat sheet]

src/main/resources/lessons/logging/documentation/sensitive_logging_intro.adoc

@@ -0,0 +1,36 @@
+=== More About Logging
+
+As you can tell by now, log-spoofing can become an issue when users try to spoof logs. There are various ways to do this other than a form-post. Think of URL parameters or crafted JSON payloads for instance. Therefore, it is important to do
+
+- apply proper input-sanitization
+- make sure you can establish source authenticity and implement integrity controls to detect log-tampering.
+- make sure that a user cannot inject logs from any channel
+- make sure that the log storage is protected
+
+But there is more to log security than just sanitization against spoofing attacks. Let's have a look at logging sensitive information.
+
+==== Logging Sensitive Information
+
+In the previous exercise, we saw only the username passing by, but no password. Why? Because we want to make sure that an application log does not contain any sensitive information. Let's make sure that when our logs get compromised, we do not have to fear authentication information to be reused.
+
+Similarly, we should not log any other sensitive information, such as symmetric or private keys, access tokens, and such.
+
+==== Logging Personal Information
+
+Be careful with logging personal information. For instance: do not log bank account details, personally identifiable information to which a user did not consent having it logged. Do not log facts that can establish the identity of the subject being logged.
+
+What you basically want to prevent, is that people use the logs to profile people or spy on them. You want to protect the privacy of the subjects using your system.
+
+===== Special case: Access Logs
+
+One special case is always the access logs offered by your ingress and/or application server. These logs should contain at least a few things: Where the request came from, when the request was made, and possibly what the response code was. Additional information can be shared in an access log, depending on the security of the log. For instance: you don't want to share the raw request in the access logs to safeguard the privacy of your users.
+
+And here the problem often starts: access logs sometimes capture the full URL used for the request. This can include sensitive URL parameters. Therefore: be careful with what you put in the URL as parameters & let's make sure that you do not log those in an openly accessible log.
+
+
+==== Read more
+
+Want to read up on more about logging? Have a look at:
+
+- link:https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html[The OWASP Logging Cheat sheet]
+- link:https://en.wikipedia.org/wiki/General_Data_Protection_Regulation#Principles[GDPR article at Wikipedia]

src/main/resources/lessons/logging/html/LogSpoofing.html

@@ -0,0 +1,55 @@
+<!DOCTYPE html>
+
+<html xmlns:th="http://www.thymeleaf.org">
+
+<div class="lesson-page-wrapper">
+    <!-- reuse this lesson-page-wrapper block for each 'page' of content in your lesson -->
+    <!-- include content here. Content will be presented via asciidocs files,
+    which you put in src/main/resources/plugin/lessonplans/{lang}/{fileName}.adoc -->
+    <div class="adoc-content" th:replace="doc:lessons/logging/documentation/logging_intro.adoc"></div>
+</div>
+
+<div class="lesson-page-wrapper">
+    <!-- stripped down without extra comments -->
+    <div class="adoc-content" th:replace="doc:lessons/logging/documentation/logSpoofing_Task.adoc"></div>
+    <div class="attack-container">
+        <div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
+        <form class="attack-form" accept-charset="UNKNOWN" name="task"
+              method="POST"
+              action="/WebGoat/LogSpoofing/log-spoofing">
+
+            <input type="text" value="" name="username" placeholder="username"/>
+            <input type="password" value="" name="password" placeholder="password"/>
+            <input type="submit" value="Submit"/>
+
+        </form>
+        <div class="attack-feedback"></div>
+        Log output:
+        <div style="background-color:red;color:white;">Login failed for username:<p class="attack-output"
+                                                                                    style="display:inline;"></p></div>
+    </div>
+</div>
+<div class="lesson-page-wrapper">
+    <div class="adoc-content" th:replace="doc:lessons/logging/documentation/sensitive_logging_intro.adoc"></div>
+</div>
+<div class="lesson-page-wrapper">
+    <div class="adoc-content" th:replace="doc:lessons/logging/documentation/logReading_Task.adoc"></div>
+    <div class="attack-container">
+        <div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
+        <form class="attack-form" accept-charset="UNKNOWN" name="task"
+              method="POST"
+              action="/WebGoat/LogSpoofing/log-bleeding">
+
+            <input type="text" value="" name="username" placeholder="username"/>
+            <input type="password" value="" name="password" placeholder="password"/>
+            <input type="submit" value="Submit"/>
+
+        </form>
+        <div class="attack-feedback"></div>
+        <div class="attack-output"></div>
+    </div>
+</div>
+<div class="lesson-page-wrapper">
+    <div class="adoc-content" th:replace="doc:lessons/logging/documentation/more_logging.adoc"></div>
+</div>
+</html>

src/main/resources/lessons/logging/i18n/WebGoatLabels.properties

@@ -0,0 +1,2 @@
+logging.title=Logging Security
+