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@389 4033779f-a91e-0410-96ef-6bf7bf53c507
27 lines
2.1 KiB
HTML
27 lines
2.1 KiB
HTML
<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><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>"/></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 -->
|
|
|