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

Create directories ru/en/de and copy there plans of lessons. In ru-directory i put english files for translate them in future.

Browse Source 
git-svn-id: http://webgoat.googlecode.com/svn/trunk@421 4033779f-a91e-0410-96ef-6bf7bf53c507
This commit is contained in:
white.tiger.russia@gmail.com 2011-05-22 11:22:28 +00:00
parent 77a6dd70a1
commit b22a537130
144 changed files with 2649 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
webgoat/src/main/webapp/lesson_plans/de/BasicAuthentication.html Normal file
View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Lehrplan:</b> Basic Authentication </p>
</div>
<p><b>Lehrinhalt:</b></p>
<!-- Start Instructions -->
"Basic Authentication" wird benutzt um Server-seitige Resource zu schützen. Wird eine Anfrage an eine geschützte Resource gestellt, so sendet der Webserver ein "401 authentication request" mit der Antwort auf diese Anfrage.
Dann fragt, auf der Client Seite, der Browser den Benutzer mittels einer Dialogbox nach Benutzername und Passwort für diese Resource.
Der Browser enkodiert Benutzername und Passwort mit base64 und sendet diese Zugangsdaten zum Webserver.
Daraufhin validiert der Webserver Benutzername und Passwort und gibt als Antwort die angeforderte Resource zurück falls die übermittelten Zugangsdaten korrekt sind.
Die Zugangsdaten werden vom Browser bei jedem weiteren Zugriff auf geschützte Resourcen mitgesendet ohne dass der Benutzer
sie ein weiteres Mal eingeben muss.<br/>
<br/>
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b></p>
Das Ziel dieser Lektion ist es "Basic Authentication" zu verstehen und die folgenden Fragen zu beantworten.
<!-- Stop Instructions -->

16
webgoat/src/main/webapp/lesson_plans/de/CommandInjection.html Normal file
View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Lehrplan:</b> Einschleusen von Programmcode</p>
</div>
<p><b>Konzept:</b></p>
Das Einschleusen von Programmcode stellt eine ernst zu nehmende Bedrohung für dynamische Webseiten dar. Entsprechende Angriffe
sind leicht zu lernen und der verursachte Schaden ist schwer bzw. entspricht der Kompromittierung des kompletten Systems.
Trotz dieses Gefahrenpotentials ist eine unglaubliche Anzahl von Systemen im Internet für diese Form des Angriffs verwundbar.
Dieser Angriff ist zwar leicht durchzuführen, allerdings ist er auch mit ein wenig gesundem Menschenverstand und Vorausdenken
leicht zu verhindern. Die anerkannte Vorgehensweise zur Verhinderung dieser Angriffstypen
besteht darin alle Eingabedaten zu säubern, insbesondere die Daten die in Betriebssystembefehlen,
Skripten und Datenbankabfragen eingebaut werden.
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b></p>
<!-- Start Instructions -->
Schleusen Sie einen Befehl in das darunterliegende Betriebssystem ein.
<!-- Stop Instructions -->

14
webgoat/src/main/webapp/lesson_plans/de/HiddenFieldTampering.html Normal file
View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Lehrplan:</b> Versteckte Felder ausnutzen </p>
</div>
<p><b>Konzept:</b> </p>
<!-- Start Instructions -->
Entwickler benutzen versteckte Formularfelder zur Besucherverfolgung, für den Login, für Preisinformationen und andere
Informationen. Dies ist ein sehr einfacher und bequemer Mechnismus für Entwickler, allerdings werden die Werte
diese Felder nur selten geprüft bevor sie benutzt werden. In dieser Lektion lernt man wie man versteckte Felder
zu seinem Vorteil manipulieren kann.
<br>
<!-- Stop Instructions -->
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
Nutzen Sie ein verstecktes Formularfeld aus, um den HD Fernseher zu einem falschen Preis zu kaufen.

13
webgoat/src/main/webapp/lesson_plans/de/HtmlClues.html Normal file
View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Lehrplan:</b> Nützliche Hinweise in HTML entdecken. </p>
</div>
<p><b>Konzept:</b> </p>
<!-- Start Instructions -->
Entwickler lassen oftmals Kommentare wie FIXME's, TODO's, Code Broken, Hack usw. im Quellcode.
Durchsuchen Sie den Quellcode nach allem was für Sie nach Passwörtern, Hintertüren oder anderen Unregelmäßigkeiten aussieht.
<!-- Stop Instructions -->
<br>
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
Sie suchen und finden Hinweise im Quellcode die es Ihnen erlauben sich anzumelden.

29
webgoat/src/main/webapp/lesson_plans/de/HttpBasics.html Normal file
View File

