dubey/WebGoat
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Copied changes from English to en if newer

Browse Source
This commit is contained in:
nbaars 2014-09-18 20:50:15 +02:00
parent b2dcb85b13
commit c0e8c06189
9 changed files with 107 additions and 98 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/main/webapp/lesson_plans/en/CSRF.html
View File

@ -21,6 +21,6 @@ In this way, the attacker can make the victim perform actions that they didn't i
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
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.<br/><b>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.</b>
<!-- Stop Instructions -->

3
src/main/webapp/lesson_plans/en/CsrfPromptByPass.html
View File

@ -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.<br/>
<b>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.</b>
<!-- Stop Instructions -->

3
src/main/webapp/lesson_plans/en/CsrfTokenByPass.html
View File

@ -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.<br/>
<b>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.</b>
<!-- Stop Instructions -->

81
src/main/webapp/lesson_plans/en/HowToWork.html
View File

@ -1,49 +1,68 @@
<!-- Start Instructions -->
<h1>How To Work With WebGoat</h1>
<p>
Welcome to a short introduction to WebGoat.<br>
Here you will learn how to use WebGoat and additional tools for the lessons.<br><br>
Welcome to a brief overview of WebGoat.<br>
</p>
<h2>Environment Information</h2>
<p>
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.</p>
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. </p>
<h2>The WebGoat Interface</h2>
<p>
<img src="images/introduction/interface.jpg"><br><br>
1. These are Lesson Categories in WebGoat. Click on a Category to see all Lessons in it.<br>
2. This will show technical hints to solve the lesson.<br>
3. This will show the HTTP Request Parameters<br>
4. This will show the HTTP Request Cookies<br>
5. This will show goals and objectives of the lesson.<br>
6. This will show the underlying Java source code.<br>
7. This will show the complete solution of the selected lesson.<br>
8. If you want to restart a lesson you can use this link.</p>
<img src="images/introduction/interface.png"><br><br>
1. Lesson Categories in WebGoat. Click on a Category to see specific Lessons.<br>
2. This will show the underlying Java source code.<br>
3. This will show the complete solution of the selected lesson.<br>
4. This will show goals and objectives of the lesson.<br>
5. This will show technical hints to solve the lesson.<br>
6. This shows the HTTP request data<br>
7. If you want to restart a lesson you can use this link.</p>
<h2>Solve The Lesson</h2>
<p>
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.</p>
<h2>Read And Edit Parameters</h2>
<h2>Read And Edit Parameters/Cookies</h2>
<p>
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.<br><br>
<img src="images/introduction/HowToUse_1.jpg"><br><br>
We have to select "Intercept Request" in the tab "Intercept". If we send a HTTP request we get a new WebScarab window.<br><br>
<img src="images/introduction/HowToUse_2.jpg"><br><br>
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.
</p>
<h2>Read And Edit Cookies</h2>
<h2>Configuring new WebGoat users</h2>
<p>
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.<br><br>
<img src="images/introduction/HowToUse_3.jpg"><br><br>
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.
<br/>
<pre>
&lt;!-- Authentication Manager --&gt;
&lt;authentication-manager alias="authenticationManager"&gt;
&lt;authentication-provider&gt;
&lt;user-service&gt;
&lt;user name="guest" password="guest" authorities="ROLE_WEBGOAT_USER" /&gt;
&lt;user name="webgoat" password="webgoat" authorities="ROLE_WEBGOAT_ADMIN" /&gt;
&lt;user name="server" password="server" authorities="ROLE_SERVER_ADMIN" /&gt;
&lt;/user-service&gt;
&lt;/authentication-provider&gt;
&lt;/authentication-manager&gt;
</pre>
</p>
<h2>Adding Users</h2>
<p>
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. <b>We recommend not to use real passwords
as the passwords are stored in plain text in this file!</b>
</p>
<h3>Adding a new User</h3>
<p>
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:
</p>
<pre>
&lt;user name="guest2" password="guest2" authorities="ROLE_WEBGOAT_USER" /&gt;
...
</pre>
<!-- Stop Instructions -->

6
src/main/webapp/lesson_plans/en/HttpBasics.html
View File

@ -8,7 +8,7 @@
<p>
<b>How HTTP works:</b>
</p>
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: <br>
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: <br>
<br>
The client contacts the server and sends a document request <br>
</div>
@ -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.<br>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
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.
<br/><br/>
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.
<!-- Stop Instructions -->

