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

Miscellaneous bug fixes

Browse Source 
divide by zero, inaccurate discount and totals, reflection of user input


git-svn-id: http://webgoat.googlecode.com/svn/trunk/webgoat@273 4033779f-a91e-0410-96ef-6bf7bf53c507
This commit is contained in:
rogan.dawes
2008-01-14 14:02:11 +00:00
commit b0b94c4688
917 changed files with 73689 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
main/project/WebContent/lesson_plans/AccessControlMatrix.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Using an Access Control Matrix</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
In a 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 scheme 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 allow privilege escalation to an unauthorized role.
<p><b>General Goal(s):</b> </p>
Each user is a member of a role that is allowed to access only certain resources. Your goal is to explore the access control rules that govern this site. Only the [Admin] group should have access to the 'Account Manager' resource.
<!-- Stop Instructions -->

23
main/project/WebContent/lesson_plans/BackDoors.html Normal file
View File

@ -0,0 +1,23 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Create Database Back Door Attacks.</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
How to Create Database Back Door Attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
Databases are used usually as a backend for web applications. Also it is used as a media of storage. It can also
be used as a place to store a malicious activity such as a trigger. A trigger is called by the database management
system upon the execution of another database operation like insert, select, update or delete. An attacker for example
can create a trigger that would set his email address instead of every new user's email address.
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
* Your goal should be to learn how you can exploit a vulnerable query to create a trigger.<br>
* You will not be able to actually create one in this lesson because the underlying database engine used with WebGoat doesn't support triggers.<br>
* Your login ID is 101.
<!-- Stop Instructions -->

9
main/project/WebContent/lesson_plans/BasicAuthentication.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Basic Authentication </p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
Basic Authentication is used to protect server side resources. The web server will send a 401 authentication request with the response for the requested resource. The client side browser will then prompt the user for a user name and password using a browser supplied dialog box. The browser will base64 encode the user name and password and send those credentials back to the web server. The web server will then validate the credentials and return the requested resource if the credentials are correct. These credentials are automatically resent for each page protected with this mechanism without requiring the user to enter their credentials again.<br/>
<p><b>General Goal(s):</b></p>
For this lesson, your goal is to understand Basic Authentication and answer the questions below.
<!-- Stop Instructions -->

15
main/project/WebContent/lesson_plans/BlindSqlInjection.html Normal file
View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Blind SQL Injection </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<br>
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can be almost totally prevented. This lesson will show the student several examples of SQL injection.<br>
<br>
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries.<br>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The form below allows a user to enter an account number and determine if it is valid or not. Use this form to develop a true / false test check other entries in the database.<br><br>Reference Ascii Values: 'A' = 65 'Z' = 90 'a' = 97 'z' = 122<br><br>The goal is to find the value of the first_name in table user_data for userid 15613. Put that name in the form to pass the lesson.

9
main/project/WebContent/lesson_plans/BufferOverflow.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Exploit Buffer Overflows</p>
</div>
<!-- Start Instructions -->
<p><b>Concept / Topic To Teach:</b> </p>
How to Exploit Buffer Overflows.
<p><b>General Goal(s):</b> </p>
This lesson needs a creator!
<!-- Stop Instructions -->

26
main/project/WebContent/lesson_plans/CSRF.html Normal file
View File

@ -0,0 +1,26 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Request Forgery. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform Cross Site Request Forgery (CSRF) attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into loading a page that contains img links like the one below:
<pre>&lt;img src="<a href="http://www.mybank.com/transferFunds.do?acctId=123456" class='external free' title="http://www.mybank.com/transferFunds.do?acctId=123456" rel="nofollow">http://www.mybank.com/sendFunds.do?acctId=123456</a>"/&gt;</pre>
When the victim's browser attempts to render this page, it will issue a request to www.mybank.com to the transferFunds.do page with the specified parameters. The browser will think the link is to get an image, even though it actually is a funds transfer function.
The request will include any cookies associated with the site. Therefore, if the user has authenticated to the site, and has either a permanent cookie or even a current session cookie, the site will have no way to distinguish this from a legitimate user request.
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, or any other function provided by the vulnerable website
</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.
<!-- Stop Instructions -->