@ -0,0 +1,29 @@
<div align="Center">
<p><b>Lehrplan:</b> Http Basics </p>
</div>
<p><b>Lehrinhalt:</b> </p>
Diese Lektion stellt die Verst&auml;ndnis-Grundlagen f&uuml;r den Datentransport zwischen Browser und Webapplikation dar.<br>
<div align="Left">
<p>
<b>So funktioniert HTTP:</b>
</p>
Alle HTTP Transaktionen folgen demselben Schema. Jede Anfrage vom Client und jede Antwort des Servers besteht aus drei Teilen: Der Anfrage-/Antwortzeile, dem Kopf und dem Körper.
Der Client initiiert eine Transaktion wie folgt:<br>
<br>
Der Client kontaktiert den Server und sendet eine Dokumentenanfrage<br>
</div>
<br>
<ul>GET /index.html?param=value HTTP/1.0</ul>
Als n&auml;chstes sendet der Client optionale Kopfzeilen (Header) um den Server &uuml;ber die Client-seitige Konfiguration und die akzeptierten Dokumentenformate zu informieren.<br>
<br>
<ul>User-Agent: Mozilla/4.06 Accept: image/gif,image/jpeg, */*</ul>
Nachdem der eigentliche Anfrage (Request) und den weiteren Kopfzeilen (Header) kann der Client noch weitere Daten senden. Diese Daten werden meistens von CGI Programmen im Zusammenhang mit der POST Methode ausgewertet.
<br>
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
<!-- Start Instructions -->
Geben Sie Ihren Namen in das Eingabefeld ein und drücken sie "Los gehts!" um die Anfrage abzuschicken. Der Server wird die Anfrage akzeptieren, Ihre Eingabedaten umdrehen, und wieder zu Ihnen zurückschicken. Dies stellt eine vollst&auml;ndige HTTP Transaktion dar!
<br/><br/>
Sie sollten mit der Benutzung von WebGoat vertraut werden. Es sollten die Knöpfe f&uuml;r Hinweise (Hints), f&uuml;r das Anzeigen von Parametern(Parameters) oder Cookies und f&uuml;r das Anzeigen von Java-Quellcode ausprobiert werden.
Außerdem, k&ouml;nnen Sie hier WebScarab gut ausprobieren.
<!-- Stop Instructions -->

19
webgoat/src/main/webapp/lesson_plans/de/JavaScriptValidation.html Normal file
View File

@ -0,0 +1,19 @@
<div align="Center">
<p><b>Lehrplan:</b> Client-seitige JavaScript Validierung umgehen</p>
</div>
<p><b>Konzept:</b> </p>
Client-seitige Validierung sollte nicht als eine sichere Maßnahme zur Validierung von Parametern angesehen werden.
Diese Art der Validierung kann höchstens den Server entlasten und verhindern das normale Benutzer Eingabedaten in
einem falschen Format absenden. Angreifer hingegen, können diesen Mechanismus auf verschiedene Arten umgehen. Jede
Client-seitige Validierung sollte auf der Serverseite wiederholt werden. Dies verhindert, dass unsichere Parameter
in der Applikation benutzt werden.
<br>
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
<!-- Start Instructions -->
Das untenstehende Formular verlangt von Ihnen verschiedene Regeln beim Ausfüllen einzuhalten. Dies wird Client-seitig
überprüft. Versuchen Sie diese
Regeln zu brechen und senden Sie Daten an die Webseite die die Webseite nicht erwartet! <b> Sie müssen alle 7 Regeln
gleichzeitig brechen! </b>
<!-- Stop Instructions -->

17
webgoat/src/main/webapp/lesson_plans/de/LogSpoofing.html Normal file
View File

@ -0,0 +1,17 @@
<div align="Center">
<p><b>Lehrplan:</b> Fälschen von Einträgen in Log Dateien (Log Spoofing) </p>
</div>
<p><b>Konzept:</b> </p>
<p>
Log-Einträge in Log-Dateien müssen nicht immer von tatsächlichen Ereignissen stammen. Ein Angreifer kann durch Einschleusen
bestimmter Einträge das Eintreten bestimmter Ereignisse vortäuschen und dadurch den Administrator zu unnötigen bzw. voreiligen
Handlungen verleiten bzw. ihn einfach nur verwirren.
</p>
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
<!-- Start Instructions -->
* Der graue Bereich steht für das was tatsächlich in der Log-Datei des Webservers erscheint.<br>
* Ihr Ziel ist es so aussehen zu lassen, als hätte sich der Benutzer "admin" erfolgreich eingeloggt.<br/>
* Verbessern Sie Ihren Angriff, indem Sie ein Skript (Javascript) in das Log schreiben.
<!-- Stop Instructions -->

11
webgoat/src/main/webapp/lesson_plans/de/PathBasedAccessControl.html Normal file
View File

@ -0,0 +1,11 @@
<div align="Center">
<p><b>Lehrplan:</b> Umgehen eines Pfad-basierten Zugangskontrollschemas</p>
</div>
<p><b>Konzept:</b> </p>
<!-- Start Instructions -->
In einem Pfad-basierten Zugangangskontrollschemas (path based access control scheme), kann ein Angreifer den Pfad "bewandern" indem
er relative Pfadangaben übergibt. Dadurch kann der Angreifer auf Dateien zugreifen, die für niemanden zugänglich sind, bzw. zu denen
der Zugang bei direkter Anfrage ansonsten abgelehnt würde.
<!-- Stop Instructions -->
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
Sie sollten in der Lage sein auf eine Datei zuzugreifen die sich nicht im aufgelisteten Verzeichnis befindet.

19
webgoat/src/main/webapp/lesson_plans/de/ReflectedXSS.html Normal file
View File

@ -0,0 +1,19 @@
<div align="Center">
<p><b>Lehrplan: </b>Cross Site Scripting (XSS)</p>
</div>
<p><b>Konzept:</b> </p>
Jegliche Eingabedaten sollten auf der Serverseite überprüft werden.
XSS passiert wenn nicht geprüfte Benutereingaben in eine HTTP Response eingebaut werden.
Bei einem reflektierten XSS Angriff, kann ein Angreifer eine URL erzeugen die ein Angriffsskript enthält und kann diese
URL auf einer Webseite hinterlegen, sie per Email verschicken oder ein Opfer auf eine andere Weise dazu bringen die
URL zu besuchen.
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
Ihre Aufgabe ist es, sich ein Stück Javascript zu überlegen das Sie in diese Seite einbauen können.
Dann versuchen Sie die Seite dazu zu bringen, Ihnen dieses Skript wieder auszulieferen (es zu reflektieren)
so dass das Skript in Ihrem Browser ausgeführt wird.
<!-- Stop Instructions -->

16
webgoat/src/main/webapp/lesson_plans/de/RemoteAdminFlaw.html Normal file
View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Lehrplan: </b>Zugang zu Web-Resourcen erzwingen</p>
</div>
<p><b>Konzept::</b> </p>
Applikationen haben oftmals eine Administrationsschnittstelle, das priviligierten Benutzern Zugang zu Funktionalität ermöglicht die
für normale Benutzer nicht sichtbar ist. Der Applikationsserver selbst hat auch oft noch eine seperate Administrationsschnittstelle.
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b>
<!-- Start Instructions -->
Versuchen Sie auf die Administrationsschnittstelle von WebGoat zuzugreifen. Sie können auch versuchen auf die Administrationsschnittstelle
von Tomcat (der Applikationsserver) zuzugreifen. Die Tomcat Schnittstelle kann über die URL /admin erreicht werden, zählt aber nicht
für das Bestehen dieser Lektion.
Wenn Sie Zugriff auf Funktionalität der Administrationsschnittstelle erlangt haben, dann kommen Sie hierher zurück um zu sehen ob Sie
die Lektion abgeschlossen haben.
<!-- Stop Instructions -->
</p>

18
webgoat/src/main/webapp/lesson_plans/de/SqlNumericInjection.html Normal file
View File

@ -0,0 +1,18 @@
<div align="Center">
<p><b>Lehrplan:</b> Durchführung von Numeric SQL Injection </p>
</div>
<p><b>Konzept:</b> </p>
SQL Injection Angriffe stellen eine ernstzunehmende Bedrohung für alle Datenbank-getriebenen Webseiten dar.
Entsprechende Angriffe sind leicht zu lernen und der verursachte Schaden ist schwer bzw. entspricht der
Kompromittierung des kompletten Systems.
Trotz dieses Gefahrenpotentials ist eine unglaubliche Anzahl von Systemen im Internet für diese Form des Angriffs verwundbar.
Dieser Angriff ist zwar leicht durchzuführen, allerdings ist er auch mit ein wenig gesundem Menschenverstand und Vorausdenken
leicht zu verhindern. Die anerkannte Vorgehensweise zur Verhinderung dieser Angriffstypen
besteht darin alle Eingabedaten zu säubern, insbesondere die Daten die in Betriebssystembefehlen,
Skripten und Datenbankabfragen eingebaut werden.
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
<!-- Start Instructions -->
Das untenstehende Formular ermöglicht es dem Benutzer Wetterdaten zu betrachten. Versuchen Sie einen SQL String einzuschleusen, der
als Resultat alle Wetterdaten anzeigt.
<!-- Stop Instructions -->

20
webgoat/src/main/webapp/lesson_plans/de/SqlStringInjection.html Normal file
View File

@ -0,0 +1,20 @@
<div align="Center">
<p><b>Lehrplan:</b> Durchführung von String SQL Injection</p>
</div>
<p><b>Konzept:</b> </p>
SQL Injection Angriffe stellen eine ernstzunehmende Bedrohung für alle Datenbank-getriebenen Webseiten dar.
Entsprechende Angriffe sind leicht zu lernen und der verursachte Schaden ist schwer bzw. entspricht der
Kompromittierung des kompletten Systems.
Trotz dieses Gefahrenpotentials ist eine unglaubliche Anzahl von Systemen im Internet für diese Form des Angriffs verwundbar.
Dieser Angriff ist zwar leicht durchzuführen, allerdings ist er auch mit ein wenig gesundem Menschenverstand und Vorausdenken
leicht zu verhindern. Die anerkannte Vorgehensweise zur Verhinderung dieser Angriffstypen
besteht darin alle Eingabedaten zu säubern, insbesondere die Daten die in Betriebssystembefehlen,
Skripten und Datenbankabfragen eingebaut werden.
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
<!-- Start Instructions -->
Das untenstehende Formular erlaubt es Benutzern ihre Kreditkartennummern anzuzeigen. Das können Sie
exemplarisch mit dem Benutzernamen "Smith" ausprobieren.
Versuchen Sie einen SQL String einzuschleusen, der als Resultat alle Kreditkartennummern anzeigt.
<!-- Stop Instructions -->

16
webgoat/src/main/webapp/lesson_plans/de/StoredXss.html Normal file
View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Lehrplan:</b> Durchführen von Stored Cross Site Scripting (XSS) </p>
</div>
<p><b>Konzept:</b> </p>
Man sollte Eingabedaten immer säubern, besonders diese die später als parameter für Betriebssystembefehle, Skripte
und Datenbankabfragen benutzt werden. Essentiell ist das für Inhalt der irgendwo in der Applikation permanent gespeichert
wird. Benutzer sollten nicht in der Lage sein eigene Inhalte zu hinterlassen, durch die andere Nutzer ungewünschte
Seiten oder Inhalte nachladen wenn der Inhalt betrachtet wird.
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
<!-- Start Instructions -->
Hinterlassen Sie Inhalt der den Browser eines anderen Benutzers dazu bringt eine unerwünschte
Seite bzw. Inhalt anzuzeigen.
<!-- Stop Instructions -->

22
webgoat/src/main/webapp/lesson_plans/de/WeakAuthenticationCookie.html Normal file
View File

@ -0,0 +1,22 @@
<div align="Center">
<p><b>Lehrplan:</b> Einen Authentisierungs Cookie fa&uml;lschen</p>
</div>
<p><b>Lehrinhalt:</b> </p>
Viele Webapplikationen erlauben es einem Benutzer sofort eingeloggt zu sein, sobald der Benutzer den richtigen Authentisierungs Cookie übergibt.
Manchmal kann der richtige Wert dieses Cookies geraten werden, wenn der Algorithmus zur Generierung dieser Cookies bekannt ist.
Der Cookie kann auch von dem Computer des Benutzers gestohlen werden indem andere Schwachstellen in seinem System ausgenutzt werden.
Mittels Cross Site Scripting (XSS) kann der Cookie auch abgefangen werden.
Diese Übung soll Sie auf das Thema der Authentisierungs Cookies aufmerksam machen und gibt Ihnen
die Möglichkeit die Authentisierungsmethode dieser Lektion zu überwinden.
<p><b>Grunds&auml;tzliche(s) Ziel(e):</b> </p>
<!-- Start Instructions -->
Es ist Ihre Aufgabe die Authentisierung zu umgehen. Melden Sie sich mit dem Benutzernamen "webgoat" und dem Passwort "webgoat" an
und schauen Sie was passiert. Sie können auch versuchen Sich mit aspect/aspect anzumelden. Wenn Sie den Authentisierungs Cookie verstehen,
versuchen Sie Ihre Identität zu "alice" zu wechseln.
<!-- Stop Instructions -->

9
webgoat/src/main/webapp/lesson_plans/en/AccessControlMatrix.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Using an Access Control Matrix</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
In a role-based access control scheme, a role represents a set of access permissions and privileges. A user can be assigned one or more roles. A role-based access control scheme normally consists of two parts: role permission management and role assignment. A broken role-based access control scheme might allow a user to perform accesses that are not allowed by his/her assigned roles, or somehow allow privilege escalation to an unauthorized role.
<p><b>General Goal(s):</b> </p>
Each user is a member of a role that is allowed to access only certain resources. Your goal is to explore the access control rules that govern this site. Only the [Admin] group should have access to the 'Account Manager' resource.
<!-- Stop Instructions -->

23
webgoat/src/main/webapp/lesson_plans/en/BackDoors.html Normal file
View File

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

9
webgoat/src/main/webapp/lesson_plans/en/BasicAuthentication.html Normal file
View File

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

15
webgoat/src/main/webapp/lesson_plans/en/BlindSqlInjection.html Normal file
View File

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

9
webgoat/src/main/webapp/lesson_plans/en/BufferOverflow.html Normal file
View File

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

26
webgoat/src/main/webapp/lesson_plans/en/CSRF.html Normal file
View File

@ -0,0 +1,26 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Request Forgery. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform Cross Site Request Forgery (CSRF) attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into loading a page that contains img links like the one below:
<pre>&lt;img src="<a href="http://www.mybank.com/transferFunds.do?acctId=123456" class='external free' title="http://www.mybank.com/transferFunds.do?acctId=123456" rel="nofollow">http://www.mybank.com/sendFunds.do?acctId=123456</a>"/&gt;</pre>
When the victim's browser attempts to render this page, it will issue a request to www.mybank.com to the transferFunds.do page with the specified parameters. The browser will think the link is to get an image, even though it actually is a funds transfer function.
The request will include any cookies associated with the site. Therefore, if the user has authenticated to the site, and has either a permanent cookie or even a current session cookie, the site will have no way to distinguish this from a legitimate user request.
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, or any other function provided by the vulnerable website
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
Your goal is to send an email to a newsgroup that contains an image whose URL is pointing to a malicious request. Try to include a 1x1 pixel image that includes a URL. The URL should point to the CSRF lesson with an extra parameter "transferFunds=4000". You can copy the shortcut from the left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever receives this email and happens to be authenticated at that time will have his funds transferred. When you think the attack is successful, refresh the page and you will find the green check on the left hand side menu.
<!-- Stop Instructions -->

7
webgoat/src/main/webapp/lesson_plans/en/ChallengeScreen.html Normal file
View File

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

12
webgoat/src/main/webapp/lesson_plans/en/ClientSideFiltering.html Normal file
View File

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

15
webgoat/src/main/webapp/lesson_plans/en/ClientSideValidation.html Normal file
View File

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

12
webgoat/src/main/webapp/lesson_plans/en/CommandInjection.html Normal file
View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Command Injection</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
Command&nbsp; injection attacks represent a serious threat to any parameter-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks an incredible number of systems on the internet are susceptible to this form of attack.<br/>
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can be almost totally prevented. This lesson will show the student several examples of parameter injection.<br/>
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries.<br/>
Try to inject a command to the operating system.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
The user should be able to execute any command on the hosting OS.

22
webgoat/src/main/webapp/lesson_plans/en/ConcurrencyCart.html Normal file
View File

@ -0,0 +1,22 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Lesson Plan</title>
</head>
<body>
<div align="Center">
<p><b>Lesson Plan Title:</b> Shopping Cart Concurrency Flaw </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web applications can handle many HTTP requests simultaneously. Developers often use variables that are not thread safe. &nbsp;Thread safety means that the fields of an object or class always maintain a valid state when used concurrently by multiple threads. It is often possible to exploit a concurrency bug by loading the same page as another user at the exact same time. Because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently. <br>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
For this exercise, your mission is to exploit the concurrency issue which will allow you to purchase merchandise for a lower price.
<br>
</body>
</html>

12
webgoat/src/main/webapp/lesson_plans/en/CrossSiteScripting.html Normal file
View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
It is always a good practice to scrub all inputs, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere. Users should not be able to create message content that could cause another user to load an undesirable page or undesirable content when the user's message is retrieved.<br>
XSS can also occur when unvalidated user input is used in an HTTP response. In a reflected XSS attack, an attacker can craft a URL with the attack script and post it to another website, email it, or otherwise get a victim to click on it.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
For this exercise, you will perform stored and reflected XSS attacks. You will also implement code changes in the web application to defeat these attacks.
<br>

32
webgoat/src/main/webapp/lesson_plans/en/CsrfPromptByPass.html Normal file
View File

@ -0,0 +1,32 @@
<div align="Center">
<p><b>Lesson Plan Title:</b>CSRF User Prompt By-Pass</p><br/>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform CSRF attacks that by-pass user confirmation prompts.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
<p>
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into loading a page
that contains a 'forged request' to execute commands with the victim's credentials. Prompting
a user to confirm or cancel the command might sound like a solution, but can be by-passed if
the prompt is scriptable. This lesson shows how to by-pass such a prompt by issuing another
forged request. This can also apply to a series of prompts such as a wizard or issuing multiple
unrelated forged requests.</p>
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains multiple
malicious requests: the first to transfer funds, and the second a request to confirm the prompt
that the first request triggered. The URL should point to the CSRF lesson with an extra
parameter "transferFunds=4000", and "transferFunds=CONFIRM". You can copy the shortcut from the
left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever
receives this email and happens to be authenticated at that time will have his funds transferred.
When you think the attack is successful, refresh the page and you will find the green check on
the left hand side menu.
<!-- Stop Instructions -->

37
webgoat/src/main/webapp/lesson_plans/en/CsrfTokenByPass.html Normal file
View File

@ -0,0 +1,37 @@
<div align="Center">
<p><b>Lesson Plan Title:</b>CSRF Token Prompt By-Pass</p><br/>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform CSRF attacks on sites that use tokens to mitigate CSRF attacks, but are vulnerable to CSS attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
<p>
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into
loading a page that contains a 'forged request' to execute commands with the
victim's credentials. </p>
<p>Token-based request authentication mitigates these attacks. This technique
inserts tokens into pages that issue requests. These tokens are required to
complete a request, and help verify that requests are not scripted. CSRFGuard from OWASP uses
this technique to help prevent CSRF attacks.</p>
<p>However, this technique can be by-passed if CSS vulnerabilities exist on the same site.
Because of the same-origin browser policy, pages from the same domain can read content from
other pages from the same domain. </p>
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains a malicious
request to transfer funds. To successfully complete you need to obtain a valid request token.
The page that presents the transfer funds form contains a valid request token. The URL for the
transfer funds page is the same as this lesson with an extra parameter "transferFunds=main". Load
this page, read the token and append the token in a forged request to transferFunds. When you think
the attack is successful, refresh the page and you will find the green check on the left hand side menu.
<!-- Stop Instructions -->

24
webgoat/src/main/webapp/lesson_plans/en/DBCrossSiteScripting.html Normal file
View File

@ -0,0 +1,24 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting
(XSS)</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
It is always a good practice to scrub all inputs, especially those
inputs that will later be used as parameters to OS commands, scripts,
and database queries. It is particularly important for content that will
be permanently stored somewhere. Users should not be able to create
message content that could cause another user to load an undesirable
page or undesirable content when the user's message is retrieved.
<br>
XSS can also occur when unvalidated user input is used in an HTTP
response. In a reflected XSS attack, an attacker can craft a URL with
the attack script and post it to another website, email it, or otherwise
get a victim to click on it.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
For this exercise, you will perform a stored XSS attack.
You will also implement code changes in the database to defeat
these attacks.
<br>

16
webgoat/src/main/webapp/lesson_plans/en/DBSQLInjection.html Normal file
View File

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

23
webgoat/src/main/webapp/lesson_plans/en/DOMInjection.html Normal file
View File

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

15
webgoat/src/main/webapp/lesson_plans/en/DOMXSS.html Normal file
View File

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

9
webgoat/src/main/webapp/lesson_plans/en/DOS_Login.html Normal file
View File

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

14
webgoat/src/main/webapp/lesson_plans/en/DangerousEval.html Normal file
View File

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

9
webgoat/src/main/webapp/lesson_plans/en/Encoding.html Normal file
View File

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

10
webgoat/src/main/webapp/lesson_plans/en/FailOpenAuthentication.html Normal file
View File

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

21
webgoat/src/main/webapp/lesson_plans/en/ForcedBrowsing.html Normal file
View File

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

9
webgoat/src/main/webapp/lesson_plans/en/ForgotPassword.html Normal file
View File

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

12
webgoat/src/main/webapp/lesson_plans/en/HiddenFieldTampering.html Normal file
View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Exploit Hidden Fields </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
Developers will use hidden fields for tracking, login, pricing, etc.. information on a loaded page. While this is a convenient and easy mechanism for the developer, they often don't validate the information that is received from the hidden field. This lesson will teach the attacker to find and modify hidden fields to obtain a product for a price other than the price specified <br>
<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.
<!-- Start Instructions -->
Try to purchase the HDTV for less than the purchase price, if you have not done so already.
<!-- Stop Instructions -->

49
webgoat/src/main/webapp/lesson_plans/en/HowToWork.html Normal file
View File

@ -0,0 +1,49 @@
<!-- Start Instructions -->
<h1>How To Work With WebGoat</h1>
<p>
Welcome to a short introduction to WebGoat.<br>
Here you will learn how to use WebGoat and additional tools for the lessons.<br><br>
</p>
<h2>Environment Information</h2>
<p>
WebGoat uses the Apache Tomcat server. It is configured to run on localhost although this can be
easily changed. This
configuration is for single user, additional users can be added in the tomcat-users.xml file.
If you want to use WebGoat in a laboratory or in
class you might need to change this setup. Please refer to the Tomcat Configuration
in the Introduction section.</p>
<h2>The WebGoat Interface</h2>
<p>
<img src="images/introduction/interface.jpg"><br><br>
1. These are Lesson Categories in WebGoat. Click on a Category to see all Lessons in it.<br>
2. This will show technical hints to solve the lesson.<br>
3. This will show the HTTP Request Parameters<br>
4. This will show the HTTP Request Cookies<br>
5. This will show goals and objectives of the lesson.<br>
6. This will show the underlying Java source code.<br>
7. This will show the complete solution of the selected lesson.<br>
8. If you want to restart a lesson you can use this link.</p>
<h2>Solve The Lesson</h2>
<p>
Always start with the lessons plan. Then try to solve the lesson and if necessary,
use the hints. The last hint is the solution text if applicable. If you cannot solve the lesson using the hints, you may view the
solution for complete details.</p>
<h2>Read And Edit Parameters</h2>
<p>
To read and edit Parameters you need a local proxy to intercept the HTTP request.
Here we use WebScarab. More information on WebScarab can be found in the "Useful Tools" Chapter.
After installing WebScarab and configuring your browser to use it as proxy on localhost we can start.<br><br>
<img src="images/introduction/HowToUse_1.jpg"><br><br>
We have to select "Intercept Request" in the tab "Intercept". If we send a HTTP request we get a new WebScarab window.<br><br>
<img src="images/introduction/HowToUse_2.jpg"><br><br>
Here we can read and edit the intercepted parameter. After "Accept changes" the request will be sent to the server.
</p>
<h2>Read And Edit Cookies</h2>
<p>
Often it is not only necessary to change the value of the parameters but to change the value of cookies.
We can use WebScarab to intercept the request and change cookies values just like parameter data as explained in the last topic.<br><br>
<img src="images/introduction/HowToUse_3.jpg"><br><br>
We get a new window on sending a HTTP request. On the screenshot you see where we can find cookies and how to edit the values of them.
</p>
<!-- Stop Instructions -->

12
webgoat/src/main/webapp/lesson_plans/en/HtmlClues.html Normal file
View File

@ -0,0 +1,12 @@
<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, TODO's, Code Broken, Hack, etc... inside the source code. &nbsp;Review the source code for any comments denoting&nbsp; passwords, backdoors, or something doesn't work right.&nbsp;
Below is an example of a forms based authentication form. Look for clues to help you log in.
<!-- Stop Instructions -->
<br>
<p><b>General Goal(s):</b> </p>
The user should be able to bypass the authentication check.

27
webgoat/src/main/webapp/lesson_plans/en/HttpBasics.html Normal file
View File

@ -0,0 +1,27 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Http Basics </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson presents the basics for understanding the transfer of data between the browser and the web application.<br>
<div align="Left">
<p>
<b>How HTTP works:</b>
</p>
All HTTP transactions follow the same general format. Each client request and server response has three parts: the request or response line, a header section, and the entity body. The client initiates a transaction as follows: <br>
<br>
The client contacts the server and sends a document request <br>
</div>
<br>
<ul>GET /index.html?param=value HTTP/1.0</ul>
Next, the client sends optional header information to inform the server of its configuration and the document formats it will accept.<br>
<br>
<ul>User-Agent: Mozilla/4.06 Accept: image/gif,image/jpeg, */*</ul>
After sending the request and headers, the client may send additional data. This data is mostly used by CGI programs using the POST method.<br>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
Enter your name in the input field below and press "go" to submit. The server will accept the request, reverse the input, and display it back to the user, illustrating the basics of handling an HTTP request.
<br/><br/>
The user should become familiar with the features of WebGoat by manipulating the above
buttons to view hints, show the HTTP request parameters, the HTTP request cookies, and the Java source code. You may also try using WebScarab for the first time.
<!-- Stop Instructions -->