21
src/main/webapp/lesson_plans/en/OffByOne.html Normal file
View File

@ -0,0 +1,21 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Exploit "Off-by-One" Buffer Overflow Vulnerabilities</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
How to Exploit a Web Based "Off-by-One" Buffer Overflow.
<br>
<div align="Left">
<p><b>How the attack works:</b>
</p>
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.
</div>
<p><b>Lesson Goal(s):</b> </p>
<!-- Start Instructions -->
<p>Welcome to the <b>OWASP Hotel</b>! Can you find out which room a VIP guest is staying in?</p>
<!-- Stop Instructions -->
* Understand how a buffer overflow vulnerability can be triggered on a web application.<br>
* Understand what type of value lengths are likely to trigger a buffer overflow.<br>

5
src/main/webapp/lesson_plans/en/PasswordStrength.html
View File

@ -3,8 +3,9 @@
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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: <a href="https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls" target="_blank">OWASP proper password strength</a>.
<!-- Stop Instructions -->
<br>
<br/><br/>
<p><b>General Goal(s):</b> </p>
For this exercise, your job is to test several passwords on <a href="https://howsecureismypassword.net/" target="_blank">https://howsecureismypassword.net/</a>

2
src/main/webapp/lesson_plans/en/SoapRequest.html
View File

@ -5,5 +5,5 @@
<!-- Start Instructions -->
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.
<p><b>General Goal(s):</b> </p>
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.
<!-- Stop Instructions -->

74
src/main/webapp/lesson_plans/en/TomcatSetup.html
View File

@ -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.</p>
<h2>The Standard Configurations</h2>
<p>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
<p>WebGoat has multiple ways of being run. The <a href="https://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0)">
WebGoat Wiki</a> 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.
</p>
<h2>Server Configurations</h2>
@ -31,8 +27,9 @@ the configurations we recommend doing a backup of the files you change.
<h3>Change Ports</h3>
<p>
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:
</p>
<pre>
@ -47,30 +44,30 @@ In this example to port 8442:
&lt;!-- Define a SSL HTTP/1.1 Connector on port 8442 --&gt;
&lt;Connector address=&quot;127.0.0.1&quot; port=&quot;8442&quot;...
</pre>
</p>
You can also modify WebGoat's pom.xml file to change the port. You will need to modify
the tomcat7-maven-plugin plugin configuration.
</p>
<br>
<h3>Make WebGoat Reachable From Another Client</h3>
<p>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!</p>
<p>By its default configurations WebGoat is only
<p>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.
</p>
<p>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.</p>
<h3>Permit Only Certain Clients Connection</h3>
<h3>Permit Only Certain Client Connection</h3>
<p>
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:
</p>
<pre>
&lt;Valve className=&quot;org.apache.catalina.valves.RemoteAddrValve&quot;
@ -78,37 +75,6 @@ only discussed the whitebox approach. You have to add following lines to the Hos
</pre>
<p>In this case only localhost, ip1 and ip2 are permitted to connect.</p>
<h2>WebGoat Default Users and Roles for Tomcat</h2>
<p>
WebGoat requires the following users and roles to be configured in order for the application to run.
<br/>
<pre>
&gt;role rolename="webgoat_basic"/&lt;
&gt;role rolename="webgoat_admin"/&lt;
&gt;role rolename="webgoat_user"/&lt;
&gt;user username="webgoat" password="webgoat" roles="webgoat_admin"/&lt;
&gt;user username="basic" password="basic" roles="webgoat_user,webgoat_basic"/&lt;
&gt;user username="guest" password="guest" roles="webgoat_user"/&lt;
</pre>
</p>
<h2>Adding Users</h2>
<p>
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. <b>We recommend not to use real passwords
as the passwords are stored in plain text in this file!</b>
</p>
<h3>Add User</h3>
<p>
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:
</p>
<pre>
&lt;user name=&quot;student1&quot; password=&quot;password1&quot; roles=&quot;webgoat_user&quot;/&gt;
&lt;user name=&quot;student2&quot; password=&quot;password2&quot; roles=&quot;webgoat_user&quot;/&gt;
...
</pre>
<!-- Stop Instructions -->