How is Cross-Site Request Forgery Prevented?
CSRF attacks are not detected with signature matching. Using this vulnerability, a hacker disguised as the victim can gain unauthorized access to application even without stealing the session cookie of a user. While a victim user is authenticated to a web site under attack, the user could unwittingly load a malicious web page from a different site within the same browser process context, for instance, by launching it in a new tab part of the same browser window. If this malicious page makes a hidden request to the victim web server, the session cookies in the browser memory are made part of this request making this an authenticated request. The web server serves the requested web page as it assumes that the request was a result of a user action on its site. To maximize the benefits, hackers typically target actionable requests such as data updates to carry out this attack.
To prevent CSRF attacks, every HTTP request within a browser session needs to carry a token based on the user session. To ensure that every request carries this token, Web Application Firewall rewrites all URLs contained in a web page similarly to how they are rewritten by the Reverse Proxy for HTTP(S) Bookmarks feature. If CSRF protection is enabled, this is also performed for Application Offloading.
CSRF protection is provided for anonymous mode as well. If CSRF protection is enabled, then an idle timeout set to the global idle timeout is enforced for anonymous access. If the session times out, an error message is displayed, forcing the user to revisit the site in a new window. If authentication is enforced for the portal, then the user is redirected to the login page for the portal.
Was This Article Helpful?
Help us to improve our support portal