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

* Hints added

Browse Source 
* 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:
wirth.marcel
2008-04-07 14:28:38 +00:00
parent 84f01ba70a
commit 5d930ec235
137 changed files with 4230 additions and 479 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
main/project/WebContent/lesson_solutions/Lab XSS/Lab Block Reflected XSS.html Normal file
View File

@ -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>

46
main/project/WebContent/lesson_solutions/Lab XSS/Lab Block Stored XSS using Input Validation.html Normal file
View File

@ -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>

26
main/project/WebContent/lesson_solutions/Lab XSS/Lab Block Stored XSS using Output Encoding.html Normal file
View File

@ -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>

27
main/project/WebContent/lesson_solutions/Lab XSS/Lab Reflected XSS.html Normal file
View File

@ -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>&lt;script&gt;alert("Dangerous");&lt;/script&gt;</code>. Now hit
the 'FindProfile' Button and you are done.</p>
</body>
</html>

27
main/project/WebContent/lesson_solutions/Lab XSS/Lab Stored XSS Revisited.html Normal file
View File

@ -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>

36
main/project/WebContent/lesson_solutions/Lab XSS/Lab Stored XSS.html Normal file
View File

@ -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: &lt;script&gt;alert("Got Ya");&lt;/script&gt;<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>

BIN
main/project/WebContent/lesson_solutions/Lab XSS/images/stored_xss.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 66 KiB