26
webgoat/src/main/webapp/lesson_plans/en/HttpOnly.html Normal file
View File

@ -0,0 +1,26 @@
<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>For a list of supported browsers see: <a href=http://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly>OWASP HTTPOnly Support</a>
<p><b>General Goal(s):</b></p>
The purpose of this lesson is to test whether your browser supports the
HTTPOnly cookie flag. Note the value of the
<strong>unique2u</strong>
cookie. If your browser supports HTTPOnly, and you enable it for a
cookie, client side code should NOT be able to read OR write to that
cookie, but the browser can still send its value to the server. Some
browsers only prevent client side read access, but don't prevent write
access.
<br />
<br />
With the HTTPOnly attribute turned on, type
"javascript:alert(document.cookie)" in the browser address bar. Notice
all cookies are displayed except the unique2u cookie.
<!-- Stop Instructions -->

34
webgoat/src/main/webapp/lesson_plans/en/HttpSplitting.html Normal file
View File

@ -0,0 +1,34 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform HTTP Splitting </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform HTTP Splitting attacks.
<br />
<div align="Left">
<p>
<b>How the attack works:</b>
</p>
<p>The attacker passes malicious code to the web server together with normal input.
A victim application will not be checking for CR (carriage return, also given by %0d or \r)
and LF (line feed, also given by %0a or \n) characters. These characters not only give attackers control
of the remaining headers and body of the response the application intends to send,
but they also allows them to create additional responses entirely under their control.</p>
<p>The effect of an HTTP Splitting attack is maximized when accompanied with a Cache Poisoning. The goal of
Cache Poisoning attack is to poison the cache of the victim by fooling the cache into believing that the page
hijacked using the HTTP splitting is an authentic version of the server's copy.</p>
<p>The attack works by using the HTTP Splitting attack plus adding the <b>Last-Modified:</b> header and setting it
to a future date. This forces the browser to send an incorrect <b>If-Modified-Since</b> request header on future requests.
Because of this, the server will always report that the (poisoned) page has not changed, and the victim's browser
will continue to display the attacked version of the page.</p>
<p>A sample of a 304 response is:
<blockquote>HTTP/1.1 304 Not Modified <br />
Date: Fri, 30 Dec 2005 17:32:47 GMT</blockquote>
</p>
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
<p>This lesson has two stages. Stage 1 teaches you how to do HTTP Splitting attacks while stage 2 builds on that to teach you how to elevate HTTP Splitting to Cache Poisoning.</p>
<p>Enter a language for the system to search by. You will notice that the application is redirecting your request to another resource on the server. You should be able to use the CR (%0d) and LF (%0a) characters to exploit the attack. Your goal should be to force the server to send a 200 OK. If the screen changed as an effect to your attack, just go back to the homepage. After stage 2 is exploited successfully, you will find the green check in the left menu.</p>
<!-- Stop Instructions -->

