fix 404 links

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

@@ -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
 
 === 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
-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
 Good to know your enemy ...

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

@@ -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
 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
-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]
 
 
 

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

@@ -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
 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.
-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
 
@@ -24,10 +24,10 @@ 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:
 
-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://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CSRF_Prevention_Filter / https://tomcat.apache.org/tomcat-8.0-doc/config/filter.html#CSRF_Prevention_Filter (Tomcat)
 
-https://docs.spring.io/spring-security/site/docs/current/reference/html5/#csrf
+https://docs.spring.io/spring-security/site/docs/current/reference/html5/#csrf

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

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

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

@@ -1,13 +1,13 @@
 == 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.
 
 === 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.
 
-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
 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!
@@ -25,4 +25,4 @@ It is always safer to do an authentication process via two or more separate ways
 On the other side it requires the user to give you additional information on the matter of contacting them, which is not welcomed bz everyone.
 
 === Further reading
-We highly recommend to take a further look on the cheat sheet linked in the introduction! The password reset functionality is easily abusable for an attacker when implemented incorrectly. You can make it harder for an attacker to abuse it by just following a few suggestions made here and in the cheat sheet!
+We highly recommend to take a further look on the cheat sheet linked in the introduction! The password reset functionality is easily abusable for an attacker when implemented incorrectly. You can make it harder for an attacker to abuse it by just following a few suggestions made here and in the cheat sheet!