How Is Cross-Site Request Forgery Prevented - Dell SonicWall SRA 4200 Administrator's Manual

The Web Application Firewall process is outlined in the following flowchart.
In the case of a blocked request, the following error page is returned to the client:
This page is customizable under Web Application Firewall > Settings in the SRA management
interface. Some administrators may want to customize the HTML contents of this page. Others
may not want to present a user friendly page for security reasons. Instead, they may prefer the
option to present an HTTP error code such as 404 (Not found) or 403 (Access Denied).

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 may 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, typically, hackers targets 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, the Web Application
Firewall feature 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.
SRA Overview | 65