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

fix 404 links

Browse Source
This commit is contained in:
Satoshi SAKAO 2020-04-14 18:50:37 +09:00 committed by Nanne Baars
parent d7ae3a4391
commit 9063b4137f
5 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
webgoat-lessons/cross-site-scripting/src/main/resources/lessonPlans/en/CrossSiteScripting_content9.adoc
View File

@ -5,10 +5,10 @@ Do not be bothered by the incubator status on this project, use it if you are do
link: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project link: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project
=== General XSS prevention Cheat Sheet === General XSS prevention Cheat Sheet
link: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet link: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
=== DOM XSS Prevention Cheat Sheet === DOM XSS Prevention Cheat Sheet
link: https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet link: https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html
=== XSS Filter Evasion === XSS Filter Evasion
Good to know your enemy ... Good to know your enemy ...

2
webgoat-lessons/csrf/src/main/resources/lessonPlans/en/CSRF_Frameworks.adoc
View File

@ -19,7 +19,7 @@ Another defense can be to add a custom request header to each call. This will wo
with the server are performed with JavaScript. On the server side you only need to check the presence of this header with the server are performed with JavaScript. On the server side you only need to check the presence of this header
if this header is not present deny the request. if this header is not present deny the request.
Some frameworks offer this implementation by default however researcer Alex Infuhr found out that this can be bypassed Some frameworks offer this implementation by default however researcer Alex Infuhr found out that this can be bypassed
as well. You can read about: http://insert-blogspot.nl/2018/05/adobe-reader-pdf-client-side-request.html?m=1[Adobe Reader PDF - Client Side Request Injection] as well. You can read about: https://insert-script.blogspot.com/2018/05/adobe-reader-pdf-client-side-request.html[Adobe Reader PDF - Client Side Request Injection]

4
webgoat-lessons/csrf/src/main/resources/lessonPlans/en/CSRF_Impact_Defense.adoc
View File

@ -15,7 +15,7 @@ For example requests for `http://webgoat.org/something` will attach same-site co
There are two modes, strict and lax. The first one does not allow cross site request, this means when you are on There are two modes, strict and lax. The first one does not allow cross site request, this means when you are on
github.com and you want to like it through Facebook (and Facebook specifies same-site as strict) you will be github.com and you want to like it through Facebook (and Facebook specifies same-site as strict) you will be
redirected to the login page, because the browser does not attach the cookie for Facebook. redirected to the login page, because the browser does not attach the cookie for Facebook.
More information can be found here: www.sjoerdlangkemper.nl/2016/04/14/preventin-csrf-with-samesite-cookie-attribute/ More information can be found here: https://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/
=== Other protections === Other protections
@ -24,7 +24,7 @@ Tomcat have this on by default. As long as you don't turn it off (like it is in
See the following for more information on CSRF protections: See the following for more information on CSRF protections:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet (Prevention/Defense) https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (Prevention/Defense)
https://owasp.org/www-community/attacks/csrf (Attack) https://owasp.org/www-community/attacks/csrf (Attack)

2
webgoat-lessons/html-tampering/src/main/resources/lessonPlans/en/HtmlTampering_Mitigation.adoc
View File

@ -11,4 +11,4 @@ send by the client. Always remember: **NEVER TRUST INPUT SEND BY A CLIENT.**
'''' ''''
==== References ==== References
https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

4
webgoat-lessons/password-reset/src/main/resources/lessonPlans/en/PasswordReset_mitigation.adoc
View File

@ -1,13 +1,13 @@
== How to prevent abusing the password reset function == How to prevent abusing the password reset function
After learning how to abuse the password reset functionality you should now also know how to defend your own website against such attacks. If you want an extensive description of all mitigation methods take a look here: https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet After learning how to abuse the password reset functionality you should now also know how to defend your own website against such attacks. If you want an extensive description of all mitigation methods take a look here: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
This lesson will summarize the important points mentioned in the cheat sheet above. This lesson will summarize the important points mentioned in the cheat sheet above.
=== How to use security questions for user verification === How to use security questions for user verification
Security questions are an easy way to find out information about the validity of the user without asking them for verification data. The problem is, that there are not that many types of security questions and the answers to most of the questions are the same among many users. This makes it easy for an attacker to just guess the question and the answer. Security questions are an easy way to find out information about the validity of the user without asking them for verification data. The problem is, that there are not that many types of security questions and the answers to most of the questions are the same among many users. This makes it easy for an attacker to just guess the question and the answer.
An easy way to make it harder to guess the security question is to let the user themselves decide on the question they want to answer. Further information on this topic can be found here: https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet#Step_1.29_Decide_on_Identity_Data_vs_Canned_Questions_vs._User-Created_Questions An easy way to make it harder to guess the security question is to let the user themselves decide on the question they want to answer. Further information on this topic can be found here: https://cheatsheetseries.owasp.org/cheatsheets/Choosing_and_Using_Security_Questions_Cheat_Sheet.html#user-defined-security-questions
=== Sending data over the network === Sending data over the network
Everything that gets sent via the network in any direction can be read by an attacker. Some data makes it easier for an attacker to compile crucial information on the user's account that helps them bypassing login and password reset restrictions. Therefor try to not send account information (like usernames, e-mails, ...) over the network during the password reset procedure that didn't get entered by the user themselves! Everything that gets sent via the network in any direction can be read by an attacker. Some data makes it easier for an attacker to compile crucial information on the user's account that helps them bypassing login and password reset restrictions. Therefor try to not send account information (like usernames, e-mails, ...) over the network during the password reset procedure that didn't get entered by the user themselves!