7
main/project/WebContent/lesson_plans/ChallengeScreen.html Normal file
View File

@ -0,0 +1,7 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Putting it all together </p>
</div><br/>
<p><b>Concept / Topic To Teach:</b></p>
This lesson creates a challenge that will help the student apply all that they have learned.<br/>
<b>General Goal(s):</b><br/>
Display the secret message.

12
main/project/WebContent/lesson_plans/ClientSideFiltering.html Normal file
View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>Client Side Filtering</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
It is always a good practice to send to the client only information which they are supposed
to have access to. In this lesson, too much information is being sent to the client, creating
a serious access control problem.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
For this exercise, your mission is exploit the extraneous information being returned by the
server to discover information to which you should not have access.

15
main/project/WebContent/lesson_plans/ClientSideValidation.html Normal file
View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>Insecure Client Storage</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
It is always a good practice to validate all input on the server side. Leaving the
mechanism for validation on the client side leaves it vulnerable to reverse
engineering. Remember, anything on the client side should not be
considered a secret.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
For this exercise, your mission is to discover a coupon code to receive an unintended
discount. Then, exploit the use of client side validation to submit an order with a
cost of zero.

11
main/project/WebContent/lesson_plans/CommandInjection.html Normal file
View File

@ -0,0 +1,11 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Command Injection</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
Command&nbsp; injection attacks represent a serious threat to any parameter-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.<br/>
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can be almost totally prevented. This lesson will show the student several examples of parameter injection.<br/>
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries.<br/>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
The user should be able to execute any command on the hosting OS.

22
main/project/WebContent/lesson_plans/ConcurrencyCart.html Normal file
View File

@ -0,0 +1,22 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Lesson Plan</title>
</head>
<body>
<div align="Center">
<p><b>Lesson Plan Title:</b> Shopping Cart Concurrency Flaw </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web applications can handle many HTTP requests simultaneously. Developers often use variables that are not thread safe. &nbsp;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. <br>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
For this exercise, your mission is to exploit the concurrency issue which will allow you to purchase merchandise for a lower price.
<br>
</body>
</html>

12
main/project/WebContent/lesson_plans/CrossSiteScripting.html Normal file
View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
It is always a good practice to scrub all inputs, 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. Users should not be able to create message content that could cause another user to load an undesirable page or undesirable content when the user's message is retrieved.<br>
XSS can also 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.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
For this exercise, you will perform stored and reflected XSS attacks. You will also implement code changes in the web application to defeat these attacks.
<br>

24
main/project/WebContent/lesson_plans/DBCrossSiteScripting.html Executable file
View File

@ -0,0 +1,24 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting
(XSS)</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
It is always a good practice to scrub all inputs, 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. Users should not be able to create
message content that could cause another user to load an undesirable
page or undesirable content when the user's message is retrieved.
<br>
XSS can also 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.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
For this exercise, you will perform a stored XSS attack.
You will also implement code changes in the database to defeat
these attacks.
<br>

16
main/project/WebContent/lesson_plans/DBSQLInjection.html Executable file
View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform SQL Injection</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
It is always a good practice to scrub all inputs, especially those
inputs that will later be used as parameters to OS commands, scripts,
and database queries. Users should not be able to alter the intent of
commands that are executed on the server, in many cases as a privileged user.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
For this exercise, you will perform a SQL Injection attack.
You will also implement code changes in the database to defeat
these attacks.
<br>

23
main/project/WebContent/lesson_plans/DOMInjection.html Normal file
View File

@ -0,0 +1,23 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform DOM Injection Attack. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
How to perform DOM injection attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
Some applications specially the ones that uses AJAX manipulates and updates the DOM
directly using javascript, DHTML and eval() method.<br>
An attacker may take advantage of that by intercepting the reply and try to inject some
javascript commands to exploit his attacks.
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
* Your victim is a system that takes an activation key to allow you to use it.<br>
* Your goal should be to try to get to enable the activate button.<br>
* Take some time to see the HTML source in order to understand how the key validation process works.<br>
<!-- Stop Instructions -->