14
webgoat/src/main/webapp/lesson_plans/en/InsecureLogin.html Normal file
View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Insecure Login</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
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.
<p><b>General Goal(s):</b> </p>
See how easy it is to sniff a password in plaintext.<br>
Understand the advantages of encrypting the login data!
<!-- Stop Instructions -->

24
webgoat/src/main/webapp/lesson_plans/en/JSONInjection.html Normal file
View File

@ -0,0 +1,24 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform JSON Injection </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform JSON Injection Attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
JavaScript Object Notation (JSON) is a simple and effective lightweight data exchange format. JSON can be in a lot of forms such as arrays, lists, hashtables and other data structures.
JSON is widely used in AJAX and Web2.0 application and is favored by programmers over XML because of its ease of use and speed.
However, JSON, like XML is prone to Injection attacks. A malicious attacker can inject the reply from the server and inject some arbitrary values in there.
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
* You are traveling from Boston, MA- Airport code BOS to Seattle, WA - Airport code SEA.<br>
* Once you enter the three digit code of the airport, an AJAX request will be executed asking for the ticket price.<br>
* You will notice that there are two flights available, an expensive one with no stops and another cheaper one with 2 stops.<br>
* Your goal is to try to get the one with no stops but for a cheaper price.
<!-- Stop Instructions -->

