From c0e8c06189c543f821c7614133df13d4845d2d23 Mon Sep 17 00:00:00 2001 From: nbaars Date: Thu, 18 Sep 2014 20:50:15 +0200 Subject: [PATCH] Copied changes from English to en if newer --- src/main/webapp/lesson_plans/en/CSRF.html | 2 +- .../lesson_plans/en/CsrfPromptByPass.html | 3 +- .../lesson_plans/en/CsrfTokenByPass.html | 3 +- .../webapp/lesson_plans/en/HowToWork.html | 81 +++++++++++------- .../webapp/lesson_plans/en/HttpBasics.html | 6 +- src/main/webapp/lesson_plans/en/OffByOne.html | 21 +++++ .../lesson_plans/en/PasswordStrength.html | 5 +- .../webapp/lesson_plans/en/SoapRequest.html | 2 +- .../webapp/lesson_plans/en/TomcatSetup.html | 82 ++++++------------- 9 files changed, 107 insertions(+), 98 deletions(-) create mode 100644 src/main/webapp/lesson_plans/en/OffByOne.html 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. +
+ 

+<!-- Authentication Manager -->
+<authentication-manager alias="authenticationManager">
+  <authentication-provider>
+    <user-service>
+      <user name="guest" password="guest" authorities="ROLE_WEBGOAT_USER" />
+      <user name="webgoat" password="webgoat" authorities="ROLE_WEBGOAT_ADMIN" />
+      <user name="server" password="server" authorities="ROLE_SERVER_ADMIN" />
+    </user-service>
+  </authentication-provider>
+</authentication-manager>  
+

+

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: +

+
+<user name="guest2" password="guest2" authorities="ROLE_WEBGOAT_USER" />
+...
+
diff --git a/src/main/webapp/lesson_plans/en/HttpBasics.html b/src/main/webapp/lesson_plans/en/HttpBasics.html index 011fed218..f3321f295 100644 --- a/src/main/webapp/lesson_plans/en/HttpBasics.html +++ b/src/main/webapp/lesson_plans/en/HttpBasics.html @@ -8,7 +8,7 @@

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:
+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/en/OffByOne.html b/src/main/webapp/lesson_plans/en/OffByOne.html new file mode 100644 index 000000000..b35b95996 --- /dev/null +++ b/src/main/webapp/lesson_plans/en/OffByOne.html @@ -0,0 +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.
+* 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. -
- 

-  >role rolename="webgoat_basic"/<
-  >role rolename="webgoat_admin"/<
-  >role rolename="webgoat_user"/<
-  >user username="webgoat" password="webgoat" roles="webgoat_admin"/<
-  >user username="basic" password="basic" roles="webgoat_user,webgoat_basic"/<
-  >user username="guest" password="guest" roles="webgoat_user"/<
-
-

-

Adding Users

-

-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: -

-
-	<user name="student1" password="password1" roles="webgoat_user"/>
-	<user name="student2" password="password2" roles="webgoat_user"/>
-	...
-
+ \ No newline at end of file