711649924b
* Some initial refactoring * Make it one application * Got it working * Fix problem on Windows * Move WebWolf * Move first lesson * Moved all lessons * Fix pom.xml * Fix tests * Add option to initialize a lesson This way we can create content for each user inside a lesson. The initialize method will be called when a new user is created or when a lesson reset happens * Clean up pom.xml files * Remove fetching labels based on language. We only support English at the moment, all the lesson explanations are written in English which makes it very difficult to translate. If we only had labels it would make sense to support multiple languages * Fix SonarLint issues * And move it all to the main project * Fix for documentation paths * Fix pom warnings * Remove PMD as it does not work * Update release notes about refactoring Update release notes about refactoring Update release notes about refactoring * Fix lesson template * Update release notes * Keep it in the same repo in Dockerhub * Update documentation to show how the connection is obtained. Resolves: #1180 * Rename all integration tests * Remove command from Dockerfile * Simplify GitHub actions Currently, we use a separate actions for pull-requests and branch build. This is now consolidated in one action. The PR action triggers always, it now only trigger when the PR is opened and not in draft. Running all platforms on a branch build is a bit too much, it is better to only run all platforms when someone opens a PR. * Remove duplicate entry from release notes * Add explicit registry for base image * Lesson scanner not working when fat jar When running the fat jar we have to take into account we are reading from the jar file and not the filesystem. In this case you cannot use `getFile` for example. * added info in README and fixed release docker * changed base image and added ignore file Co-authored-by: Zubcevic.com <rene@zubcevic.com>
34 lines
1.8 KiB
Plaintext
34 lines
1.8 KiB
Plaintext
== CSRF Impact
|
|
|
|
The impact is limited only by what the logged in user can do (if the site/function/action is not protected properly).
|
|
The areas that are really prone to CSRF attacks are IoT devices and 'smart' appliances. Sadly, many consumer-grade routers
|
|
have also proven vulnerable to CSRF.
|
|
|
|
== CSRF solutions
|
|
|
|
=== Same site cookie attribute
|
|
|
|
This is a new extension which modern browsers support which limits the scope of the cookie such that it will only be
|
|
attached to requests if those requests are 'same-site'
|
|
For example requests for `http://webgoat.org/something` will attach same-site cookies if the request is initiated from
|
|
`webgoat.org`.
|
|
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: https://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/
|
|
|
|
=== Other protections
|
|
|
|
Fortunately, many (web) application frameworks now come with built in support to handle CSRF attacks. For example, Spring and
|
|
Tomcat have this on by default. As long as you don't turn it off (like it is in WebGoat), you should be safe from CSRF attacks.
|
|
|
|
See the following for more information on CSRF protections:
|
|
|
|
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
|