14
webgoat/src/main/webapp/lesson_plans/en/JavaScriptValidation.html Normal file
View File

@ -0,0 +1,14 @@
<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>
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.
<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>
<!-- Start Instructions -->
This website performs both client and server side validation. For this exercise, your job is to break the client side validation and send the
website input that it wasn't expecting. <b> You must break all 7 validators at the same time. </b>
<!-- Stop Instructions -->

17
webgoat/src/main/webapp/lesson_plans/en/Lesson_Plan_Template.html Normal file
View File

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

20
webgoat/src/main/webapp/lesson_plans/en/LogSpoofing.html Normal file
View File

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

20
webgoat/src/main/webapp/lesson_plans/en/MultiLevelLogin1.html Normal file
View File

@ -0,0 +1,20 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Multi Level Login 1</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
A Multi Level Login should provide a strong authentication.
This is archived by adding a second layer. After having
logged in with your user name and password you are asked
for a 'Transaction Authentication Number' (TAN). This is
often used by online banking. You get a list with a lots
of TANs generated only for you by the bank. Each TAN is used only once.
Another method is to provide the TAN by SMS. This has
the advantage that an attacker can not get TANs provided
by the user.
<p><b>General Goal(s):</b> </p>
In this Lesson you try to get around the strong authentication.
You have to break into another account. The user name, password and a
already used TAN is provided. You have to make sure
the server accept the TAN even it is already used.
<!-- Stop Instructions -->

20
webgoat/src/main/webapp/lesson_plans/en/MultiLevelLogin2.html Normal file
View File

@ -0,0 +1,20 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Multi Level Login 2</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
A Multi Level Login should provide a strong authentication.
This is archived by adding a second layer. After having
logged in with your user name and password you are asked
for a 'Transaction Authentication Number' (TAN). This is
often used by online banking. You get a list with a lots
of TANs generated only for you by the bank. Each TAN is used only once.
Another method is to provide the TAN by SMS. This has
the advantage that an attacker can not get TANs provided
by the user.
<p><b>General Goal(s):</b> </p>
In this lesson you have to try to break into another account.
You have an own account for WebGoat Financial but you want to
log into another account only knowing the user name of the victim
to attack.
<!-- Stop Instructions -->

13
webgoat/src/main/webapp/lesson_plans/en/NewLesson.html Normal file
View File

@ -0,0 +1,13 @@
<!-- Start Instructions -->
<h1>Create A WebGoat Lesson</h1>
<p>
Adding lessons to WebGoat is very easy. If you have an idea that would be suitable<br>
for a new lesson, follow these few simple instructions to implement it:<br><br>
* Download the source code from <a href="http://code.google.com/p/webgoat/">here.</a><br><br>
* Setup framework: follow the simple instructions in "HOW TO create the WebGoat workspace.txt" that comes with the project.<br><br>
* You need to add two files for each new lesson: <br>
&nbsp;&nbsp;- YourLesson.java to org.owasp.webgoat.lessons<br>
&nbsp;&nbsp;- YourLesson.html to WebContent/lesson_plans</p>
<!-- Stop Instructions -->

10
webgoat/src/main/webapp/lesson_plans/en/PasswordStrength.html Normal file
View File

@ -0,0 +1,10 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Password Strength</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Accounts are only as secure as their passwords. Most users have the same weak password everywhere. If you want to protect them against brute-force-attacks your application should have good requirements for passwords. The password should contain lower case letters, capitals and numbers. The longer the password, the better.
<!-- Stop Instructions -->
<br>
<p><b>General Goal(s):</b> </p>
For this exercise, your job is to test several passwords on <a href="https://www.cnlab.ch/codecheck" target="_blank">https://www.cnlab.ch/codecheck</a>

9
webgoat/src/main/webapp/lesson_plans/en/PathBasedAccessControl.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Bypass a Path Based Access Control Scheme </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
In a path based access control scheme, an attacker can traverse a path by providing relative path information. Therefore an attacker can use relative paths to access files that normally are not directly accessible by anyone, or would otherwise be denied if requested directly.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to access a file that is not in the listed directory.

16
webgoat/src/main/webapp/lesson_plans/en/Phishing.html Normal file
View File

@ -0,0 +1,16 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Phishing with 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.
With the help of XSS you can do a Phishing Attack and add content to a page
which looks official. It is very hard for a victim to determinate
that the content is malicious.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to add a form asking for username
and password. On submit the input should be sent
to http://localhost/WebGoat/catcher?PROPERTY=yes &user=catchedUserName&password=catchedPasswordName

13
webgoat/src/main/webapp/lesson_plans/en/ReflectedXSS.html Normal file
View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>How to Perform Reflected Cross Site Scripting (XSS)</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
It is always a good practice to validate all input on the server side.
XSS can occur when unvalidated user input is used in an HTTP response.
In a reflected XSS attack, an attacker can craft a URL with the attack
script and post it to another website, email it, or otherwise get a
victim to click on it.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
For this exercise, your mission is to come up with some input containing a script. You have to try to get this page to reflect that input back to your browser, which will execute the script and do something bad.

11
webgoat/src/main/webapp/lesson_plans/en/RemoteAdminFlaw.html Normal file
View File

@ -0,0 +1,11 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>How to Force Browser Web Resources</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
Applications will often have an administrative interface that allows privileged users access to functionality that normal users shouldn't see. The application server will often have an admin interface as well.
<p><b>Standards Addressed :</b> </p>
<p><b>General Goal(s):</b>
<!-- Start Instructions -->
Try to access the administrative interface for WebGoat. You may also try to access the administrative interface for Tomcat. The Tomcat admin interface can be accessed via a URL (/admin) and will not count towards the completion of this lesson.
<!-- Stop Instructions -->
</p>

15
webgoat/src/main/webapp/lesson_plans/en/RoleBasedAccessControl.html Normal file
View File

@ -0,0 +1,15 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Role Based Access Control</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
In role-based access control scheme, a role represents a set of access permissions and privileges. A user can be assigned one or more roles. A role-based access control normally consists of two parts: role permission management and role assignment. A broken role-based access control scheme might allow a user to perform accesses that are not allowed by his/her assigned roles, or somehow obtain unauthorized roles.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
Your goal is to explore the access control rules that govern this site. Each role has permission to certain resources (A-F). Each user is assigned one or more roles. Only the user with the [Admin] role should have access to the 'F' resources. In a successful attack, a user doesn't have the [Admin] role can access resource F.
<p><b>Lesson Resources:</b> </p>
<a href="lessons/RoleBasedAccessControl/images/orgChart.jpg" onclick="makeWindow(this.href, 'Org Chart');return false;" target="orgChartWin">Org Chart</a>
<br>
<a href="lessons/RoleBasedAccessControl/images/accessControl.jpg" onclick="makeWindow(this.href, 'Access Control Matrix');return false;" target="accessControlWin">Access Control Matrix</a>
<br>
<a href="lessons/RoleBasedAccessControl/images/dbSchema.jpg" onclick="makeWindow(this.href, 'Access Control Matrix');return false;" target="accessControlWin">Database Schema</a>

14
webgoat/src/main/webapp/lesson_plans/en/SQLInjection.html Normal file
View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform a SQL Injection </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible number of systems on the internet are susceptible to this form of attack.
<br><br>
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented.<br>
<br>
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queiries, even if the threat of SQL injection has been prevented in some other manner.<br>
<p><b>General Goal(s):</b> </p>
For this exercise, you will perform SQLInjection attacks. You will also implement code changes in the web application to defeat these attacks.
<!-- Stop Instructions -->

13
webgoat/src/main/webapp/lesson_plans/en/SameOriginPolicyProtection.html Normal file
View File

