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 29 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.
- 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 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 verifying 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 enforce security checks that examine client HTTP requests for anomalies in JSON data in HTTP POST operations.
- XML Detection policy — This policy enables you to create rules that examine client requests for anomalies in XML code.
- OpenAPI Detection policy — This policy enables you to create 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 an 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.
- 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 use allowlists to exclude known trusted sources (good Bots) from detection.
- Threshold Based Detection — This policy enables you to create rules to detect bad bots, such as web crawlers, content scraping, and attack bots.
- Biometrics Based Detection — This policy enables you to create rules that detect bots using behavioral biometrics such as mouse movement, keyboard, screen touch, and scroll.
- Advanced Protection policy — This policy enables you to create rules that detect web crawlers and content scraping.
- CSRF Protection policy — This policy enables you to create rules that protect backend 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.
Number |
Attack |
Solution |
---|---|---|
1 | SQL Injection |
FortiADC Supports it in two ways to prevent the SQL injection attack:
Enable FortiADC's exclusive SQL/XSS Injection Detection function for XSS attacks prevention . |
2 | Cross Site Scripting |
FortiADC Supports it in two ways to prevent the XSS injection attack.
Enable FortiADC's exclusive SQL/XSS Injection Detection function for XSS attacks prevention . |
3 | Parameter/HTTP Tampering |
FortiADC Supports it with "request-body-detection" signature profile.
You can enable it through CLI, for example: config security waf web-attack-signature edit "Poc_Test" set request-body-detection enable next end |
4 | Sensitive information | It can be protected by configuring the Sensitive Data Type in Data Leak Prevention (DLP) policy. |
5 | Cross Site Request Forging (CSRF) | It can be prevented by configuring “.*” in Parameter Value. |
6 | Session Hijacking | It can be prevented by enabling Cookie Security and configuring Authentication policy. |
7 | Blind SQL Injection |
FortiADC supports it in two ways to prevent the SQL injection attack.
It's recommended to enable the Exclusive SQL/XSS Injection Detection function for SQL attack prevention. |
8 | Request Smuggling |
FortiADC strictly follows RFC 7230, section 3.3.3. If both Content-Length and Transfer-Encoding HTTP Header exist in the request, Content-Length will be removed. This ensures that the HTTP Request Smuggling attack can be blocked by FortiADC without any additional settings. |
9 | Web Scraping |
FortiADC provides three ways to prevent the Web Scraping attacks.
|