git-svn-id: http://webgoat.googlecode.com/svn/trunk@14 4033779f-a91e-0410-96ef-6bf7bf53c507
This commit is contained in:
mayhew64
@ -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 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.
|
||||
<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 -->
|
||||
@ -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 sendthose 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 -->
|
||||
@ -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 queiries.<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.
|
||||
@ -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 -->
|
||||
@ -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.
|
||||
@ -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 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.
|
||||
@ -0,0 +1,11 @@
|
||||
<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 undesireable page or undesireable 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>
|
||||
@ -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 -->
|
||||
@ -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.
|
||||
@ -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, “fail open” 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.
|
||||
@ -0,0 +1,9 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> How to Exploit Forced Browsing</p>
|
||||
</div>
|
||||
<!-- Start Instructions -->
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
How to Exploit Forced Browsing
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
This lesson needs a creator!
|
||||
<!-- Stop Instructions -->
|
||||
@ -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, most web applications fail to implement the mechanism properly. The information required to verify the integrity 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 -->
|
||||
@ -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 convienent 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.
|
||||
@ -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. Review the source code for any comments denoting passowrds, backdoors, or something doesn't work right.
|
||||
<!-- Stop Instructions -->
|
||||
<br>
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
The user should be able to bypass the authentication check.
|
||||
@ -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 -->
|
||||
@ -0,0 +1,9 @@
|
||||
<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 unique2u cookie. If your browser supports HTTPOnly, and you enable it for a cookie, client side code should NOT be able to read OR write to that cookie, but the browser can still send its value to the server. Some browsers only prevent client side read access, but don't prevent write access.
|
||||
<!-- Stop Instructions -->
|
||||
@ -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 validation 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 likelyhood 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>
|
||||
@ -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 -->
|
||||
@ -0,0 +1,16 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Parameter Injection </p>
|
||||
</div>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
Parameter 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>
|
||||
<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>
|
||||
<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 -->
|
||||
<br>
|
||||
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
The user should be able to execute any command on the hosting OS.
|
||||
@ -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.
|
||||
@ -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.
|
||||
@ -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 adminstrative 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>
|
||||
@ -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>
|
||||
@ -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 listed in the web service definition language (WSDL). Lets learn something about WSDL files. Check out WebGoats 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 -->
|
||||
@ -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>
|
||||
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 queiries.<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 -->
|
||||
@ -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>
|
||||
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 queiries.<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 -->
|
||||
@ -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 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 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.
|
||||
@ -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. 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>
|
||||
@ -0,0 +1,9 @@
|
||||
<div align="Center">
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Trace Attacks </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 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 Trace (XST) attack.
|
||||
<!-- Stop Instructions -->
|
||||
@ -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 a non-authenticated users to send email to a 'friend'. This is a great mechanisms 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.
|
||||
@ -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 listed in the web service definition language (WSDL).
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
This screen is the API for a web service. Check the WSDL for this web service and try to get some customer credit numbers.
|
||||
<!-- Stop Instructions -->
|
||||
@ -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. Some times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. Some times the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. Some times the cookies maybe intercepted using Ccross site scripting. This lesson tries to make the student aware of authentication cookies and presents the student with a way to defeat the cookie authentication method in this lesson.<br>
|
||||
<!-- Stop Instructions -->
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
The user should be able to bypass the authentication check.
|
||||
@ -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 ID 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 -->
|
||||
@ -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>
|
||||
@ -0,0 +1,9 @@
|
||||
<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 listed in the web service definition language (WSDL).
|
||||
<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/>In this exercise, try to change the password for a user other than 101.
|
||||
<!-- Stop Instructions -->
|
||||
@ -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 listed in the web service definition language (WSDL).
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
Check the web service description language (WSDL) 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 -->
|
||||
Reference in New Issue
Block a user