From 55f39364239331501a0f58d55367fea169b8d2aa Mon Sep 17 00:00:00 2001 From: Ryan Rudder <96507400+RRudder@users.noreply.github.com> Date: Fri, 5 May 2023 13:26:52 +1000 Subject: [PATCH] Update rec for CSRF on Logout --- .../action_specific/logout/recommendations.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/submissions/description/cross_site_scripting_xss/cross_site_request_forgery_csrf/action_specific/logout/recommendations.md b/submissions/description/cross_site_scripting_xss/cross_site_request_forgery_csrf/action_specific/logout/recommendations.md index b510a4e2..8d41aeae 100644 --- a/submissions/description/cross_site_scripting_xss/cross_site_request_forgery_csrf/action_specific/logout/recommendations.md +++ b/submissions/description/cross_site_scripting_xss/cross_site_request_forgery_csrf/action_specific/logout/recommendations.md @@ -2,7 +2,8 @@ There is no single technique to stop CSRF from occurring. However, implementing the right combination of defensive measures within the application will prevent and limit the impact of CSRF. Some best practices include the following: -- All state changing requests should include CSRF tokens which are validated on the backend of the application. This token should be tied to the user’s session, strictly validated before an action is executed, and be unpredictable with high entropy. +- Implement a logout mechanism that requires a confirmation message for the user to confirm the logout action +- All state changing requests should include CSRF tokens which are validated on the backend of the application. This token should be tied to the user’s session, strictly validated before an action is executed, and be unpredictable with high entropy - Ensure that the framework is using built-in or existing CSRF prevention protections that exist within most major frameworks - Use the `SameSite` cookie attribute, which can have the values of `Lax`, `Strict`, or `None`. For example: