A first attempt at internationalization of WebGoat. For complete internationalization WebGoat needs two things:
1. Every text passage/label that appears in lessons must independent of the current language set for WebGoat.
2. Every lesson plan and solutions must be translated for each supported language.
Number 1 is achieved by using webgoat/util/WebgoatI18N.java and by having every output routed through this piece of code. You no longer say hints.add("Lesson Hint 1"); or ....addElement("Shopping Cart")) but you in the lesson you say hints.add(WebGoatI18N.get("Lesson Hint1")) or ....addElement(WebGoatI18N.get("Shopping Cart"). Then WebGoatI18N looks up the corresponding string for the language set as the current lanuage and returns it.
Number 2 is achieved by having subdirectories in lesson_plans corresponding to every language. That means, a lesson that has been translated to Spanish and German will be found in lesson_plans/English and lesson_plans/Spanish and lesson_plans/German.
This is how WebGoat finds out about available languages: in Course.java in loadResources() it looks for lesson plans.
Unlike before, now a lesson plan can be found multiple times in different "language" directories. So for every directory the lesson plan is found in, WebGoat associates this language with the lesson and also lets WebGoatI18N load the appropriate WebGoatLabels_$LANGAUGE$.properties file which contains the translations of labels.
So this is what you have to do for a new language:
First of all, you have to copy and translate every lesson plan that you need in the new language, and then you also have to create a WebGoatLabels_$LANGUAGE$.properties file with that labels that will be used in these lessons. Atm WebGoat crashes throws an exception when a label is missing but this can be sorted out quickly.
git-svn-id: http://webgoat.googlecode.com/svn/trunk/webgoat@389 4033779f-a91e-0410-96ef-6bf7bf53c507
This commit is contained in:
mjawurek
@ -6,6 +6,7 @@
|
||||
Command injection attacks represent a serious threat to any parameter-driven site. The methods behind an attack are easy to learn and the damage caused can range from considerable to complete system compromise. Despite these risks an incredible number of systems on the internet are susceptible to this form of attack.<br/>
|
||||
Not only is it a threat easily instigated, it is also a threat that, with a little common-sense and forethought, can be almost totally prevented. This lesson will show the student several examples of parameter injection.<br/>
|
||||
It is always good practice to sanitize all input data, especially data that will used in OS command, scripts, and database queries.<br/>
|
||||
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.
|
||||
@ -2,8 +2,11 @@
|
||||
<p><b>Lesson Plan Title:</b> How to Exploit Hidden Fields </p>
|
||||
</div>
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
|
||||
Developers will use hidden fields for tracking, login, pricing, etc.. information on a loaded page. While this is a 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>
|
||||
<!-- Stop Instructions -->
|
||||
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
The user should be able to exploit a hidden field to obtain a product at an incorrect price.
|
||||
<!-- Start Instructions -->
|
||||
Try to purchase the HDTV for less than the purchase price, if you have not done so already.
|
||||
<!-- Stop Instructions -->
|
||||
@ -5,7 +5,8 @@
|
||||
<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. Review the source code for any comments denoting passwords, backdoors, or something doesn't work right.
|
||||
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.
|
||||
The user should be able to bypass the authentication check.
|
||||
@ -2,9 +2,13 @@
|
||||
<p><b>Lesson Plan Title:</b> How to Bypass Client Side JavaScript Validation </p>
|
||||
</div>
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
|
||||
Client-side validation should not be considered a secure means of validating parameters. These 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.
|
||||
<!-- Stop Instructions -->
|
||||
|
||||
<br>
|
||||
<p><b>General Goal(s):</b> </p>
|
||||
For this exercise, the web site requires that you follow certain rules when you fill out a form. The user should be able to break those rules, and send the website input that it wasn't expecting. <br>
|
||||
<!-- 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 -->
|
||||
@ -1,114 +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>
|
||||
<!-- Define a non-SSL HTTP/1.1 Connector on port 8079 -->
|
||||
<Connector address="127.0.0.1" port="8079"...
|
||||
</pre>
|
||||
<p>
|
||||
You can also change the SSL connector to another port of course.
|
||||
In this example to port 8442:
|
||||
</p>
|
||||
<pre>
|
||||
<!-- Define a SSL HTTP/1.1 Connector on port 8442 -->
|
||||
<Connector address="127.0.0.1" port="8442"...
|
||||
<!-- 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>
|
||||
<!-- Define a non-SSL HTTP/1.1 Connector on port 8079 -->
|
||||
<Connector address="127.0.0.1" port="8079"...
|
||||
</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>
|
||||
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
|
||||
allow="127.0.0.1,ip1,ip2"/>
|
||||
</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>
|
||||
>role rolename="webgoat_basic"/<
|
||||
>role rolename="webgoat_admin"/<
|
||||
>role rolename="webgoat_user"/<
|
||||
>user username="webgoat" password="webgoat" roles="webgoat_admin"/<
|
||||
>user username="basic" password="basic" roles="webgoat_user,webgoat_basic"/<
|
||||
>user username="guest" password="guest" roles="webgoat_user"/<
|
||||
</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>
|
||||
<user name="student1" password="password1" roles="webgoat_user"/>
|
||||
<user name="student2" password="password2" roles="webgoat_user"/>
|
||||
...
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
You can also change the SSL connector to another port of course.
|
||||
In this example to port 8442:
|
||||
</p>
|
||||
<pre>
|
||||
<!-- Define a SSL HTTP/1.1 Connector on port 8442 -->
|
||||
<Connector address="127.0.0.1" port="8442"...
|
||||
</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>
|
||||
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
|
||||
allow="127.0.0.1,ip1,ip2"/>
|
||||
</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>
|
||||
>role rolename="webgoat_basic"/<
|
||||
>role rolename="webgoat_admin"/<
|
||||
>role rolename="webgoat_user"/<
|
||||
>user username="webgoat" password="webgoat" roles="webgoat_admin"/<
|
||||
>user username="basic" password="basic" roles="webgoat_user,webgoat_basic"/<
|
||||
>user username="guest" password="guest" roles="webgoat_user"/<
|
||||
</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>
|
||||
<user name="student1" password="password1" roles="webgoat_user"/>
|
||||
<user name="student2" password="password2" roles="webgoat_user"/>
|
||||
...
|
||||
</pre>
|
||||
|
||||
<!-- Stop Instructions -->
|
||||
@ -3,8 +3,10 @@
|
||||
</div>
|
||||
|
||||
<p><b>Concept / Topic To Teach:</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
|
||||
Many applications will automatically log a user into their site if the right authentication cookie is specified. Some times the cookie values can be guessed if the algorithm for generating the cookie can be obtained. Some times the cookies are left on the client machine and can be stolen by exploiting another system vulnerability. Some times the cookies maybe intercepted using Cross site scripting. This lesson tries to make the student aware of authentication cookies and presents the student with a way to defeat the cookie authentication method in this lesson.<br>
|
||||
<!-- Stop Instructions -->
|
||||
<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 -->
|
||||
@ -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<63>tzen. Wird eine Anfrage an eine gesch<63>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<75>ck falls die <20>bermittelten Zugangsdaten korrekt sind.
|
||||
Die Zugangsdaten werden vom Browser bei jedem weiteren Zugriff auf gesch<63>tzte Resourcen mitgesendet ohne dass der Benutzer
|
||||
sie ein weiteres Mal eingeben muss.<br/>
|
||||
<br/>
|
||||
<p><b>Grundsätzliche(s) Ziel(e):</b></p>
|
||||
Das Ziel dieser Lektion ist es "Basic Authentication" zu verstehen und die folgenden Fragen zu beantworten.
|
||||
<!-- Stop Instructions -->
|
||||
@ -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<75>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ätzliche(s) Ziel(e):</b></p>
|
||||
<!-- Start Instructions -->
|
||||
Schleusen Sie einen Befehl in das darunterliegende Betriebssystem ein.
|
||||
<!-- Stop Instructions -->
|
||||
@ -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<70>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ätzliche(s) Ziel(e):</b> </p>
|
||||
Nutzen Sie ein verstecktes Formularfeld aus, um den HD Fernseher zu einem falschen Preis zu kaufen.
|
||||
13
main/project/WebContent/lesson_plans/German/HtmlClues.html
Normal file
13
main/project/WebContent/lesson_plans/German/HtmlClues.html
Normal 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<73>rtern, Hintert<72>ren oder anderen Unregelm<6C><6D>igkeiten aussieht.
|
||||
<!-- Stop Instructions -->
|
||||
|
||||
<br>
|
||||
<p><b>Grundsätzliche(s) Ziel(e):</b> </p>
|
||||
Sie suchen und finden Hinweise im Quellcode die es Ihnen erlauben sich anzumelden.
|
||||
29
main/project/WebContent/lesson_plans/German/HttpBasics.html
Normal file
29
main/project/WebContent/lesson_plans/German/HttpBasics.html
Normal 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ändnis-Grundlagen fü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ächstes sendet der Client optionale Kopfzeilen (Header) um den Server ü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ätzliche(s) Ziel(e):</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
Geben Sie Ihren Namen in das Eingabefeld ein und dr<64>cken sie "Los gehts!" um die Anfrage abzuschicken. Der Server wird die Anfrage akzeptieren, Ihre Eingabedaten umdrehen, und wieder zu Ihnen zur<75>ckschicken. Dies stellt eine vollständige HTTP Transaktion dar!
|
||||
<br/><br/>
|
||||
Sie sollten mit der Benutzung von WebGoat vertraut werden. Es sollten die Kn<4B>pfe für Hinweise (Hints), für das Anzeigen von Parametern(Parameters) oder Cookies und für das Anzeigen von Java-Quellcode ausprobiert werden.
|
||||
Au<EFBFBD>erdem, können Sie hier WebScarab gut ausprobieren.
|
||||
<!-- Stop Instructions -->
|
||||
@ -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<4D>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ätzliche(s) Ziel(e):</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
Das untenstehende Formular verlangt von Ihnen verschiedene Regeln beim Ausf<73>llen einzuhalten. Dies wird Client-seitig
|
||||
<EFBFBD>berpr<EFBFBD>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
main/project/WebContent/lesson_plans/German/LogSpoofing.html
Normal file
17
main/project/WebContent/lesson_plans/German/LogSpoofing.html
Normal file
@ -0,0 +1,17 @@
|
||||
<div align="Center">
|
||||
<p><b>Lehrplan:</b> F<>lschen von Eintr<74>gen in Log Dateien (Log Spoofing) </p>
|
||||
</div>
|
||||
|
||||
<p><b>Konzept:</b> </p>
|
||||
<p>
|
||||
Log-Eintr<74>ge in Log-Dateien m<>ssen nicht immer von tats<74>chlichen Ereignissen stammen. Ein Angreifer kann durch Einschleusen
|
||||
bestimmter Eintr<74>ge das Eintreten bestimmter Ereignisse vort<72>uschen und dadurch den Administrator zu unn<6E>tigen bzw. voreiligen
|
||||
Handlungen verleiten bzw. ihn einfach nur verwirren.
|
||||
</p>
|
||||
|
||||
<p><b>Grundsätzliche(s) Ziel(e):</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
* Der graue Bereich steht f<>r das was tats<74>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 -->
|
||||
@ -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 <20>bergibt. Dadurch kann der Angreifer auf Dateien zugreifen, die f<>r niemanden zug<75>nglich sind, bzw. zu denen
|
||||
der Zugang bei direkter Anfrage ansonsten abgelehnt w<>rde.
|
||||
<!-- Stop Instructions -->
|
||||
<p><b>Grundsätzliche(s) Ziel(e):</b> </p>
|
||||
Sie sollten in der Lage sein auf eine Datei zuzugreifen die sich nicht im aufgelisteten Verzeichnis befindet.
|
||||
@ -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 <20>berpr<70>ft werden.
|
||||
XSS passiert wenn nicht gepr<70>fte Benutereingaben in eine HTTP Response eingebaut werden.
|
||||
Bei einem reflektierten XSS Angriff, kann ein Angreifer eine URL erzeugen die ein Angriffsskript enth<74>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<53>ck Javascript zu <20>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<65>hrt wird.
|
||||
<!-- Stop Instructions -->
|
||||
@ -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<69>t erm<72>glicht die
|
||||
f<EFBFBD>r normale Benutzer nicht sichtbar ist. Der Applikationsserver selbst hat auch oft noch eine seperate Administrationsschnittstelle.
|
||||
|
||||
<p><b>Grundsä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 <20>ber die URL /admin erreicht werden, z<>hlt aber nicht
|
||||
f<EFBFBD>r das Bestehen dieser Lektion.
|
||||
Wenn Sie Zugriff auf Funktionalit<69>t der Administrationsschnittstelle erlangt haben, dann kommen Sie hierher zur<75>ck um zu sehen ob Sie
|
||||
die Lektion abgeschlossen haben.
|
||||
<!-- Stop Instructions -->
|
||||
</p>
|
||||
@ -0,0 +1,18 @@
|
||||
<div align="Center">
|
||||
<p><b>Lehrplan:</b> Durchf<68>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<75>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ätzliche(s) Ziel(e):</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
Das untenstehende Formular erm<72>glicht es dem Benutzer Wetterdaten zu betrachten. Versuchen Sie einen SQL String einzuschleusen, der
|
||||
als Resultat alle Wetterdaten anzeigt.
|
||||
<!-- Stop Instructions -->
|
||||
@ -0,0 +1,20 @@
|
||||
<div align="Center">
|
||||
<p><b>Lehrplan:</b> Durchf<68>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<75>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ä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
main/project/WebContent/lesson_plans/German/StoredXss.html
Normal file
16
main/project/WebContent/lesson_plans/German/StoredXss.html
Normal file
@ -0,0 +1,16 @@
|
||||
<div align="Center">
|
||||
<p><b>Lehrplan:</b> Durchf<68>hren von Stored Cross Site Scripting (XSS) </p>
|
||||
</div>
|
||||
<p><b>Konzept:</b> </p>
|
||||
|
||||
Man sollte Eingabedaten immer s<>ubern, besonders diese die sp<73>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<65>nschte
|
||||
Seiten oder Inhalte nachladen wenn der Inhalt betrachtet wird.
|
||||
|
||||
|
||||
<p><b>Grundsätzliche(s) Ziel(e):</b> </p>
|
||||
<!-- Start Instructions -->
|
||||
Hinterlassen Sie Inhalt der den Browser eines anderen Benutzers dazu bringt eine unerw<72>nschte
|
||||
Seite bzw. Inhalt anzuzeigen.
|
||||
<!-- Stop Instructions -->
|
||||
@ -0,0 +1,22 @@
|
||||
<div align="Center">
|
||||
<p><b>Lehrplan:</b> Einen Authentisierungs Cookie fa¨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 <20>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 <20>bung soll Sie auf das Thema der Authentisierungs Cookies aufmerksam machen und gibt Ihnen
|
||||
die M<>glichkeit die Authentisierungsmethode dieser Lektion zu <20>berwinden.
|
||||
|
||||
|
||||
|
||||
<p><b>Grundsä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<69>t zu "alice" zu wechseln.
|
||||
|
||||
<!-- Stop Instructions -->
|
||||
Reference in New Issue
Block a user