@ -0,0 +1,13 @@
<div align="Center">
<p><b>Lesson Plan Title: </b>Same Origin Policy Protection</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
A key element of AJAX is the XMLHttpRequest (XHR), which allows javascript to make asynchronous
calls from the client side to a server. However, as a security measure these requests may
only be made to the server from which the client page originated.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
This exercise demonstrates the Same Origin Policy Protection. XHR requests
can only be passed back to the originating server. Attempts to pass data to
a non-originating server will fail.";

33
webgoat/src/main/webapp/lesson_plans/en/SessionFixation.html Normal file
View File

@ -0,0 +1,33 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Session Fixation</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
How to steal a session with a 'Session Fixation'
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
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.
<br><br>
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.
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
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.
<!-- Stop Instructions -->

24
webgoat/src/main/webapp/lesson_plans/en/SilentTransactions.html Normal file
View File

@ -0,0 +1,24 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Silent Transactions Attacks. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform silent transactions attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
Any system that silently processes transactions using a single submission is dangerous to the client.
For example, if a normal web application allows a simple URL submission, a preset session attack will
allow the attacker to complete a transaction without the user’s authorization.
In Ajax, it gets worse: the transaction is silent; it happens with no user feedback on the page,
so an injected attack script may be able to steal money from the client without authorization.<br>
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
* This is a sample internet banking application - money transfer page.<br>
* It shows below your balance, the account you are transferring to and amount you will transfer.<br>
* The application uses AJAX to submit the transaction after doing some basic client side validations.<br>
* Your goal is to try to bypass the user's authorization and silently execute the transaction.<br>
<!-- Stop Instructions -->

9
webgoat/src/main/webapp/lesson_plans/en/SoapRequest.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Create a SOAP Request</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL). Let's learn something about WSDL files. Check out WebGoat's web service description language (WSDL) file.
<p><b>General Goal(s):</b> </p>
Try connecting to the WSDL with a browser or Web Service tool. The URL for the web service is: http://localhost/WebGoat/services/SoapRequest The WSDL can usually be viewed by adding a ?WSDL on the end of the web service request.
<!-- Stop Instructions -->

14
webgoat/src/main/webapp/lesson_plans/en/SqlNumericInjection.html Normal file
View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Numeric SQL Injection </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible number of systems on the internet are susceptible to this form of attack.
<br><br>
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented.<br>
<br>
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries, even if the threat of SQL injection has been prevented in some other manner.<br>
<p><b>General Goal(s):</b> </p>
The form below allows a user to view weather data. Try to inject an SQL string that results in all the weather data being displayed.
<!-- Stop Instructions -->

14
webgoat/src/main/webapp/lesson_plans/en/SqlStringInjection.html Normal file
View File

@ -0,0 +1,14 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform String SQL Injection </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
SQL injection attacks represent a serious threat to any database-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks, an incredible number of systems on the internet are susceptible to this form of attack.
<br><br>
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can easily be prevented.<br>
<br>
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries, even if the threat of SQL injection has been prevented in some other manner.<br>
<p><b>General Goal(s):</b> </p>
The form below allows a user to view their credit card numbers. Try to inject an SQL string that results in all the credit card numbers being displayed. Try the user name of 'Smith'.
<!-- Stop Instructions -->

9
webgoat/src/main/webapp/lesson_plans/en/StoredXss.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Stored Cross Site Scripting (XSS) </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
It is always a good practice to scrub all input, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere in the application. Users should not be able to create message content that could cause another user to load an undesireable page or undesireable content when the user's message is retrieved.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to add message content that cause another user to load an undesireable page or content.

22
webgoat/src/main/webapp/lesson_plans/en/ThreadSafetyProblem.html Normal file
View File

@ -0,0 +1,22 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Lesson Plan</title>
</head>
<body>
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Exploit Thread Safety Problems </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web applications can handle many HTTP requests simultaneously. Developers often use variables that are not thread safe. &nbsp;Thread safety means that the fields of an object or class always maintain a valid state when used concurrently by multiple threads. It is often possible to exploit a concurrency bug by loading the same page as another user at the exact same time. Because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently. <br>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to exploit the concurrency error in the web application and view login information for another user that is attempting the same function at the same time. <b>This will require the use of two browsers</b>.
<br>
</body>
</html>

114
webgoat/src/main/webapp/lesson_plans/en/TomcatSetup.html Normal file
View File

@ -0,0 +1,114 @@
<!-- Start Instructions -->
<h1>How To Configure Tomcat</h1><br><br>
<h2>Introduction</h2>
<p>WebGoat comes with default configurations for Tomcat. This page will explain these configurations
and other possible configurations for Tomcat. This is just
a short description which should be enough in most cases. For more advanced tasks please
refer to the Tomcat documentation. Please note that all solutions
are written for the standard configurations on port 80. If you use another port you have
to adjust the solution to your configuration.</p>
<h2>The Standard Configurations</h2>
<p>There are two standard Tomcat configurations. In the basic configurations you use the server on your localhost.
Both are identically with the only difference
that in one tomcat is running on port 80 and 443 (SSL) and in the other tomcat is running on port 8080 and 8443. In Linux you have
to start WebGoat as root or with sudo if you want to run it on port 80 and
443.
As running software as root is dangerous we strongly advice to use
the port 8080 and 8443. In Windows you can
run WebGoat.bat to run it on port 80 and WebGoat_8080.bat to run it on port 8080. In Linux you
can use webgoat.sh and run it with webgoat.sh start80 or webgoat.sh start8080. The user in these
configurations is guest with password guest
</p>
<h2>Server Configurations</h2>
<p>
If you are a single user of WebGoat the standard configurations should be
enough but if you want to use WebGoat in laboratory or in class there
might be the need to change the configurations. Before changing
the configurations we recommend doing a backup of the files you change.
</p>
<h3>Change Ports</h3>
<p>
To change the ports open the server_80.xml which you find in tomcat/conf and change the
non-SSL port. If you want to use it on port 8079 for example:
</p>
<pre>
&lt;!-- Define a non-SSL HTTP/1.1 Connector on port 8079 --&gt;
&lt;Connector address=&quot;127.0.0.1&quot; port=&quot;8079&quot;...
</pre>
<p>
You can also change the SSL connector to another port of course.
In this example to port 8442:
</p>
<pre>
&lt;!-- Define a SSL HTTP/1.1 Connector on port 8442 --&gt;
&lt;Connector address=&quot;127.0.0.1&quot; port=&quot;8442&quot;...
</pre>
<br>
<h3>Make WebGoat Reachable From Another Client</h3>
<p>THIS MAKES IT POSSIBLE TO REALLY ATTACK YOUR SERVER! DO NOT DO THIS
UNTIL YOU KNOW WHAT YOU ARE DOING. THIS CONFIGURATION SHOULD BE ONLY USED IN
SAFE NETWORKS!</p>
<p>By its default configurations WebGoat is only
reachable within the localhost. In a laboratory or a class
there is maybe the need of having a server and a few clients.
In this case it is possible to make WebGoat reachable.
</p>
<p>The reason why WebGoat is only reachable within the localhost is
the parameter address in the connectors for the non-SSL and SSL connection in server_80.xml. It is set
to 127.0.0.1. The applications only listens on the port of this address for
incoming connections if it is set. If you remove this parameter the server listens on all IPs on the
specific port.</p>
<h3>Permit Only Certain Clients Connection</h3>
<p>
If you have made WebGoat reachable it is reachable for
all clients. If you want to make it reachable only for certain clients specified
by there IP you can archive this by using a 'Remote Address Filter'.
The filter can be set in a whitebox or blackbox approach. Here is
only discussed the whitebox approach. You have to add following lines to the Host section of web_80.xml:
</p>
<pre>
&lt;Valve className=&quot;org.apache.catalina.valves.RemoteAddrValve&quot;
allow=&quot;127.0.0.1,ip1,ip2&quot;/&gt;
</pre>
<p>In this case only localhost, ip1 and ip2 are permitted to connect.</p>
<h2>WebGoat Default Users and Roles for Tomcat</h2>
<p>
WebGoat requires the following users and roles to be configured in order for the application to run.
<br/>
<pre>
&gt;role rolename="webgoat_basic"/&lt;
&gt;role rolename="webgoat_admin"/&lt;
&gt;role rolename="webgoat_user"/&lt;
&gt;user username="webgoat" password="webgoat" roles="webgoat_admin"/&lt;
&gt;user username="basic" password="basic" roles="webgoat_user,webgoat_basic"/&lt;
&gt;user username="guest" password="guest" roles="webgoat_user"/&lt;
</pre>
</p>
<h2>Adding Users</h2>
<p>
Usually using WebGoat you just use the user guest with the password guest.
But maybe in laboratory you have made a setup with one server and a lot of
clients. In this case you might want to have a user for every client
and you have to alter tomcat-users.xml
in tomcat/conf as the users are stored there. <b>We recommend not to use real passwords
as the passwords are stored in plain text in this file!</b>
</p>
<h3>Add User</h3>
<p>
Adding a user is straight forward. You can use the guest entry as an example. The added
users should have the same role as the guest user. Add lines like this to the file:
</p>
<pre>
&lt;user name=&quot;student1&quot; password=&quot;password1&quot; roles=&quot;webgoat_user&quot;/&gt;
&lt;user name=&quot;student2&quot; password=&quot;password2&quot; roles=&quot;webgoat_user&quot;/&gt;
...
</pre>
<!-- Stop Instructions -->