15
main/project/WebContent/lesson_plans/DOMXSS.html Normal file
View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>DOM Based Cross Site Scripting (XSS)</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
The Document Object Model (DOM) presents an interesting problem from
a security standpoint. It allows the content of a web page to be dynamically
modified, but that can be abused by attackers during a malicious code injection. XSS,
a type of malicious code injection, can occur when unvalidated user input is used directly
to modify the content of a page on the client side.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
For this exercise, your mission is to use this vulnerability to inject
malicious code into the DOM. Then in the last stage, you will correct
the flaws in the code to address the vulnerability.

9
main/project/WebContent/lesson_plans/DOS_Login.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Denial of Service from Multiple Logins</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Denial of service attacks are a major issue in web applications. If the end user cannot conduct business or perform the service offered by the web application, then both time and money is wasted.
<p><b>General Goal(s):</b> </p>
This site allows a user to login multiple times. This site has a database connection pool that allows 2 connections. You must obtain a list of valid users and create a total of 3 logins.
<!-- Stop Instructions -->

14
main/project/WebContent/lesson_plans/DangerousEval.html Normal file
View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>Dangerous Use of Eval</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
It is always a good practice to validate all input on the server side. XSS can occur
when unvalidated user input is reflected directly into an HTTP response. In this lesson, unvalidated
user-supplied data is used in conjunction with a Javascript eval() call. In a reflected
XSS attack, an attacker can craft a URL with the attack script and store it on another
website, email it, or otherwise trick a victim into clicking on it.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
For this exercise, your mission is to come up with some input which, when run through eval,
will execute a malicious script. In order to pass this lesson, you must 'alert()' document.cookie.

9
main/project/WebContent/lesson_plans/Encoding.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Peform Basic Encoding</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Different encoding schemes can be used in web applications for different reasons.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
This lesson will familiarize the user with different encoding schemes.

10
main/project/WebContent/lesson_plans/FailOpenAuthentication.html Normal file
View File

@ -0,0 +1,10 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Bypass Fail Open Authentication </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
This lesson presents the basics for understanding the "fail open" condition regarding authentication. The security term, &#8220;fail open&#8221; describes a behavior of a verification mechanism. This is when an error (i.e. unexpected exception) occurs during a verification method causing that method to evaluate to true. This is especially dangerous during login. <br>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to bypass the authentication check.

21
main/project/WebContent/lesson_plans/ForcedBrowsing.html Normal file
View File

@ -0,0 +1,21 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Forced Browsing Attacks. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
How to Exploit Forced Browsing.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
Forced browsing is a technique used by attackers to gain access to resources that are not referenced, but are nevertheless accessible.
One technique is to manipulate the URL in the browser by deleting sections from the end until an unprotected directory is found
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
* Your goal should be to try to guess the URL for the "config" interface.<br>
* The "config" URL is only available to the maintenance personnel.<br>
* The application doesn't check for horizontal privileges.
<!-- Stop Instructions -->

9
main/project/WebContent/lesson_plans/ForgotPassword.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Exploit the Forgot Password Page</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web applications frequently provide their users the ability to retrieve a forgotten password. Unfortunately, many web applications fail to implement the mechanism properly. The information required to verify the identity of the user is often overly simplistic.
<p><b>General Goal(s):</b> </p>
Users can retrieve their password if they can answer the secret question properly. There is no lock-out mechanism on this 'Forgot Password' page. Your username is 'webgoat' and your favorite color is 'red'. The goal is to retrieve the password of another user.
<!-- Stop Instructions -->

9
main/project/WebContent/lesson_plans/HiddenFieldTampering.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Exploit Hidden Fields </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Developers will use hidden fields for tracking, login, pricing, etc.. information on a loaded page. While this is a convenient and easy mechanism for the developer, they often don't validate the information that is received from the hidden field. This lesson will teach the attacker to find and modify hidden fields to obtain a product for a price other than the price specified <br>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to exploit a hidden field to obtain a product at an incorrect price.

