- Introduced user registration

- Now using Spring Boot for classloading, this way local development does not need to restart the complete server
- Fixed all kinds of dependencies on the names of the lessons necessary to keep in mind during the creation of a lesson.
- Simplied loading of resources, by adding resource mappings in MvcConfig.
- Refactored plugin loading, now only one class is left for loading the lessons.
This commit is contained in:
Nanne Baars
2017-02-25 12:15:07 +01:00
parent 9b86aaba05
commit 259fd19c1b
221 changed files with 1179 additions and 1083 deletions

View File

@ -0,0 +1,39 @@
package org.owasp.webgoat.plugin;
import com.beust.jcommander.internal.Lists;
import org.owasp.webgoat.lessons.Category;
import org.owasp.webgoat.lessons.NewLesson;
import java.util.List;
/**
* @author nbaars
* @since 3/22/17.
*/
public class JWT extends NewLesson {
@Override
public Category getDefaultCategory() {
return Category.AUTHENTICATION;
}
@Override
public List<String> getHints() {
return Lists.newArrayList();
}
@Override
public Integer getDefaultRanking() {
return null;
}
@Override
public String getTitle() {
return "jwt.title";
}
@Override
public String getId() {
return "JWT";
}
}

View File

@ -0,0 +1,42 @@
<!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, or can be placed in another location. Content will be presented via asciidocs files,
which you put in src/main/resources/lessonplans/{lang}/{fileName}.adoc -->
<div class="adoc-content" th:replace="doc:JWT_plan.adoc"></div>
</div>
<div class="lesson-page-wrapper">
<!-- reuse this block for each 'page' of content -->
<!-- sample ascii doc content for second page -->
<div class="adoc-content" th:replace="doc:JWT_content1.adoc"></div>
<!-- if including attack, reuse this section, leave classes in place -->
<div class="attack-container">
<div class="assignment-success"><i class="fa fa-2 fa-check hidden" aria-hidden="true"></i></div>
<!-- using attack-form class on your form will allow your request to be ajaxified and stay within the display framework for webgoat -->
<!-- you can write your own custom forms, but standard form submission will take you to your endpoint and outside of the WebGoat framework -->
<!-- of course, you can write your own ajax submission /handling in your own javascript if you like -->
<form class="attack-form" accept-charset="UNKNOWN"
method="POST" name="form"
action="/WebGoat/HttpBasics/attack1"
enctype="application/json;charset=UTF-8">
<div id="lessonContent">
<form accept-charset="UNKNOWN" method="POST" name="form"
action="#attack/307/100" enctype="">
Enter Your Name: <input name="person" value="" type="TEXT"/><input
name="SUBMIT" value="Go!" type="SUBMIT"/>
</form>
</div>
</form>
<!-- do not remove the two following div's, this is where your feedback/output will land -->
<div class="attack-feedback"></div>
<div class="attack-output"></div>
<!-- ... of course, you can move them if you want to, but that will not look consistent to other lessons -->
</div>
</div>
</html>

View File

@ -0,0 +1 @@
jwt.title=JWT tokens

View File

@ -0,0 +1 @@
== Test

View File

@ -0,0 +1,39 @@
= 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.
== 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)
-------------------------------------------------------