Web application firewall basics

A web application firewall (WAF) is a security policy enforcement point positioned between a client endpoint and a web application. The primary purpose is to prevent attacks against the web servers. A WAF is deployed separately from the web application so that the process overhead required to perform security scanning can be offloaded from the web server, and policies can be administered from one platform to many servers.

A WAF uses methods that complement perimeter security systems, such as the FortiGate next-generation firewall. The FortiADC WAF module applies a set of policies to HTTP scanpoints, which are parsed contexts of an HTTP transaction.

HTTP scanpoints illustrates the scanpoints. In the WAF policy configurations, you have options to enable rules to detect attacks at the request line, query string, filename, URI, request headers, request body, response code, or response body.

• Web Attack Signature policy—The signature database includes signatures that can detect known attacks and exploits that can be found in 22 scanpoints. In your policy configuration, you choose classes of scanpoints to process: HTTP Headers, HTTP Request Body, and HTTP Response Body.
• URL Protection policy—This policy enables you to create rules that detect patterns in the URI or the file extension.
• HTTP Protocol Constraint policy—This policy enables you to create rules that restrict URI, header, and body length; HTTP method, or HTTP response code.
• SQL/XSS Injection Detection policy—This policy includes rules to detect SQL/XSS injection in the HTTP Request URI, HTTP Referer Header, HTTP Cookie Header, or HTTP Request Body.
• Bot Detection—This policy includes rules to detect Bots. A Bot is an application that runs automated tasks over the Internet.The WAF supports two methods for detecting bad Bots: signature detection and behavior detection. You can also also use allowlists to exclude known trusted sources (good Bots) from detection.
• Cookie Security policy— This policy enables you to create rules that prevent cookie-based attacks and apply them in a protection profile.
• Data Leak Prevention policy----This policy enables you to create rules that to prevent information leaks, damages and loss.
• HTTP Header Security policy--- This policy enables you to create rules to prevent or mitigate known XSS, clickjacking, and MIME sniffing security vulnerabilities. These response headers define security policies to client browsers so that the browsers avoid exposure to known vulnerabilities when handling requests.
• Input Validation Policy--- This policy enables you to create rules to prevent suspicious HTTP requests by verifing the user input from scan points like URL parameter, HTML form, hidden fields, and upload file.
• Brute Force Attack Detection policy--- This policy enables you to create rules to prevent too many login tests
• Credential Stuffing Defense policy--- This policy enables you to create rules to identify login attempts using username and password that have been compromised using an always up-to-date feed of stolen credentials.
• JSON Detection policy--- This policy enables you to create rules that to enforce security checks that examine client HTTP requests for anomalies in JSON data in HTTP POST operations.
• XML Detection policy--- This policy enable you to crate rules that to examine client requests for anomalies in XML code.
• OpenAPI Detection policy--- This policy enable you to crate rules through defining a standard, language-agnostic interface to RESTful APIs, which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.
• API Gateway policy--- This policy includes API management tool that sits between a client and a collection of backend services. It acts as a reverse proxy to accept all API calls and return the appropriate result.
• Advanced Protection policy--- This policy enable you to crate rules that
• CSRF Protection policy--- This policy enables you to create rules that to protect back-end servers from CSRF attacks.

Policy rules are enforced (action taken) when scanning is completed at four checkpoints:

• HTTP Request Header
• HTTP Request Body
• HTTP Response Header
• HTTP Response Body

If the HTTP Request Header violates a rule, and the action is Deny, the attempted session is dropped and scanning for the transaction stops. If the action is Alert, the event is logged and rules processing continues.