* Hints added
* Solutions added * Bugfixes * Introduction added (including how to start with webgoat and useful tools) * New lesson: Password strength * New lessons: Multi Level Login * Not yet working new lesson: Session fixation (inital release) git-svn-id: http://webgoat.googlecode.com/svn/trunk/webgoat@301 4033779f-a91e-0410-96ef-6bf7bf53c507
This commit is contained in:
@ -0,0 +1,32 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>Solution Lab Block Stored XSS</title>
|
||||
<link rel="stylesheet" type="text/css" href="/WebGoat/lesson_solutions/formate.css">
|
||||
</head>
|
||||
<body>
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>General Goal(s):</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<b>Solution:</b><br/>
|
||||
The Solution is rather simular to stage 2. You have to edit org.owasp.webgoat.lessons.CrossSiteScripting.FindProfile.java.
|
||||
Alter the method getRequestParameter. The body of the mehtod should look something like this:<pre><code>
|
||||
String regex = "[\\s\\w-,]*";
|
||||
String parameter = s.getParser().getRawParameter(name);
|
||||
Pattern pattern = Pattern.compile(regex);
|
||||
validate(parameter, pattern);
|
||||
|
||||
return parameter;
|
||||
</code></pre>
|
||||
|
||||
</body>
|
||||
</html>
|
@ -0,0 +1,46 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>Solution Lab Block Stored XSS</title>
|
||||
<link rel="stylesheet" type="text/css" href="/WebGoat/lesson_solutions/formate.css">
|
||||
</head>
|
||||
<body>
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>General Goal(s):</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>Solution:</b><br/>
|
||||
You have to alter the method parseEmployeeProfile in the class UpdateProfile.java which is
|
||||
placed in the package org.owasp.webgoat.lessons.CrossSiteScripting<br/>
|
||||
The place to code is marked! Following code will work:<br/>
|
||||
</p>
|
||||
<p>
|
||||
<code>
|
||||
/**Your code**/<br/>
|
||||
String regex = "[\\s\\w-,]*";<br/>
|
||||
String stringToValidate = firstName+lastName+ssn+title+phone+address1+address2+<br/>startDate+ccn+disciplinaryActionDate+<br/>disciplinaryActionNotes+personalDescription;<br/>
|
||||
Pattern pattern = Pattern.compile(regex);<br/>
|
||||
validate(stringToValidate, pattern);<br/>
|
||||
/**End of your code**/
|
||||
</code>
|
||||
</p>
|
||||
<p>
|
||||
This validation allows following:<br>
|
||||
\s = whitspace: \t\n\x0B\f\r<br>
|
||||
\w = word: a-zA-Z_0-9<br>
|
||||
and the characters - and ,
|
||||
</p>
|
||||
<p>
|
||||
Use of any other character will throw a Validation Exception.
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
@ -0,0 +1,26 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>Solution Lab Block Stored XSS</title>
|
||||
<link rel="stylesheet" type="text/css" href="/WebGoat/lesson_solutions/formate.css">
|
||||
</head>
|
||||
<body>
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>General Goal(s):</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>Solution:</b><br/>
|
||||
You have to use a static method called encode(String s) which is part of the class org.owasp.webgoat.util.HtmlEncoder.
|
||||
<p>This method changes all special characters in the string. Now you have to use this method in the getEmployeeProfile method in the org.owasp.webgoat.lessons.CrossSiteScripting class.
|
||||
Replace all answer_results.getString(someString) with HtmlEncoder.encode(answer_results.getString(someString)) and you are done.</p>
|
||||
|
||||
</body>
|
||||
</html>
|
@ -0,0 +1,27 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>Solution Lab Block Stored XSS</title>
|
||||
<link rel="stylesheet" type="text/css" href="/WebGoat/lesson_solutions/formate.css">
|
||||
</head>
|
||||
<body>
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>General Goal(s):</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>Solution:</b><br/>
|
||||
First log in as an user for example as Larry with password larry. Now click on
|
||||
the 'SearchStaff' Button. Burry a script in the field for example:
|
||||
<code><script>alert("Dangerous");</script></code>. Now hit
|
||||
the 'FindProfile' Button and you are done.</p>
|
||||
|
||||
</body>
|
||||
</html>
|
@ -0,0 +1,27 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>Solution Lab Block Stored XSS</title>
|
||||
<link rel="stylesheet" type="text/css" href="/WebGoat/lesson_solutions/formate.css">
|
||||
</head>
|
||||
<body>
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>General Goal(s):</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>Solution:</b><br/>
|
||||
Log in as David with david as password. Choose Bruce from the List and click
|
||||
on the 'ViewProfile' Button.
|
||||
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
@ -0,0 +1,36 @@
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||||
<html>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
||||
<title>Solution Lab Block Stored XSS</title>
|
||||
<link rel="stylesheet" type="text/css" href="/WebGoat/lesson_solutions/formate.css">
|
||||
</head>
|
||||
<body>
|
||||
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>General Goal(s):</b><br/>
|
||||
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.
|
||||
</p>
|
||||
|
||||
<p><b>Solution:</b><br/>
|
||||
First Login as Tom with tom as password. Select Tom from the list and click on the View Profile Button.
|
||||
Now should appear Tom's Profile. Click on the 'Edit Profile' Button and try an XSS attack on the street filed.<br/>
|
||||
For example: <script>alert("Got Ya");</script><br/>
|
||||
Click on the UpdateProfile Button and Log out.</p><p>
|
||||
<p>
|
||||
<center>
|
||||
<img src="/WebGoat/lesson_solutions/Lab XSS/images/stored_xss.png" width=450px alt="stored_xss.png" />
|
||||
</center>
|
||||
<p>
|
||||
Now log in as Jerry with jerry as password. Select from the the list the profile of tom and hit the
|
||||
ViewProfile Button. Congratulation! You have completed the lesson.
|
||||
|
||||
</p>
|
||||
|
||||
</body>
|
||||
</html>
|
Binary file not shown.
After Width: | Height: | Size: 66 KiB |
Reference in New Issue
Block a user