fc08681d89
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
38 lines
1.7 KiB
HTML
38 lines
1.7 KiB
HTML
<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 -->
|
|
|
|
|