diff --git a/src/main/java/org/owasp/webgoat/lessons/AbstractLesson.java b/src/main/java/org/owasp/webgoat/lessons/AbstractLesson.java
index 21571e100..130b81ed5 100644
--- a/src/main/java/org/owasp/webgoat/lessons/AbstractLesson.java
+++ b/src/main/java/org/owasp/webgoat/lessons/AbstractLesson.java
@@ -60,8 +60,8 @@ import org.slf4j.LoggerFactory;
*
* Getting Source ==============
*
- * Source for this application is maintained at https://github.com/WebGoat/WebGoat, a repository
- * for free software projects.
+ * Source for this application is maintained at
+ * https://github.com/WebGoat/WebGoat, a repository for free software projects.
*
* For details, please see http://webgoat.github.io
*
@@ -70,7 +70,7 @@ import org.slf4j.LoggerFactory;
*/
public abstract class AbstractLesson extends Screen implements Comparable
-
Adding Users
-
-Usually WebGoat only requires logging in with the user:guest and password:guest.
- But maybe in laboratory you have made a setup with one server and a lot of
-clients. In this case you might want to have a user for every client,
- you will have to alter /WEB-INF/spring-security.xml to add additional users. We recommend not to use real passwords
-as the passwords are stored in plain text in this file!
-
-
Adding a new User
-
-Adding a user is straight forward. You can use the guest entry as an example. The added
-users should have the same role as the guest user. The new user/password will not show on the login page.
-Add lines like this to the /WEB-INF/spring-security.xml file:
-
Lesson Plan Title: How to Discover Clues in the HTML
-
-
-
Concept / Topic To Teach:
-
- Developers are notorious for leaving statements like FIXME's, TODO's, Code Broken, Hack, etc... inside the source code. Review the source code for any comments denoting passwords, backdoors, or something doesn't work right.
- Below is an example of a forms based authentication form. Look for clues to help you log in.
-
-
-
General Goal(s):
-The user should be able to bypass the authentication check.
diff --git a/src/main/webapp/lesson_plans/English/HttpBasics.html b/src/main/webapp/lesson_plans/English/HttpBasics.html
deleted file mode 100644
index f3321f295..000000000
--- a/src/main/webapp/lesson_plans/English/HttpBasics.html
+++ /dev/null
@@ -1,27 +0,0 @@
-
-
Lesson Plan Title: Http Basics
-
-
-
Concept / Topic To Teach:
- This lesson presents the basics for understanding the transfer of data between the browser and the web application.
-
-
-How HTTP works:
-
-All HTTP transactions follow the same general format. Each client request and server response has three parts: the request or response line, a header section and the entity body. The client initiates a transaction as follows:
-
- The client contacts the server and sends a document request
-
-
-
GET /index.html?param=value HTTP/1.0
- Next, the client sends optional header information to inform the server of its configuration and the document formats it will accept.
-
-
-After sending the request and headers, the client may send additional data. This data is mostly used by CGI programs using the POST method.
-
General Goal(s):
-
-Enter your name in the input field below and press "Go!" to submit. The server will accept the request, reverse the input and display it back to the user, illustrating the basics of handling an HTTP request.
-
-The user should become familiar with the features of WebGoat by manipulating the above
-buttons to view hints, show the HTTP request parameters, the HTTP request cookies, and the Java source code. You may also try using OWASP Zed Attack Proxy for the first time.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/HttpOnly.html b/src/main/webapp/lesson_plans/English/HttpOnly.html
deleted file mode 100644
index aea12470c..000000000
--- a/src/main/webapp/lesson_plans/English/HttpOnly.html
+++ /dev/null
@@ -1,26 +0,0 @@
-
-
Lesson Plan Title: HttpOnly Test
-
-
Concept / Topic To Teach:
-
-To help mitigate the cross site scripting threat, Microsoft has
-introduced a new cookie attribute entitled 'HttpOnly.' If this flag is
-set, then the browser should not allow client-side script to access the
-cookie. Since the attribute is relatively new, several browsers neglect
-to handle the new attribute properly.
-
-The purpose of this lesson is to test whether your browser supports the
-HTTPOnly cookie flag. Note the value of the
-unique2u
-cookie. If your browser supports HTTPOnly, and you enable it for a
-cookie, client side code should NOT be able to read OR write to that
-cookie, but the browser can still send its value to the server. Some
-browsers only prevent client side read access, but don't prevent write
-access.
-
-
-With the HTTPOnly attribute turned on, type
-"javascript:alert(document.cookie)" in the browser address bar. Notice
-all cookies are displayed except the unique2u cookie.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/HttpSplitting.html b/src/main/webapp/lesson_plans/English/HttpSplitting.html
deleted file mode 100644
index bf042b323..000000000
--- a/src/main/webapp/lesson_plans/English/HttpSplitting.html
+++ /dev/null
@@ -1,35 +0,0 @@
-
-
Lesson Plan Title: How to Perform HTTP Splitting
-
-
-
Concept / Topic To Teach:
- This lesson teaches how to perform HTTP Splitting attacks.
-
-
-
-How the attack works:
-
-
The attacker passes malicious code to the web server together with normal input.
-A victim application will not be checking for CR (carriage return, also given by %0d or \r)
-and LF (line feed, also given by %0a or \n) characters. These characters not only give attackers control
-of the remaining headers and body of the response the application intends to send,
-but they also allows them to create additional responses entirely under their control.
-
The effect of an HTTP Splitting attack is maximized when accompanied with a Cache Poisoning. The goal of
-Cache Poisoning attack is to poison the cache of the victim by fooling the cache into believing that the page
-hijacked using the HTTP splitting is an authentic version of the server's copy.
-
The attack works by using the HTTP Splitting attack plus adding the Last-Modified: header and setting it
-to a future date. This forces the browser to send an incorrect If-Modified-Since request header on future requests.
-Because of this, the server will always report that the (poisoned) page has not changed, and the victim's browser
-will continue to display the attacked version of the page.
-
A sample of a 304 response is:
-
HTTP/1.1 304 Not Modified
-Date: Fri, 30 Dec 2005 17:32:47 GMT
-
-
-
General Goal(s):
-
-
This lesson has two stages. Stage 1 teaches you how to do HTTP Splitting attacks while stage 2 builds on that to teach you how to elevate HTTP Splitting to Cache Poisoning.
-
Enter a language for the system to search by. You will notice that the application is redirecting your request to another resource on the server. You should be able to use the CR (%0d) and LF (%0a) characters to exploit the attack. Your goal should be to force the server to send a 200 OK. If the screen changed as an effect to your attack, just go back to the homepage. After stage 2 is exploited successfully, you will find the green check in the left menu.
-
You may find the PHP Charset Encoder useful. The Encode and DecodeURIComponent buttons translate CR and LF.
-
-Sensitive data should never sent in plaintext! Often applications
-switch to a secure connection after the authorization. An attacker
-could just sniff the login and use the gathered information to
-break into an account. A good webapplication always takes care of
-encrypting sensitive data.
-
General Goal(s):
-See how easy it is to sniff a password in plaintext.
-Understand the advantages of encrypting the login data!
-
diff --git a/src/main/webapp/lesson_plans/English/JSONInjection.html b/src/main/webapp/lesson_plans/English/JSONInjection.html
deleted file mode 100644
index 4c72bd04f..000000000
--- a/src/main/webapp/lesson_plans/English/JSONInjection.html
+++ /dev/null
@@ -1,24 +0,0 @@
-
-
Lesson Plan Title: How to Perform JSON Injection
-
-
-
Concept / Topic To Teach:
-This lesson teaches how to perform JSON Injection Attacks.
-
-
-
-How the attacks works:
-
-JavaScript Object Notation (JSON) is a simple and effective lightweight data exchange format. JSON can be in a lot of forms such as arrays, lists, hashtables and other data structures.
-JSON is widely used in AJAX and Web2.0 application and is favored by programmers over XML because of its ease of use and speed.
-However, JSON, like XML is prone to Injection attacks. A malicious attacker can inject the reply from the server and inject some arbitrary values in there.
-
-
-
General Goal(s):
-
-* You are traveling from Boston, MA- Airport code BOS to Seattle, WA - Airport code SEA.
-* Once you enter the three digit code of the airport, an AJAX request will be executed asking for the ticket price.
-* You will notice that there are two flights available, an expensive one with no stops and another cheaper one with 2 stops.
-* Your goal is to try to get the one with no stops but for a cheaper price.
-
-
diff --git a/src/main/webapp/lesson_plans/English/JavaScriptValidation.html b/src/main/webapp/lesson_plans/English/JavaScriptValidation.html
deleted file mode 100644
index 7819de2bf..000000000
--- a/src/main/webapp/lesson_plans/English/JavaScriptValidation.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
Lesson Plan Title: How to Bypass Client Side JavaScript Validation
-
-
Concept / Topic To Teach:
-
-Client-side validation should not be considered a secure means of validating parameters. These validations only help reduce the amount of server processing time for normal users who do not know the format of required input. Attackers can bypass these mechanisms easily in various ways. Any client-side validation should be duplicated on the server side. This will greatly reduce the likelihood of insecure parameter values being used in the application.
-
-
-
General Goal(s):
-For this exercise, the web site requires that you follow certain rules when you fill out a form. The user should be able to break those rules, and send the website input that it wasn't expecting.
-
-This website performs both client and server side validation. For this exercise, your job is to break the client side validation and send the
- website input that it wasn't expecting. You must break all 7 validators at the same time.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/Lesson_Plan_Template.html b/src/main/webapp/lesson_plans/English/Lesson_Plan_Template.html
deleted file mode 100644
index 66293a95c..000000000
--- a/src/main/webapp/lesson_plans/English/Lesson_Plan_Template.html
+++ /dev/null
@@ -1,17 +0,0 @@
-
-
Lesson Plan Title:
-
-
-
Concept / Topic To Teach:
-
Standards Addressed:
-
General Goal(s):
-
Specific Objectives:
-
Required Materials:
-
Anticipatory Set (Lead-In):
-
Step-By-Step Procedures:
-
Plan For Independent Practice:
-
Closure (Reflect Anticipatory Set):
-
Assessment Based On Objectives:
-
Extensions (For Gifted Students):
-
Possible Connections To Other Subjects:
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/LogSpoofing.html b/src/main/webapp/lesson_plans/English/LogSpoofing.html
deleted file mode 100644
index 105e38f54..000000000
--- a/src/main/webapp/lesson_plans/English/LogSpoofing.html
+++ /dev/null
@@ -1,20 +0,0 @@
-
-
Lesson Plan Title: How to Perform Log Spoofing.
-
-
-
Concept / Topic To Teach:
- This lesson teaches attempts to fool the human eye.
-
-
-
-How the attacks works:
-The attack is based on fooling the humane eye in log files. An attacker can erase his traces from the logs
-using this attack.
-
-
-
General Goal(s):
-
-* The grey area below represents what is going to be logged in the web server's log file.
-* Your goal is to make it like a username "admin" has succeeded into logging in.
-* Elevate your attack by adding a script to the log file.
-
diff --git a/src/main/webapp/lesson_plans/English/MultiLevelLogin1.html b/src/main/webapp/lesson_plans/English/MultiLevelLogin1.html
deleted file mode 100644
index b5bd6118d..000000000
--- a/src/main/webapp/lesson_plans/English/MultiLevelLogin1.html
+++ /dev/null
@@ -1,20 +0,0 @@
-
-
Lesson Plan Title: Multi Level Login 1
-
-
Concept / Topic To Teach:
-
-A Multi Level Login should provide a strong authentication.
-This is archived by adding a second layer. After having
-logged in with your user name and password you are asked
-for a 'Transaction Authentication Number' (TAN). This is
-often used by online banking. You get a list with a lots
-of TANs generated only for you by the bank. Each TAN is used only once.
-Another method is to provide the TAN by SMS. This has
-the advantage that an attacker can not get TANs provided
-by the user.
-
General Goal(s):
-In this Lesson you try to get around the strong authentication.
-You have to break into another account. The user name, password and a
-already used TAN is provided. You have to make sure
-the server accept the TAN even it is already used.
-
diff --git a/src/main/webapp/lesson_plans/English/MultiLevelLogin2.html b/src/main/webapp/lesson_plans/English/MultiLevelLogin2.html
deleted file mode 100644
index 3514b7148..000000000
--- a/src/main/webapp/lesson_plans/English/MultiLevelLogin2.html
+++ /dev/null
@@ -1,20 +0,0 @@
-
-
Lesson Plan Title: Multi Level Login 2
-
-
Concept / Topic To Teach:
-
-A Multi Level Login should provide a strong authentication.
-This is archived by adding a second layer. After having
-logged in with your user name and password you are asked
-for a 'Transaction Authentication Number' (TAN). This is
-often used by online banking. You get a list with a lots
-of TANs generated only for you by the bank. Each TAN is used only once.
-Another method is to provide the TAN by SMS. This has
-the advantage that an attacker can not get TANs provided
-by the user.
-
General Goal(s):
-In this lesson you have to try to break into another account.
-You have an own account for WebGoat Financial but you want to
-log into another account only knowing the user name of the victim
-to attack.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/NewLesson.html b/src/main/webapp/lesson_plans/English/NewLesson.html
deleted file mode 100644
index 234b170d8..000000000
--- a/src/main/webapp/lesson_plans/English/NewLesson.html
+++ /dev/null
@@ -1,13 +0,0 @@
-
-
-
Create A WebGoat Lesson
-
-Adding lessons to WebGoat is very easy. If you have an idea that would be suitable
-for a new lesson, follow these few simple instructions to implement it:
-
-Accounts are only as secure as their passwords. Most users have the same weak password everywhere. If you want to protect them against brute-force-attacks your application should have good requirements for passwords. The password should contain lower case letters, capitals, numbers and special characters. The longer the password, the better, consider using a passphrase instead. For
-more information see: OWASP proper password strength.
-
-
-
General Goal(s):
- For this exercise, your job is to test several passwords on https://howsecureismypassword.net/
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/PathBasedAccessControl.html b/src/main/webapp/lesson_plans/English/PathBasedAccessControl.html
deleted file mode 100644
index 235bd2528..000000000
--- a/src/main/webapp/lesson_plans/English/PathBasedAccessControl.html
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
Lesson Plan Title: How to Bypass a Path Based Access Control Scheme
-
-
Concept / Topic To Teach:
-
-In a path based access control scheme, an attacker can traverse a path by providing relative path information. Therefore an attacker can use relative paths to access files that normally are not directly accessible by anyone, or would otherwise be denied if requested directly.
-
-
General Goal(s):
-The user should be able to access a file that is not in the listed directory.
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/Phishing.html b/src/main/webapp/lesson_plans/English/Phishing.html
deleted file mode 100644
index 9b0127d14..000000000
--- a/src/main/webapp/lesson_plans/English/Phishing.html
+++ /dev/null
@@ -1,16 +0,0 @@
-
-
Lesson Plan Title: Phishing with XSS
-
-
Concept / Topic To Teach:
-
-It is always a good practice to validate all input on the server side.
- XSS can occur when unvalidated user input is used in an HTTP response.
- With the help of XSS you can do a Phishing Attack and add content to a page
- which looks official. It is very hard for a victim to determinate
- that the content is malicious.
-
-
General Goal(s):
-The user should be able to add a form asking for username
-and password. On submit the input should be sent
-to http://localhost/WebGoat/catcher?PROPERTY=yes &user=catchedUserName&password=catchedPasswordName
-
diff --git a/src/main/webapp/lesson_plans/English/ReflectedXSS.html b/src/main/webapp/lesson_plans/English/ReflectedXSS.html
deleted file mode 100644
index 9db959e07..000000000
--- a/src/main/webapp/lesson_plans/English/ReflectedXSS.html
+++ /dev/null
@@ -1,13 +0,0 @@
-
-
Lesson Plan Title: How to Perform Reflected Cross Site Scripting (XSS)
-
-
Concept / Topic To Teach:
-
-It is always a good practice to validate all input on the server side.
- XSS can occur when unvalidated user input is used in an HTTP response.
- In a reflected XSS attack, an attacker can craft a URL with the attack
- script and post it to another website, email it, or otherwise get a
- victim to click on it.
-
-
General Goal(s):
-For this exercise, your mission is to come up with some input containing a script. You have to try to get this page to reflect that input back to your browser, which will execute the script and do something bad.
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/RemoteAdminFlaw.html b/src/main/webapp/lesson_plans/English/RemoteAdminFlaw.html
deleted file mode 100644
index e852cbcba..000000000
--- a/src/main/webapp/lesson_plans/English/RemoteAdminFlaw.html
+++ /dev/null
@@ -1,11 +0,0 @@
-
-
Lesson Plan Title: How to Force Browser Web Resources
-
-
Concept / Topic To Teach:
-Applications will often have an administrative interface that allows privileged users access to functionality that normal users shouldn't see. The application server will often have an admin interface as well.
-
Standards Addressed :
-
General Goal(s):
-
-Try to access the administrative interface for WebGoat. You may also try to access the administrative interface for Tomcat. The Tomcat admin interface can be accessed via a URL (/admin) and will not count towards the completion of this lesson.
-
-
-
-In role-based access control scheme, a role represents a set of access permissions and privileges. A user can be assigned one or more roles. A role-based access control normally consists of two parts: role permission management and role assignment. A broken role-based access control scheme might allow a user to perform accesses that are not allowed by his/her assigned roles, or somehow obtain unauthorized roles.
-
-
General Goal(s):
-Your goal is to explore the access control rules that govern this site. Each role has permission to certain resources (A-F). Each user is assigned one or more roles. Only the user with the [Admin] role should have access to the 'F' resources. In a successful attack, a user doesn't have the [Admin] role can access resource F.
-
-
-SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible number of systems on the internet are susceptible to this form of attack.
-
-Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented.
-
-It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queiries, even if the threat of SQL injection has been prevented in some other manner.
-
General Goal(s):
-For this exercise, you will perform SQLInjection attacks. You will also implement code changes in the web application to defeat these attacks.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/SameOriginPolicyProtection.html b/src/main/webapp/lesson_plans/English/SameOriginPolicyProtection.html
deleted file mode 100644
index b7db5d10e..000000000
--- a/src/main/webapp/lesson_plans/English/SameOriginPolicyProtection.html
+++ /dev/null
@@ -1,13 +0,0 @@
-
-
Lesson Plan Title: Same Origin Policy Protection
-
-
Concept / Topic To Teach:
-
-A key element of AJAX is the XMLHttpRequest (XHR), which allows javascript to make asynchronous
-calls from the client side to a server. However, as a security measure these requests may
-only be made to the server from which the client page originated.
-
-
General Goal(s):
-This exercise demonstrates the Same Origin Policy Protection. XHR requests
-can only be passed back to the originating server. Attempts to pass data to
-a non-originating server will fail.";
diff --git a/src/main/webapp/lesson_plans/English/SessionFixation.html b/src/main/webapp/lesson_plans/English/SessionFixation.html
deleted file mode 100644
index c7e70f3aa..000000000
--- a/src/main/webapp/lesson_plans/English/SessionFixation.html
+++ /dev/null
@@ -1,33 +0,0 @@
-
-
Lesson Plan Title: Session Fixation
-
-
-
Concept / Topic To Teach:
-How to steal a session with a 'Session Fixation'
-
-
-
-How the attacks works:
-
-A user is recognized by the server by an unique Session ID. If a
-user has logged in and is authorized he does not have to
-reauthorize when he revisits the application as the user is recognized
-by the Session ID. In some applications it is possible to deliver
-the Session ID in the Get-Request. Here is where the attack starts.
-
-An attacker can send a hyperlink to a victim with a chosen Session ID.
-This can be done for example by a prepared mail which looks like an
-official mail from the application administrator.
-If the victim clicks on the link and logs in he is authorized
-by the Session ID the attacker has chosen. The attacker
-can visit the page with the same ID and is recognized as the victim and
-gets logged in without authorization.
-
-
General Goal(s):
-
-This lesson has several stages. You play the attacker but also the victim.
-After having done this lesson it should be understood how
-a Session Fixation in general works. It should be also understood that
-it is a bad idea to use the Get-Request for Session IDs.
-
-
diff --git a/src/main/webapp/lesson_plans/English/SilentTransactions.html b/src/main/webapp/lesson_plans/English/SilentTransactions.html
deleted file mode 100644
index d3377dce8..000000000
--- a/src/main/webapp/lesson_plans/English/SilentTransactions.html
+++ /dev/null
@@ -1,24 +0,0 @@
-
-
Lesson Plan Title: How to Perform Silent Transactions Attacks.
-
-
-
Concept / Topic To Teach:
-This lesson teaches how to perform silent transactions attacks.
-
-
-
-How the attacks works:
-
-Any system that silently processes transactions using a single submission is dangerous to the client.
-For example, if a normal web application allows a simple URL submission, a preset session attack will
-allow the attacker to complete a transaction without the user’s authorization.
-In Ajax, it gets worse: the transaction is silent; it happens with no user feedback on the page,
-so an injected attack script may be able to steal money from the client without authorization.
-
-
General Goal(s):
-
-* This is a sample internet banking application - money transfer page.
-* It shows below your balance, the account you are transferring to and amount you will transfer.
-* The application uses AJAX to submit the transaction after doing some basic client side validations.
-* Your goal is to try to bypass the user's authorization and silently execute the transaction.
-
diff --git a/src/main/webapp/lesson_plans/English/SoapRequest.html b/src/main/webapp/lesson_plans/English/SoapRequest.html
deleted file mode 100644
index b96226617..000000000
--- a/src/main/webapp/lesson_plans/English/SoapRequest.html
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
Lesson Plan Title: How to Create a SOAP Request
-
-
Concept / Topic To Teach:
-
-Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL). Let's learn something about WSDL files. Check out WebGoat's web service description language (WSDL) file.
-
General Goal(s):
-Try connecting to the WSDL with a browser or Web Service tool. The URL for the web service is: http://localhost/WebGoat/services/SoapRequest The WSDL can usually be viewed by adding a ?WSDL on the end of the web service request. You must access 2 of the operations to pass this lesson.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/SqlNumericInjection.html b/src/main/webapp/lesson_plans/English/SqlNumericInjection.html
deleted file mode 100644
index a081c1a29..000000000
--- a/src/main/webapp/lesson_plans/English/SqlNumericInjection.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
Lesson Plan Title: How to Perform Numeric SQL Injection
-
-
-
Concept / Topic To Teach:
-
-SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible number of systems on the internet are susceptible to this form of attack.
-
-Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented.
-
-It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries, even if the threat of SQL injection has been prevented in some other manner.
-
General Goal(s):
-The form below allows a user to view weather data. Try to inject an SQL string that results in all the weather data being displayed.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/SqlStringInjection.html b/src/main/webapp/lesson_plans/English/SqlStringInjection.html
deleted file mode 100644
index 2dc84b697..000000000
--- a/src/main/webapp/lesson_plans/English/SqlStringInjection.html
+++ /dev/null
@@ -1,14 +0,0 @@
-
-
Lesson Plan Title: How to Perform String SQL Injection
-
-
-
Concept / Topic To Teach:
-
-SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible number of systems on the internet are susceptible to this form of attack.
-
-Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented.
-
-It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries, even if the threat of SQL injection has been prevented in some other manner.
-
General Goal(s):
-The form below allows a user to view their credit card numbers. Try to inject an SQL string that results in all the credit card numbers being displayed. Try the user name of 'Smith'.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/StoredXss.html b/src/main/webapp/lesson_plans/English/StoredXss.html
deleted file mode 100644
index e2662164f..000000000
--- a/src/main/webapp/lesson_plans/English/StoredXss.html
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
Lesson Plan Title: How to Perform Stored Cross Site Scripting (XSS)
-
-
Concept / Topic To Teach:
-
-It is always a good practice to scrub all input, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere in the application. Users should not be able to create message content that could cause another user to load an undesireable page or undesireable content when the user's message is retrieved.
-
-
General Goal(s):
-The user should be able to add message content that cause another user to load an undesireable page or content.
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/ThreadSafetyProblem.html b/src/main/webapp/lesson_plans/English/ThreadSafetyProblem.html
deleted file mode 100644
index 1b01a915d..000000000
--- a/src/main/webapp/lesson_plans/English/ThreadSafetyProblem.html
+++ /dev/null
@@ -1,22 +0,0 @@
-
-
-
-
-
- Lesson Plan
-
-
-
-
-
Lesson Plan Title: How to Exploit Thread Safety Problems
-
-
-
Concept / Topic To Teach:
-
- Web applications can handle many HTTP requests simultaneously. Developers often use variables that are not thread safe. Thread safety means that the fields of an object or class always maintain a valid state when used concurrently by multiple threads. It is often possible to exploit a concurrency bug by loading the same page as another user at the exact same time. Because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently.
-
-
General Goal(s):
-The user should be able to exploit the concurrency error in the web application and view login information for another user that is attempting the same function at the same time. This will require the use of two browsers.
-
-
-
diff --git a/src/main/webapp/lesson_plans/English/TomcatSetup.html b/src/main/webapp/lesson_plans/English/TomcatSetup.html
deleted file mode 100644
index decbd49df..000000000
--- a/src/main/webapp/lesson_plans/English/TomcatSetup.html
+++ /dev/null
@@ -1,80 +0,0 @@
-
-
How To Configure Tomcat
-
Introduction
-
WebGoat comes with default configurations for Tomcat. This page will explain these configurations
-and other possible configurations for Tomcat. This is just
-a short description which should be enough in most cases. For more advanced tasks please
-refer to the Tomcat documentation. Please note that all solutions
-are written for the standard configurations on port 80 or 8080. If you use another port you have
-to adjust the solution to your configuration.
-
-
The Standard Configurations
-
WebGoat has multiple ways of being run. The
-WebGoat Wiki is the best place to find the latest configuration instructions.
-By default WebGoat will run on port 8080. In the basic configurations you use the server on your localhost.
-In Linux you have to start WebGoat as root or with sudo if you want to run it on port 80 and
- 443. Running software as root is dangerous we strongly advice to use
-the port 8080 and 8443.
-
-
-
Server Configurations
-
-If you are a single user of WebGoat the standard configurations should be
-enough but if you want to use WebGoat in laboratory or in class there
-might be the need to change the configurations. Before changing
-the configurations we recommend doing a backup of the files you change.
-
-
-
Change Ports
-
-To change the ports open Tomcat's server.xml which you find in tomcat/conf and change the
-non-SSL port. If you want to change your
-Tomcat server to use it on port 8079 for example:
-
-
-
-<!-- Define a non-SSL HTTP/1.1 Connector on port 8079 -->
-<Connector address="127.0.0.1" port="8079"...
-
-
-You can also change the SSL connector to another port of course.
-In this example to port 8442:
-
-
-<!-- Define a SSL HTTP/1.1 Connector on port 8442 -->
-<Connector address="127.0.0.1" port="8442"...
-
-
-You can also modify WebGoat's pom.xml file to change the port. You will need to modify
-the tomcat7-maven-plugin plugin configuration.
-
-
-
-
Make WebGoat Reachable From Another Client
-
THIS MAKES IT POSSIBLE TO REALLY ATTACK YOUR SERVER! DO NOT DO THIS
- UNTIL YOU KNOW WHAT YOU ARE DOING. THIS CONFIGURATION SHOULD BE ONLY USED IN
-SAFE NETWORKS!
-
By its default configuration, WebGoat is only
-reachable within the localhost. In a laboratory or a class
-there is maybe the need of having a server and a few clients.
-In this case it is possible to make WebGoat reachable.
-
-
-
Permit Only Certain Client Connection
-
-If you have made WebGoat reachable it is reachable for
-all clients. If you want to make it reachable only for certain clients specified
-by their IP you can archive this by using a 'Remote Address Filter'.
-The filter can be set in a whitebox or blackbox approach. Here is
-only discussed the whitebox approach. You have to add following lines to the
-Host section of server.xml in your Tomcat server configuration:
-
In this case only localhost, ip1 and ip2 are permitted to connect.
-
-
-
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/TraceXSS.html b/src/main/webapp/lesson_plans/English/TraceXSS.html
deleted file mode 100644
index 2358d4fc4..000000000
--- a/src/main/webapp/lesson_plans/English/TraceXSS.html
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
Lesson Plan Title: How to Perform Cross Site Tracing (XST) Attacks
-
-
Concept / Topic To Teach:
-
-It is always a good practice to scrub all input, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere in the application. Users should not be able to create message content that could cause another user to load an undesireable page or undesireable content when the user's message is retrieved.
-
General Goal(s):
-Tomcat is configured to support the HTTP TRACE command. Your goal is to perform a Cross Site Tracing (XST) attack.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/UncheckedEmail.html b/src/main/webapp/lesson_plans/English/UncheckedEmail.html
deleted file mode 100644
index db3c630e9..000000000
--- a/src/main/webapp/lesson_plans/English/UncheckedEmail.html
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
Lesson Plan Title: How to Exploit Unchecked Email
-
-
Concept / Topic To Teach:
-
-It is always a good practice to validate all inputs. Most sites allow non-authenticated users to send email to a 'friend'. This is a great mechanism for spammers to send out email using your corporate mail server.
-
-
General Goal(s):
-The user should be able to send and obnoxious email message.
diff --git a/src/main/webapp/lesson_plans/English/UsefulTools.html b/src/main/webapp/lesson_plans/English/UsefulTools.html
deleted file mode 100644
index 99bee445d..000000000
--- a/src/main/webapp/lesson_plans/English/UsefulTools.html
+++ /dev/null
@@ -1,41 +0,0 @@
-
-
-
Useful Tools
-
-Below is a list of tools we've found useful in solving the WebGoat lessons. You will need a proxy like OWASP ZAP or Paros to solve most of the lessons.
-
OWASP ZAP:
-
-Like WebGoat, Zed Attack Proxy (ZAP) is a part of OWASP and is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.
-It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.
-ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually..
After installing ZAP and configuring your browser to use it as a proxy on localhost we can start. To intercept a request,
-click the green arrow icon turning it red. If we browse a WebGoat page, ZAP will intercept the HTTP request.
-Here we can read and edit the intercepted parameters and headers. After editing is complete press the play icon to submit the request to the server.
-
-
-
Modern Browsers:
-
-Most modern browser have developer tools that will allow you to inspect and modify request data.
-
-
-
Wireshark
-
-Wireshark is a network protocol analyzer. You can sniff network traffic and gather useful
-informations this way.
-There are many vulnerability scanners for your own web applications. They can find XSS, Injection Flaws and other vulnerabilities. Below are links to three open source scanners.
-
-Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL) file.
-
General Goal(s):
-This screen is the API for a web service. Check the WSDL file for this web service and try to get some customer credit numbers.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/WeakAuthenticationCookie.html b/src/main/webapp/lesson_plans/English/WeakAuthenticationCookie.html
deleted file mode 100644
index 9c9b86c8a..000000000
--- a/src/main/webapp/lesson_plans/English/WeakAuthenticationCookie.html
+++ /dev/null
@@ -1,12 +0,0 @@
-
-
Lesson Plan Title: How to Spoof an Authentication Cookie
-
-
-
Concept / Topic To Teach:
-
-Many applications will automatically log a user into their site if the right authentication cookie is specified. Some times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. Some times the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. Some times the cookies maybe intercepted using Cross site scripting. This lesson tries to make the student aware of authentication cookies and presents the student with a way to defeat the cookie authentication method in this lesson.
-
General Goal(s):
-
- The user should be able to bypass the authentication check.
-Login using the webgoat/webgoat account to see what happens. You may also try aspect/aspect. When you understand the authentication cookie, try changing your identity to alice.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/WeakSessionID.html b/src/main/webapp/lesson_plans/English/WeakSessionID.html
deleted file mode 100644
index 45157e0b5..000000000
--- a/src/main/webapp/lesson_plans/English/WeakSessionID.html
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
Lesson Plan Title: How to Hijack a Session
-
-
Concept / Topic To Teach:
-
-Application developers who develop their own session IDs frequently forget to incorporate the complexity and randomness necessary for security. If the user specific session ID is not complex and random, then the application is highly susceptible to session-based brute force attacks.
-
General Goal(s):
-Try to access an authenticated session belonging to someone else.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/WelcomeScreeen.html b/src/main/webapp/lesson_plans/English/WelcomeScreeen.html
deleted file mode 100644
index be93e40e2..000000000
--- a/src/main/webapp/lesson_plans/English/WelcomeScreeen.html
+++ /dev/null
@@ -1,16 +0,0 @@
-
-
Lesson Plan Title:Welcome
-
-
Concept / Topic To Teach:
-This lesson presents the basics for understanding the transfer of data between the browser and the web application.
-
Standards Addressed:
-
General Goal(s):
-
Specific Objectives:
-
Required Materials:
-
Anticipatory Set (Lead-In):
-
Step-By-Step Procedures:
-
Plan For Independent Practice:
-
Closure (Reflect Anticipatory Set):
-
Assessment Based On Objectives:
-
Extensions (For Gifted Students):
-
Possible Connections To Other Subjects:
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/WsSAXInjection.html b/src/main/webapp/lesson_plans/English/WsSAXInjection.html
deleted file mode 100644
index 23a2e8607..000000000
--- a/src/main/webapp/lesson_plans/English/WsSAXInjection.html
+++ /dev/null
@@ -1,12 +0,0 @@
-
-
Lesson Plan Title: How to Perform Web Service SAX Injection
-
-
Concept / Topic To Teach:
-
-Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL) file.
-
General Goal(s):
-Some web interfaces make use of Web Services in the background. If the frontend relies on the web service for all input validation, it may be possible to corrupt the XML that the web interface sends.
-
-
-In this exercise, try to change the password for a user other than 101.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/WsSqlInjection.html b/src/main/webapp/lesson_plans/English/WsSqlInjection.html
deleted file mode 100644
index 95738b0bf..000000000
--- a/src/main/webapp/lesson_plans/English/WsSqlInjection.html
+++ /dev/null
@@ -1,9 +0,0 @@
-
-
Lesson Plan Title: How to Perform Web Service SQL Injection
-
-
Concept / Topic To Teach:
-
-Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL) file.
-
General Goal(s):
-Check the web service description language (WSDL) file and try to obtain multiple customer credit card numbers. You will not see the results returned to this screen. When you believe you have suceeded, refresh the page and look for the 'green star'.
-
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/XMLInjection.html b/src/main/webapp/lesson_plans/English/XMLInjection.html
deleted file mode 100644
index fc9c73697..000000000
--- a/src/main/webapp/lesson_plans/English/XMLInjection.html
+++ /dev/null
@@ -1,19 +0,0 @@
-
-
Lesson Plan Title: How to Perform XML Injection Attacks.
-
-
-
Concept / Topic To Teach:
- This lesson teaches how to perform XML Injection attacks.
-
-
-
-How the attacks works:
-
-AJAX applications use XML to exchange information with the server. This XML can be easily intercepted and altered by a malicious attacker.
-
-
-
General Goal(s):
-
-WebGoat-Miles Reward Miles shows all the rewards available. Once you've entered your account ID, the lesson will show you your balance and the products you can afford. Your goal is to try to add more rewards to your allowed set of rewards. Your account ID is 836239.
-
-
diff --git a/src/main/webapp/lesson_plans/English/XPATHInjection.html b/src/main/webapp/lesson_plans/English/XPATHInjection.html
deleted file mode 100644
index 926d8f151..000000000
--- a/src/main/webapp/lesson_plans/English/XPATHInjection.html
+++ /dev/null
@@ -1,22 +0,0 @@
-
-
Lesson Plan Title: How to Perform XPATH Injection Attacks.
-
-
-
Concept / Topic To Teach:
- This lesson teaches how to perform XPath Injection attacks.
-
-
-
-How the attacks works:
-
-Similar to SQL Injection, XPATH Injection attacks occur when a web site uses user supplied information to query XML data. By sending intentionally malformed information into the web site, an attacker can find out how the XML data is structured or access data that they may not normally have access to.
-They may even be able to elevate their privileges on the web site if the xml data is being used for authentication (such as an xml based user file).
-
-Querying XML is done with XPath, a type of simple descriptive statement that allows the xml query to locate a piece of information. Like SQL you can specify certain attributes to find and patterns to match. When using XML for a web site it is common to accept some form of input on the query string to identify the content to locate and display on the page. This input must be sanitized to verify that it doesn't mess up the XPath query and return the wrong data.
-
-
-
-
General Goal(s):
-
-The form below allows employees to see all their personal data including their salaries. Your account is Mike/test123. Your goal is to try to see other employees data as well.
-
diff --git a/src/main/webapp/lesson_plans/en/CSRF.html b/src/main/webapp/lesson_plans/en/CSRF.html
index dc17ddef9..594d049bd 100644
--- a/src/main/webapp/lesson_plans/en/CSRF.html
+++ b/src/main/webapp/lesson_plans/en/CSRF.html
@@ -21,6 +21,6 @@ In this way, the attacker can make the victim perform actions that they didn't i
General Goal(s):
-Your goal is to send an email to a newsgroup that contains an image whose URL is pointing to a malicious request. Try to include a 1x1 pixel image that includes a URL. The URL should point to the CSRF lesson with an extra parameter "transferFunds=4000". You can copy the shortcut from the left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever receives this email and happens to be authenticated at that time will have his funds transferred. When you think the attack is successful, refresh the page and you will find the green check on the left hand side menu.
+Your goal is to send an email to a newsgroup that contains an image whose URL is pointing to a malicious request. Try to include a 1x1 pixel image that includes a URL. The URL should point to the CSRF lesson with an extra parameter "transferFunds=4000". You can copy the shortcut from the left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever receives this email and happens to be authenticated at that time will have his funds transferred. When you think the attack is successful, refresh the page and you will find the green check on the left hand side menu. Note that the "Screen" and "menu" GET variables will vary between WebGoat builds. Copying the menu link on the left will give you the current values.
diff --git a/src/main/webapp/lesson_plans/en/CsrfPromptByPass.html b/src/main/webapp/lesson_plans/en/CsrfPromptByPass.html
index a5b524be2..7a505f2ac 100644
--- a/src/main/webapp/lesson_plans/en/CsrfPromptByPass.html
+++ b/src/main/webapp/lesson_plans/en/CsrfPromptByPass.html
@@ -27,6 +27,7 @@ parameter "transferFunds=4000", and "transferFunds=CONFIRM". You can copy the sh
left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever
receives this email and happens to be authenticated at that time will have his funds transferred.
When you think the attack is successful, refresh the page and you will find the green check on
-the left hand side menu.
+the left hand side menu.
+Note that the "Screen" and "menu" GET variables will vary between WebGoat builds. Copying the menu link on the left will give you the current values.
diff --git a/src/main/webapp/lesson_plans/en/CsrfTokenByPass.html b/src/main/webapp/lesson_plans/en/CsrfTokenByPass.html
index b0cbe426d..b57ea6b83 100644
--- a/src/main/webapp/lesson_plans/en/CsrfTokenByPass.html
+++ b/src/main/webapp/lesson_plans/en/CsrfTokenByPass.html
@@ -31,7 +31,8 @@ request to transfer funds. To successfully complete you need to obtain a valid
The page that presents the transfer funds form contains a valid request token. The URL for the
transfer funds page is the same as this lesson with an extra parameter "transferFunds=main". Load
this page, read the token and append the token in a forged request to transferFunds. When you think
-the attack is successful, refresh the page and you will find the green check on the left hand side menu.
+the attack is successful, refresh the page and you will find the green check on the left hand side menu.
+Note that the "Screen" and "menu" GET variables will vary between WebGoat builds. Copying the menu link on the left will give you the current values.
diff --git a/src/main/webapp/lesson_plans/en/HowToWork.html b/src/main/webapp/lesson_plans/en/HowToWork.html
index 94cb85851..d99f61dc2 100644
--- a/src/main/webapp/lesson_plans/en/HowToWork.html
+++ b/src/main/webapp/lesson_plans/en/HowToWork.html
@@ -1,49 +1,68 @@
How To Work With WebGoat
-Welcome to a short introduction to WebGoat.
-Here you will learn how to use WebGoat and additional tools for the lessons.
+Welcome to a brief overview of WebGoat.
Environment Information
-WebGoat uses the Apache Tomcat server. It is configured to run on localhost although this can be
-easily changed. This
-configuration is for single user, additional users can be added in the tomcat-users.xml file.
-If you want to use WebGoat in a laboratory or in
-class you might need to change this setup. Please refer to the Tomcat Configuration
-in the Introduction section.
+WebGoat uses the Apache Tomcat server but can run in any application server. It is configured to run on
+localhost although this can be easily changed, see the "Tomcat Configuration" section in the Introduction.
The WebGoat Interface
-
-1. These are Lesson Categories in WebGoat. Click on a Category to see all Lessons in it.
-2. This will show technical hints to solve the lesson.
-3. This will show the HTTP Request Parameters
-4. This will show the HTTP Request Cookies
-5. This will show goals and objectives of the lesson.
-6. This will show the underlying Java source code.
-7. This will show the complete solution of the selected lesson.
-8. If you want to restart a lesson you can use this link.
+
+1. Lesson Categories in WebGoat. Click on a Category to see specific Lessons.
+2. This will show the underlying Java source code.
+3. This will show the complete solution of the selected lesson.
+4. This will show goals and objectives of the lesson.
+5. This will show technical hints to solve the lesson.
+6. This shows the HTTP request data
+7. If you want to restart a lesson you can use this link.
Solve The Lesson
-Always start with the lessons plan. Then try to solve the lesson and if necessary,
+Always start with the lesson plan. Then try to solve the lesson and if necessary,
use the hints. The last hint is the solution text if applicable. If you cannot solve the lesson using the hints, you may view the
solution for complete details.
-
Read And Edit Parameters
+
+
Read And Edit Parameters/Cookies
-To read and edit Parameters you need a local proxy to intercept the HTTP request.
-Here we use WebScarab. More information on WebScarab can be found in the "Useful Tools" Chapter.
-After installing WebScarab and configuring your browser to use it as proxy on localhost we can start.
-
-We have to select "Intercept Request" in the tab "Intercept". If we send a HTTP request we get a new WebScarab window.
-
-Here we can read and edit the intercepted parameter. After "Accept changes" the request will be sent to the server.
+To read and edit parameters and cookies you need a local proxy like OWASP ZAP to intercept the HTTP request.
+ More information on ZAP can be found in the "Useful Tools" section in the Introduction.
-
Read And Edit Cookies
+
+
Configuring new WebGoat users
-Often it is not only necessary to change the value of the parameters but to change the value of cookies.
-We can use WebScarab to intercept the request and change cookies values just like parameter data as explained in the last topic.
-
-We get a new window on sending a HTTP request. On the screenshot you see where we can find cookies and how to edit the values of them.
+WebGoat uses spring-security.xml to configure users.
+
+
+Usually WebGoat only requires logging in with the user:guest and password:guest.
+ But maybe in laboratory you have made a setup with one server and a lot of
+clients. In this case you might want to have a user for every client,
+ you will have to alter /WEB-INF/spring-security.xml to add additional users. We recommend not to use real passwords
+as the passwords are stored in plain text in this file!
+
+
Adding a new User
+
+Adding a user is straight forward. You can use the guest entry as an example. The added
+users should have the same role as the guest user. The new user/password will not show on the login page.
+Add lines like this to the /WEB-INF/spring-security.xml file:
+
-All HTTP transactions follow the same general format. Each client request and server response has three parts: the request or response line, a header section, and the entity body. The client initiates a transaction as follows:
+All HTTP transactions follow the same general format. Each client request and server response has three parts: the request or response line, a header section and the entity body. The client initiates a transaction as follows:
The client contacts the server and sends a document request
@@ -20,8 +20,8 @@ All HTTP transactions follow the same general format. Each client request and se
After sending the request and headers, the client may send additional data. This data is mostly used by CGI programs using the POST method.
General Goal(s):
-Enter your name in the input field below and press "go" to submit. The server will accept the request, reverse the input, and display it back to the user, illustrating the basics of handling an HTTP request.
+Enter your name in the input field below and press "Go!" to submit. The server will accept the request, reverse the input and display it back to the user, illustrating the basics of handling an HTTP request.
The user should become familiar with the features of WebGoat by manipulating the above
-buttons to view hints, show the HTTP request parameters, the HTTP request cookies, and the Java source code. You may also try using WebScarab for the first time.
+buttons to view hints, show the HTTP request parameters, the HTTP request cookies, and the Java source code. You may also try using OWASP Zed Attack Proxy for the first time.
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/English/OffByOne.html b/src/main/webapp/lesson_plans/en/OffByOne.html
similarity index 98%
rename from src/main/webapp/lesson_plans/English/OffByOne.html
rename to src/main/webapp/lesson_plans/en/OffByOne.html
index 53bd06d01..b35b95996 100644
--- a/src/main/webapp/lesson_plans/English/OffByOne.html
+++ b/src/main/webapp/lesson_plans/en/OffByOne.html
@@ -1,21 +1,21 @@
-
-
Lesson Plan Title: How to Exploit "Off-by-One" Buffer Overflow Vulnerabilities
-
-
Concept / Topic To Teach:
-How to Exploit a Web Based "Off-by-One" Buffer Overflow.
-
-
-
How the attack works:
-
-Despite being more rare, buffer overflow vulnerabilities on the web occur when a tier of the application has insufficient memory allocated to deal with the data submitted by the user. Typically, such a tier would be written in C or a similar language.
-
-For the particular subset, namely, off-by-one overflows, this lesson focuses on the consequences of being able to overwrite the position for the trailing null byte.
-
-As a result, further information is returned back to the user, due to the fact that no null byte was found.
-
-
Lesson Goal(s):
-
-
Welcome to the OWASP Hotel! Can you find out which room a VIP guest is staying in?
-
-* Understand how a buffer overflow vulnerability can be triggered on a web application.
+
+
Lesson Plan Title: How to Exploit "Off-by-One" Buffer Overflow Vulnerabilities
+
+
Concept / Topic To Teach:
+How to Exploit a Web Based "Off-by-One" Buffer Overflow.
+
+
+
How the attack works:
+
+Despite being more rare, buffer overflow vulnerabilities on the web occur when a tier of the application has insufficient memory allocated to deal with the data submitted by the user. Typically, such a tier would be written in C or a similar language.
+
+For the particular subset, namely, off-by-one overflows, this lesson focuses on the consequences of being able to overwrite the position for the trailing null byte.
+
+As a result, further information is returned back to the user, due to the fact that no null byte was found.
+
+
Lesson Goal(s):
+
+
Welcome to the OWASP Hotel! Can you find out which room a VIP guest is staying in?
+
+* Understand how a buffer overflow vulnerability can be triggered on a web application.
* Understand what type of value lengths are likely to trigger a buffer overflow.
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/en/PasswordStrength.html b/src/main/webapp/lesson_plans/en/PasswordStrength.html
index e53f5170d..f700fb8fd 100644
--- a/src/main/webapp/lesson_plans/en/PasswordStrength.html
+++ b/src/main/webapp/lesson_plans/en/PasswordStrength.html
@@ -3,8 +3,9 @@
Concept / Topic To Teach:
-Accounts are only as secure as their passwords. Most users have the same weak password everywhere. If you want to protect them against brute-force-attacks your application should have good requirements for passwords. The password should contain lower case letters, capitals and numbers. The longer the password, the sbetter.
+Accounts are only as secure as their passwords. Most users have the same weak password everywhere. If you want to protect them against brute-force-attacks your application should have good requirements for passwords. The password should contain lower case letters, capitals, numbers and special characters. The longer the password, the better, consider using a passphrase instead. For
+more information see: OWASP proper password strength.
-
+
General Goal(s):
For this exercise, your job is to test several passwords on https://howsecureismypassword.net/
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/en/SoapRequest.html b/src/main/webapp/lesson_plans/en/SoapRequest.html
index 1b7b6b0e4..b96226617 100644
--- a/src/main/webapp/lesson_plans/en/SoapRequest.html
+++ b/src/main/webapp/lesson_plans/en/SoapRequest.html
@@ -5,5 +5,5 @@
Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL). Let's learn something about WSDL files. Check out WebGoat's web service description language (WSDL) file.
General Goal(s):
-Try connecting to the WSDL with a browser or Web Service tool. The URL for the web service is: http://localhost/WebGoat/services/SoapRequest The WSDL can usually be viewed by adding a ?WSDL on the end of the web service request.
+Try connecting to the WSDL with a browser or Web Service tool. The URL for the web service is: http://localhost/WebGoat/services/SoapRequest The WSDL can usually be viewed by adding a ?WSDL on the end of the web service request. You must access 2 of the operations to pass this lesson.
\ No newline at end of file
diff --git a/src/main/webapp/lesson_plans/en/TomcatSetup.html b/src/main/webapp/lesson_plans/en/TomcatSetup.html
index 2f33d253c..decbd49df 100644
--- a/src/main/webapp/lesson_plans/en/TomcatSetup.html
+++ b/src/main/webapp/lesson_plans/en/TomcatSetup.html
@@ -5,20 +5,16 @@
and other possible configurations for Tomcat. This is just
a short description which should be enough in most cases. For more advanced tasks please
refer to the Tomcat documentation. Please note that all solutions
-are written for the standard configurations on port 80. If you use another port you have
+are written for the standard configurations on port 80 or 8080. If you use another port you have
to adjust the solution to your configuration.
The Standard Configurations
-
There are two standard Tomcat configurations. In the basic configurations you use the server on your localhost.
- Both are identically with the only difference
- that in one tomcat is running on port 80 and 443 (SSL) and in the other tomcat is running on port 8080 and 8443. In Linux you have
- to start WebGoat as root or with sudo if you want to run it on port 80 and
- 443.
- As running software as root is dangerous we strongly advice to use
-the port 8080 and 8443. In Windows you can
-run WebGoat.bat to run it on port 80 and WebGoat_8080.bat to run it on port 8080. In Linux you
-can use webgoat.sh and run it with webgoat.sh start80 or webgoat.sh start8080. The user in these
-configurations is guest with password guest
+
WebGoat has multiple ways of being run. The
+WebGoat Wiki is the best place to find the latest configuration instructions.
+By default WebGoat will run on port 8080. In the basic configurations you use the server on your localhost.
+In Linux you have to start WebGoat as root or with sudo if you want to run it on port 80 and
+ 443. Running software as root is dangerous we strongly advice to use
+the port 8080 and 8443.
Server Configurations
@@ -31,46 +27,47 @@ the configurations we recommend doing a backup of the files you change.
Change Ports
-To change the ports open the server_80.xml which you find in tomcat/conf and change the
-non-SSL port. If you want to use it on port 8079 for example:
+To change the ports open Tomcat's server.xml which you find in tomcat/conf and change the
+non-SSL port. If you want to change your
+Tomcat server to use it on port 8079 for example:
- <!-- Define a non-SSL HTTP/1.1 Connector on port 8079 -->
- <Connector address="127.0.0.1" port="8079"...
+<!-- Define a non-SSL HTTP/1.1 Connector on port 8079 -->
+<Connector address="127.0.0.1" port="8079"...
You can also change the SSL connector to another port of course.
In this example to port 8442:
- <!-- Define a SSL HTTP/1.1 Connector on port 8442 -->
- <Connector address="127.0.0.1" port="8442"...
+<!-- Define a SSL HTTP/1.1 Connector on port 8442 -->
+<Connector address="127.0.0.1" port="8442"...
+
+You can also modify WebGoat's pom.xml file to change the port. You will need to modify
+the tomcat7-maven-plugin plugin configuration.
+
Make WebGoat Reachable From Another Client
THIS MAKES IT POSSIBLE TO REALLY ATTACK YOUR SERVER! DO NOT DO THIS
UNTIL YOU KNOW WHAT YOU ARE DOING. THIS CONFIGURATION SHOULD BE ONLY USED IN
SAFE NETWORKS!
-
By its default configurations WebGoat is only
+
By its default configuration, WebGoat is only
reachable within the localhost. In a laboratory or a class
there is maybe the need of having a server and a few clients.
In this case it is possible to make WebGoat reachable.
-
The reason why WebGoat is only reachable within the localhost is
-the parameter address in the connectors for the non-SSL and SSL connection in server_80.xml. It is set
-to 127.0.0.1. The applications only listens on the port of this address for
-incoming connections if it is set. If you remove this parameter the server listens on all IPs on the
-specific port.
-
Permit Only Certain Clients Connection
+
Permit Only Certain Client Connection
If you have made WebGoat reachable it is reachable for
all clients. If you want to make it reachable only for certain clients specified
-by there IP you can archive this by using a 'Remote Address Filter'.
+by their IP you can archive this by using a 'Remote Address Filter'.
The filter can be set in a whitebox or blackbox approach. Here is
-only discussed the whitebox approach. You have to add following lines to the Host section of web_80.xml:
+only discussed the whitebox approach. You have to add following lines to the
+Host section of server.xml in your Tomcat server configuration:
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
@@ -78,37 +75,6 @@ only discussed the whitebox approach. You have to add following lines to the Hos
In this case only localhost, ip1 and ip2 are permitted to connect.
-
WebGoat Default Users and Roles for Tomcat
-
-WebGoat requires the following users and roles to be configured in order for the application to run.
-
-
-Usually using WebGoat you just use the user guest with the password guest.
-But maybe in laboratory you have made a setup with one server and a lot of
-clients. In this case you might want to have a user for every client
- and you have to alter tomcat-users.xml
-in tomcat/conf as the users are stored there. We recommend not to use real passwords
-as the passwords are stored in plain text in this file!
-
-
Add User
-
-Adding a user is straight forward. You can use the guest entry as an example. The added
-users should have the same role as the guest user. Add lines like this to the file:
-
WebGoat is a demonstration of common web application flaws. The
+ associated exercises are intended to provide hands-on experience with
+ techniques aimed at demonstrating and testing application penetration.
+
+
From the entire WebGoat team, we appreciate your interest and efforts
+ in making applications not just better, but safer and more secure for
+ everyone. We, as well as our sacrificial goat, thank you.
+
+ Version: ${version}, Build: ${build}
+
-
-
-
-
Thank you for using WebGoat! This program is a demonstration of common web application flaws.
-The exercises are intended to provide hands on experience with
-application penetration testing techniques.
-
The WebGoat project is led
-by Bruce Mayhew. Please send all comments to Bruce at <%=webSession.getWebgoatContext().getFeedbackAddress()%>.
Did we miss you? Our sincere apologies, as we know there have
+ been many contributors over the years. If your name does not
+ appear in any of the lists above, please send us a note. We'll
+ get you added with no further sacrifices required.
+
+
+
+
-
-
-
-
-
WARNING
-While running this program, your machine is extremely vulnerable to
-attack if you are not running on localhost. If you are NOT running on localhost (default configuration), You should disconnect from the network while using this program.
-
-
-This program is for educational purposes only. Use of these techniques
-without permission could lead to job termination, financial liability,
-and/or criminal penalties.