How are Signatures Used to Prevent Attacks?
For Cross Site Scripting, Injection Flaws, Malicious File Execution, and Insecure Direct Object Reference vulnerabilities, the Web Application Firewall feature uses a black list of signatures that are known to make web applications vulnerable. New updates to these signatures are periodically downloaded from a SonicWall signature database server, providing protection from recently introduced attacks.
How signatures prevent attacks
When input arrives from the internet, Web Application Firewall inspects HTTP/HTTPS request headers, cookies, POST data, query strings, response headers, and content. It compares the input to both a black list and a white list of signatures. If pattern matching succeeds for any signature, the event is logged and/or the input is blocked if so configured. If blocked, an error page is returned to the client and access to the resource is prevented. The threat details are not exposed in the URL of the error page. If configured for detection only, the attack is logged but the client can still access the resource. If no signature is matched, the request is forwarded to the web server for handling.
What happens when no signature is matched
The Web Application Firewall process is outlined in the following flowchart.
Web Application Firewall process
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 SMA management interface. Some administrators might want to customize the HTML contents of this page. Others might not want to present a user friendly page for security reasons. Instead, they might prefer the option to present an HTTP error code such as 404 (Not found) or 403 (Access Denied).
Was This Article Helpful?
Help us to improve our support portal