9
webgoat/src/main/webapp/lesson_plans/en/TraceXSS.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Tracing (XST) Attacks </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
It is always a good practice to scrub all input, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere in the application. Users should not be able to create message content that could cause another user to load an undesireable page or undesireable content when the user's message is retrieved.
<p><b>General Goal(s):</b> </p>
Tomcat is configured to support the HTTP TRACE command. Your goal is to perform a Cross Site Tracing (XST) attack.
<!-- Stop Instructions -->

9
webgoat/src/main/webapp/lesson_plans/en/UncheckedEmail.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Exploit Unchecked Email </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
It is always a good practice to validate all inputs. Most sites allow non-authenticated users to send email to a 'friend'. This is a great mechanism for spammers to send out email using your corporate mail server.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
The user should be able to send and obnoxious email message.

44
webgoat/src/main/webapp/lesson_plans/en/UsefulTools.html Normal file
View File

@ -0,0 +1,44 @@
<!-- Start Instructions -->
<h1>Useful Tools</h1>
<p>
Below is a list of tools we've found useful in solving the WebGoat lessons. You will need WebScarab or Paros to solve most of the lessons. </p>
<h2>WebScarab:</h2>
<p>
Like WebGoat, WebScarab is a part of OWASP.
WebScarab is a proxy for analyzing applications that
communicate using the HTTP and HTTPS protocols. Because WebScarab
operates as an intercepting proxy, we can review and modify requests
and responses.<br><br>
<img src="images/introduction/webscarab.jpg"><br><br>
Webpage:<a href="http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project">http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project</a>
</p>
<h2>Firebug:</h2>
<p>
Firebug is an add-on for the Firefox browser. We can use it to inspect, edit and monitor CSS, HTML and JavaScript.<br><br>
<img src="images/introduction/firebug.jpg"><br><br>
Webpage:<a href="http://www.getfirebug.com" target="_blank">http://www.getfirebug.com</a>
<br><br>
<h2>IEWatch:</h2>
<p>
IEWatch is a tool to analyze HTTP and HTML for users of the Internet Explorer.<br><br>
<img src="images/introduction/iewatch.jpg"><br><br>
Webpage:<a href="http://www.iewatch.com" target="_blank">http://www.iewatch.com</a>
</p>
<h2>Wireshark</h2>
<p>
Wireshark is a network protocol analyzer. You can sniff network traffic and gather useful
informations this way.<br><br>
<img src="images/introduction/wireshark.png"><br><br>
Webpage:<a href="http://www.wireshark.org" target="_blank">http://www.wireshark.org</a>
</p>
<h2>Scanner:</h2>
<p>
There are many vulnerability scanners for your own web applications. They can find XSS, Injection Flaws and other vulnerabilities. Below are links to two open source scanner. <br><br>
Nessus:<a href="http://www.nessus.org" target="_blank">http://www.nessus.org</a><br>
Paros:<a href="http://www.parosproxy.org" target="_blank">http://www.parosproxy.org</a><br>
</p>
<!-- Stop Instructions -->
<br>

9
webgoat/src/main/webapp/lesson_plans/en/WSDLScanning.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform WSDL Scanning</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL) file.
<p><b>General Goal(s):</b> </p>
This screen is the API for a web service. Check the WSDL file for this web service and try to get some customer credit numbers.
<!-- Stop Instructions -->

12
webgoat/src/main/webapp/lesson_plans/en/WeakAuthenticationCookie.html Normal file
View File

@ -0,0 +1,12 @@
<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>
Many applications will automatically log a user into their site if the right authentication cookie is specified. &nbsp; Some times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. &nbsp;Some times the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. &nbsp;Some times the cookies maybe intercepted using Cross site scripting. &nbsp;This lesson tries to make the student aware of authentication cookies and presents the student with a way to defeat the cookie authentication method in this lesson.<br>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
The user should be able to bypass the authentication check.
Login using the webgoat/webgoat account to see what happens. You may also try aspect/aspect. When you understand the authentication cookie, try changing your identity to alice.
<!-- Stop Instructions -->

9
webgoat/src/main/webapp/lesson_plans/en/WeakSessionID.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Hijack a Session</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Application developers who develop their own session IDs frequently forget to incorporate the complexity and randomness necessary for security. If the user specific session ID is not complex and random, then the application is highly susceptible to session-based brute force attacks.
<p><b>General Goal(s):</b> </p>
Try to access an authenticated session belonging to someone else.
<!-- Stop Instructions -->

16
webgoat/src/main/webapp/lesson_plans/en/WelcomeScreeen.html Normal file
View File

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

12
webgoat/src/main/webapp/lesson_plans/en/WsSAXInjection.html Normal file
View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Web Service SAX Injection</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL) file.
<p><b>General Goal(s):</b> </p>
Some web interfaces make use of Web Services in the background. If the frontend relies on the web service for all input validation, it may be possible to corrupt the XML that the web interface sends.
<br/>
<br>
In this exercise, try to change the password for a user other than 101.
<!-- Stop Instructions -->

9
webgoat/src/main/webapp/lesson_plans/en/WsSqlInjection.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Web Service SQL Injection</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web Services communicate through the use of SOAP requests. These requests are submitted to a web service in an attempt to execute a function defined in the web service definition language (WSDL) file.
<p><b>General Goal(s):</b> </p>
Check the web service description language (WSDL) file and try to obtain multiple customer credit card numbers. You will not see the results returned to this screen. When you believe you have suceeded, refresh the page and look for the 'green star'.
<!-- Stop Instructions -->

19
webgoat/src/main/webapp/lesson_plans/en/XMLInjection.html Normal file
View File

@ -0,0 +1,19 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform XML Injection Attacks. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform XML Injection attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
AJAX applications use XML to exchange information with the server. This XML can be easily intercepted and altered by a malicious attacker.
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
WebGoat-Miles Reward Miles shows all the rewards available. Once you've entered your account ID, the lesson will show you your balance and the products you can afford. Your goal is to try to add more rewards to your allowed set of rewards. Your account ID is 836239.
<!-- Stop Instructions -->

22
webgoat/src/main/webapp/lesson_plans/en/XPATHInjection.html Normal file
View File

@ -0,0 +1,22 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform XPATH Injection Attacks. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform XPath Injection attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
Similar to SQL Injection, XPATH Injection attacks occur when a web site uses user supplied information to query XML data. By sending intentionally malformed information into the web site, an attacker can find out how the XML data is structured or access data that they may not normally have access to.
They may even be able to elevate their privileges on the web site if the xml data is being used for authentication (such as an xml based user file).
Querying XML is done with XPath, a type of simple descriptive statement that allows the xml query to locate a piece of information. Like SQL you can specify certain attributes to find and patterns to match. When using XML for a web site it is common to accept some form of input on the query string to identify the content to locate and display on the page. This input must be sanitized to verify that it doesn't mess up the XPath query and return the wrong data.
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
The form below allows employees to see all their personal data including their salaries. Your account is Mike/test123. Your goal is to try to see other employees data as well.
<!-- Stop Instructions -->

9
webgoat/src/main/webapp/lesson_plans/ru/AccessControlMatrix.html Normal file
View File

@ -0,0 +1,9 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> Using an Access Control Matrix</p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
In a role-based access control scheme, a role represents a set of access permissions and privileges. A user can be assigned one or more roles. A role-based access control scheme normally consists of two parts: role permission management and role assignment. A broken role-based access control scheme might allow a user to perform accesses that are not allowed by his/her assigned roles, or somehow allow privilege escalation to an unauthorized role.
<p><b>General Goal(s):</b> </p>
Each user is a member of a role that is allowed to access only certain resources. Your goal is to explore the access control rules that govern this site. Only the [Admin] group should have access to the 'Account Manager' resource.
<!-- Stop Instructions -->

23
webgoat/src/main/webapp/lesson_plans/ru/BackDoors.html Normal file
View File

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

9
webgoat/src/main/webapp/lesson_plans/ru/BasicAuthentication.html Normal file
View File

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

15
webgoat/src/main/webapp/lesson_plans/ru/BlindSqlInjection.html Normal file
View File

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