11
main/project/WebContent/lesson_plans/HtmlClues.html Normal file
View File

@ -0,0 +1,11 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Discover Clues in the HTML </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Developers are notorious for leaving statements like FIXME's, Code Broken, Hack, etc... inside the source code. &nbsp;Review the source code for any comments denoting&nbsp; passwords, backdoors, or something doesn't work right.&nbsp;
<!-- Stop Instructions -->
<br>
<p><b>General Goal(s):</b> </p>
The user should be able to bypass the authentication check.

27
main/project/WebContent/lesson_plans/HttpBasics.html Normal file
View File

@ -0,0 +1,27 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Http Basics </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson presents the basics for understanding the transfer of data between the browser and the web application.<br>
<div align="Left">
<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>
<br>
The client contacts the server and sends a document request <br>
</div>
<br>
<ul>GET /index.html?param=value HTTP/1.0</ul>
Next, the client sends optional header information to inform the server of its configuration and the document formats it will accept.<br>
<br>
<ul>User-Agent: Mozilla/4.06 Accept: image/gif,image/jpeg, */*</ul>
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.
<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.
<!-- Stop Instructions -->

25
main/project/WebContent/lesson_plans/HttpOnly.html Normal file
View File

@ -0,0 +1,25 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> HttpOnly Test</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
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.
<p><b>General Goal(s):</b></p>
The purpose of this lesson is to test whether your browser supports the
HTTPOnly cookie flag. Note the value of the
<strong>unique2u</strong>
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.
<br />
<br />
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.
<!-- Stop Instructions -->

32
main/project/WebContent/lesson_plans/HttpSplitting.html Normal file
View File

@ -0,0 +1,32 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Http Splitting </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform HTTP Splitting attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
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 also allows them to create additional responses entirely under their control.<br>
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 to believe that the page
hijacked using the HTTP splitting is a good one and it is indeed the server's copy.<br>
The attack happens using the HTTP Splitting attack plus adding the <b>Last-Modified:</b> header and setting it
to a future date. This will force the browser to send <b>If-Modified-Since</b> request header, which gives the attacker
the chance to intercept the server's reply and replace it with a '304 Not Modified' reply. A sample of a 304 response is:<br>
HTTP/1.1 304 Not Modified <br>
Date: Fri, 30 Dec 2005 17:32:47 GMT
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
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.<br>
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) to exploit the attack. Your exercise 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 and after stage 2 is exploited successfully you will find the green check in the left menu.
<!-- Stop Instructions -->

24
main/project/WebContent/lesson_plans/JSONInjection.html Normal file
View File

@ -0,0 +1,24 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform JSON Injection </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform JSON Injection Attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
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.
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
* You are traveling from Boston, MA- Airport code BOS to Seattle, WA - Airport code SEA.<br>
* Once you enter the three digit code of the airport, an AJAX request will be executed asking for the ticket price.<br>
* You will notice that there are two flights available, an expensive one with no stops and another cheaper one with 2 stops.<br>
* Your goal is to try to get the one with no stops but for a cheaper price.
<!-- Stop Instructions -->

10
main/project/WebContent/lesson_plans/JavaScriptValidation.html Normal file
View File

@ -0,0 +1,10 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Bypass Client Side JavaScript Validation </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->
<br>
<p><b>General Goal(s):</b> </p>
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. <br>

17
main/project/WebContent/lesson_plans/Lesson_Plan_Template.html Normal file
View File

@ -0,0 +1,17 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> </p>
</div>
<!-- Start Instructions -->
<p><b>Concept / Topic To Teach:</b> </p>
<p><b>Standards Addressed:</b> </p>
<p><b>General Goal(s):</b> </p>
<p><b>Specific Objectives:</b> </p>
<p><b>Required Materials:</b> </p>
<p><b>Anticipatory Set (Lead-In):</b> </p>
<p><b>Step-By-Step Procedures:</b> </p>
<p><b>Plan For Independent Practice:</b> </p>
<p><b>Closure (Reflect Anticipatory Set):</b> </p>
<p><b>Assessment Based On Objectives:</b> </p>
<p><b>Extensions (For Gifted Students):</b> </p>
<p><b>Possible Connections To Other Subjects:</b> </p>
<!-- Stop Instructions -->

20
main/project/WebContent/lesson_plans/LogSpoofing.html Normal file
View File

@ -0,0 +1,20 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Log Spoofing. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches attempts to fool the human eye.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
The attack is based on fooling the humane eye in log files. An attacker can erase his traces from the logs
using this attack.
</p>
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
* The grey area below represents what is going to be logged in the web server's log file.<br>
* Your goal is to make it like a username "admin" has succeeded into logging in.<br/>
* Elevate your attack by adding a script to the log file.
<!-- Stop Instructions -->

18
main/project/WebContent/lesson_plans/NewLesson.html Normal file
View File

@ -0,0 +1,18 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Add a New WebGoat Lesson </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Adding lessons to WebGoat is very easy. If you have an idea that would be suitable<br>
for a new lesson, follow these few simple instructions to implement it:<br><br>
* Download the source code from <a href="http://code.google.com/p/webgoat/">here.</a><br><br>
* Setup framework: follow the simple instructions in "HOW TO create the WebGoat workspace.txt" that comes with the project.<br><br>
* You need to add two files for each new lesson: <br>
&nbsp;&nbsp;- YourLesson.java to org.owasp.webgoat.lessons<br>
&nbsp;&nbsp;- YourLesson.html to WebContent/lesson_plans<br><br>
<!-- Stop Instructions -->
<br>
<p><b>General Goal(s):</b> </p>
The user should be able to learn how to add a new lesson.

9
main/project/WebContent/lesson_plans/PathBasedAccessControl.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Bypass a Path Based Access Control Scheme </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to access a file that is not in the listed directory.

9
main/project/WebContent/lesson_plans/ReflectedXSS.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>How to Perform Reflected Cross Site Scripting (XSS)</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
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.

11
main/project/WebContent/lesson_plans/RemoteAdminFlaw.html Normal file
View File

@ -0,0 +1,11 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>How to Force Browser Web Resources</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
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.
<p><b>Standards Addressed :</b> </p>
<p><b>General Goal(s):</b>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->
</p>

15
main/project/WebContent/lesson_plans/RoleBasedAccessControl.html Normal file
View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Role Based Access Control</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
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.
<p><b>Lesson Resources:</b> </p>
<a href="lessons/RoleBasedAccessControl/images/orgChart.jpg" onclick="makeWindow(this.href, 'Org Chart');return false;" target="orgChartWin">Org Chart</a>
<br>
<a href="lessons/RoleBasedAccessControl/images/accessControl.jpg" onclick="makeWindow(this.href, 'Access Control Matrix');return false;" target="accessControlWin">Access Control Matrix</a>
<br>
<a href="lessons/RoleBasedAccessControl/images/dbSchema.jpg" onclick="makeWindow(this.href, 'Access Control Matrix');return false;" target="accessControlWin">Database Schema</a>

13
main/project/WebContent/lesson_plans/SameOriginPolicyProtection.html Normal file
View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>Same Origin Policy Protection</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
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.";

24
main/project/WebContent/lesson_plans/SilentTransactions.html Normal file
View File

@ -0,0 +1,24 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Silent Transactions Attacks. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform silent transactions attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
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<65>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.<br>
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
* This is a sample internet banking application - money transfer page.<br>
* It shows below your balance, the account you are transferring to and amount you will transfer.<br>
* The application uses AJAX to submit the transaction after doing some basic client side validations.<br>
* Your goal is to try to bypass the user's authorization and silently execute the transaction.<br>
<!-- Stop Instructions -->

9
main/project/WebContent/lesson_plans/SoapRequest.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Create a SOAP Request</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- 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.
<!-- Stop Instructions -->

14
main/project/WebContent/lesson_plans/SqlNumericInjection.html Normal file
View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Numeric SQL Injection </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<br><br>
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.<br>
<br>
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.<br>
<p><b>General Goal(s):</b> </p>
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.
<!-- Stop Instructions -->

14
main/project/WebContent/lesson_plans/SqlStringInjection.html Normal file
View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform String SQL Injection </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<br><br>
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.<br>
<br>
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.<br>
<p><b>General Goal(s):</b> </p>
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'.
<!-- Stop Instructions -->

9
main/project/WebContent/lesson_plans/StoredXss.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Stored Cross Site Scripting (XSS) </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to add message content that cause another user to load an undesireable page or content.

22
main/project/WebContent/lesson_plans/ThreadSafetyProblem.html Normal file
View File

@ -0,0 +1,22 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Lesson Plan</title>
</head>
<body>
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Exploit Thread Safety Problems </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web applications can handle many HTTP requests simultaneously. Developers often use variables that are not thread safe. &nbsp;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. <br>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
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. <b>This will require the use of two browsers</b>.
<br>
</body>
</html>

9
main/project/WebContent/lesson_plans/TraceXSS.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Tracing (XST) Attacks </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<p><b>General Goal(s):</b> </p>
Tomcat is configured to support the HTTP TRACE command. Your goal is to perform a Cross Site Tracing (XST) attack.
<!-- Stop Instructions -->

9
main/project/WebContent/lesson_plans/UncheckedEmail.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Exploit Unchecked Email </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to send and obnoxious email message.

9
main/project/WebContent/lesson_plans/WSDLScanning.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform WSDL Scanning</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- 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) file.
<p><b>General Goal(s):</b> </p>
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.
<!-- Stop Instructions -->

10
main/project/WebContent/lesson_plans/WeakAuthenticationCookie.html Normal file
View File

@ -0,0 +1,10 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Spoof an Authentication Cookie </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Many applications will automatically log a user into their site if the right authentication cookie is specified. &nbsp; Some times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. &nbsp;Some times the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. &nbsp;Some times the cookies maybe intercepted using Cross site scripting. &nbsp;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.<br>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to bypass the authentication check.

9
main/project/WebContent/lesson_plans/WeakSessionID.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Hijack a Session</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<p><b>General Goal(s):</b> </p>
Try to access an authenticated session belonging to someone else.
<!-- Stop Instructions -->

16
main/project/WebContent/lesson_plans/WelcomeScreeen.html Normal file
View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Lesson Plan Title:Welcome</b> </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson presents the basics for understanding the transfer of data between the browser and the web application.
<p><b>Standards Addressed:</b> </p>
<p><b>General Goal(s):</b> </p>
<p><b>Specific Objectives:</b> </p>
<p><b>Required Materials:</b> </p>
<p><b>Anticipatory Set (Lead-In):</b> </p>
<p><b>Step-By-Step Procedures:</b> </p>
<p><b>Plan For Independent Practice:</b> </p>
<p><b>Closure (Reflect Anticipatory Set):</b> </p>
<p><b>Assessment Based On Objectives:</b> </p>
<p><b>Extensions (For Gifted Students):</b> </p>
<p><b>Possible Connections To Other Subjects:</b> </p>

12
main/project/WebContent/lesson_plans/WsSAXInjection.html Normal file
View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Web Service SAX Injection</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- 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) file.
<p><b>General Goal(s):</b> </p>
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.
<br/>
<br>
In this exercise, try to change the password for a user other than 101.
<!-- Stop Instructions -->

9
main/project/WebContent/lesson_plans/WsSqlInjection.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Web Service SQL Injection</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- 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) file.
<p><b>General Goal(s):</b> </p>
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'.
<!-- Stop Instructions -->

19
main/project/WebContent/lesson_plans/XMLInjection.html Normal file
View File

@ -0,0 +1,19 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform XML Injection Attacks. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform XML Injection attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
AJAX applications use XML to exchange information with the server. This XML can be easily intercepted and altered by a malicious attacker.
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->

22
main/project/WebContent/lesson_plans/XPATHInjection.html Normal file
View File

@ -0,0 +1,22 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform XPATH Injection Attacks. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform XPath Injection attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
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.
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->