9
webgoat/src/main/webapp/lesson_plans/ru/BufferOverflow.html Normal file
View File

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

26
webgoat/src/main/webapp/lesson_plans/ru/CSRF.html Normal file
View File

@ -0,0 +1,26 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Request Forgery. </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform Cross Site Request Forgery (CSRF) attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into loading a page that contains img links like the one below:
<pre>&lt;img src="<a href="http://www.mybank.com/transferFunds.do?acctId=123456" class='external free' title="http://www.mybank.com/transferFunds.do?acctId=123456" rel="nofollow">http://www.mybank.com/sendFunds.do?acctId=123456</a>"/&gt;</pre>
When the victim's browser attempts to render this page, it will issue a request to www.mybank.com to the transferFunds.do page with the specified parameters. The browser will think the link is to get an image, even though it actually is a funds transfer function.
The request will include any cookies associated with the site. Therefore, if the user has authenticated to the site, and has either a permanent cookie or even a current session cookie, the site will have no way to distinguish this from a legitimate user request.
In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, or any other function provided by the vulnerable website
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
Your goal is to send an email to a newsgroup that contains an image whose URL is pointing to a malicious request. Try to include a 1x1 pixel image that includes a URL. The URL should point to the CSRF lesson with an extra parameter "transferFunds=4000". You can copy the shortcut from the left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever receives this email and happens to be authenticated at that time will have his funds transferred. When you think the attack is successful, refresh the page and you will find the green check on the left hand side menu.
<!-- Stop Instructions -->

7
webgoat/src/main/webapp/lesson_plans/ru/ChallengeScreen.html Normal file
View File

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

12
webgoat/src/main/webapp/lesson_plans/ru/ClientSideFiltering.html Normal file
View File

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

15
webgoat/src/main/webapp/lesson_plans/ru/ClientSideValidation.html Normal file
View File

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

12
webgoat/src/main/webapp/lesson_plans/ru/CommandInjection.html Normal file
View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Command Injection</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
Command&nbsp; injection attacks represent a serious threat to any parameter-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks an incredible number of systems on the internet are susceptible to this form of attack.<br/>
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can be almost totally prevented. This lesson will show the student several examples of parameter injection.<br/>
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries.<br/>
Try to inject a command to the operating system.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
The user should be able to execute any command on the hosting OS.

22
webgoat/src/main/webapp/lesson_plans/ru/ConcurrencyCart.html Normal file
View File

@ -0,0 +1,22 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title>Lesson Plan</title>
</head>
<body>
<div align="Center">
<p><b>Lesson Plan Title:</b> Shopping Cart Concurrency Flaw </p>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
<!-- Start Instructions -->
Web applications can handle many HTTP requests simultaneously. Developers often use variables that are not thread safe. &nbsp;Thread safety means that the fields of an object or class always maintain a valid state when used concurrently by multiple threads. It is often possible to exploit a concurrency bug by loading the same page as another user at the exact same time. Because all threads share the same method area, and the method area is where all class variables are stored, multiple threads can attempt to use the same class variables concurrently. <br>
<!-- Stop Instructions -->
<p><b>General Goal(s):</b> </p>
For this exercise, your mission is to exploit the concurrency issue which will allow you to purchase merchandise for a lower price.
<br>
</body>
</html>

12
webgoat/src/main/webapp/lesson_plans/ru/CrossSiteScripting.html Normal file
View File

@ -0,0 +1,12 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting (XSS)</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
It is always a good practice to scrub all inputs, especially those inputs that will later be used as parameters to OS commands, scripts, and database queries. It is particularly important for content that will be permanently stored somewhere. Users should not be able to create message content that could cause another user to load an undesirable page or undesirable content when the user's message is retrieved.<br>
XSS can also occur when unvalidated user input is used in an HTTP response. In a reflected XSS attack, an attacker can craft a URL with the attack script and post it to another website, email it, or otherwise get a victim to click on it.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
For this exercise, you will perform stored and reflected XSS attacks. You will also implement code changes in the web application to defeat these attacks.
<br>

32
webgoat/src/main/webapp/lesson_plans/ru/CsrfPromptByPass.html Normal file
View File

@ -0,0 +1,32 @@
<div align="Center">
<p><b>Lesson Plan Title:</b>CSRF User Prompt By-Pass</p><br/>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform CSRF attacks that by-pass user confirmation prompts.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
<p>
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into loading a page
that contains a 'forged request' to execute commands with the victim's credentials. Prompting
a user to confirm or cancel the command might sound like a solution, but can be by-passed if
the prompt is scriptable. This lesson shows how to by-pass such a prompt by issuing another
forged request. This can also apply to a series of prompts such as a wizard or issuing multiple
unrelated forged requests.</p>
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains multiple
malicious requests: the first to transfer funds, and the second a request to confirm the prompt
that the first request triggered. The URL should point to the CSRF lesson with an extra
parameter "transferFunds=4000", and "transferFunds=CONFIRM". You can copy the shortcut from the
left hand menu by right clicking on the left hand menu and choosing copy shortcut. Whoever
receives this email and happens to be authenticated at that time will have his funds transferred.
When you think the attack is successful, refresh the page and you will find the green check on
the left hand side menu.
<!-- Stop Instructions -->

37
webgoat/src/main/webapp/lesson_plans/ru/CsrfTokenByPass.html Normal file
View File

@ -0,0 +1,37 @@
<div align="Center">
<p><b>Lesson Plan Title:</b>CSRF Token Prompt By-Pass</p><br/>
</div>
<p><b>Concept / Topic To Teach:</b> </p>
This lesson teaches how to perform CSRF attacks on sites that use tokens to mitigate CSRF attacks, but are vulnerable to CSS attacks.
<br>
<div align="Left">
<p>
<b>How the attacks works:</b>
</p>
<p>
Cross-Site Request Forgery (CSRF/XSRF) is an attack that tricks the victim into
loading a page that contains a 'forged request' to execute commands with the
victim's credentials. </p>
<p>Token-based request authentication mitigates these attacks. This technique
inserts tokens into pages that issue requests. These tokens are required to
complete a request, and help verify that requests are not scripted. CSRFGuard from OWASP uses
this technique to help prevent CSRF attacks.</p>
<p>However, this technique can be by-passed if CSS vulnerabilities exist on the same site.
Because of the same-origin browser policy, pages from the same domain can read content from
other pages from the same domain. </p>
</div>
<p><b>General Goal(s):</b> </p>
<!-- Start Instructions -->
Similar to the CSRF Lesson, your goal is to send an email to a newsgroup that contains a malicious
request to transfer funds. To successfully complete you need to obtain a valid request token.
The page that presents the transfer funds form contains a valid request token. The URL for the
transfer funds page is the same as this lesson with an extra parameter "transferFunds=main". Load
this page, read the token and append the token in a forged request to transferFunds. When you think
the attack is successful, refresh the page and you will find the green check on the left hand side menu.
<!-- Stop Instructions -->

24
webgoat/src/main/webapp/lesson_plans/ru/DBCrossSiteScripting.html Normal file
View File

@ -0,0 +1,24 @@
<div align="Center">
<p><b>Lesson Plan Title:</b> How to Perform Cross Site Scripting
(XSS)</p>
</div>
<p><b>Concept / Topic To Teach:</b></p>
<!-- Start Instructions -->
It is always a good practice to scrub all inputs, especially those
inputs that will later be used as parameters to OS commands, scripts,
and database queries. It is particularly important for content that will
be permanently stored somewhere. Users should not be able to create
message content that could cause another user to load an undesirable
page or undesirable content when the user's message is retrieved.
<br>
XSS can also occur when unvalidated user input is used in an HTTP
response. In a reflected XSS attack, an attacker can craft a URL with
the attack script and post it to another website, email it, or otherwise
get a victim to click on it.
<!-- Stop Instructions -->
<p><b>General Goal(s):</b></p>
For this exercise, you will perform a stored XSS attack.
You will also implement code changes in the database to defeat
these attacks.
<br>

16
webgoat/src/main/webapp/lesson_plans/ru/DBSQLInjection.html Normal file
View File

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

23
webgoat/src/main/webapp/lesson_plans/ru/DOMInjection.html Normal file
View File

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

15
webgoat/src/main/webapp/lesson_plans/ru/DOMXSS.html Normal file
View File

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

9
webgoat/src/main/webapp/lesson_plans/ru/DOS_Login.html Normal file
View File

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

14
webgoat/src/main/webapp/lesson_plans/ru/DangerousEval.html Normal file
View File

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

9
webgoat/src/main/webapp/lesson_plans/ru/Encoding.html Normal file
View File

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

Some files were not shown because too many files have changed in this diff Show More