Fortinet black logo

Handbook

Web application firewall basics

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.

HTTP scanpoints

Number

Attack

Solution

1 SQL Injection

FortiADC Supports it in two ways to prevent the SQL injection attack:

  • Signatures

  • SQL/XSS Injection Detection (Under WAF > Common Attacks Detection)

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.

  • Signatures

  • SQL/XSS Injection Detection (Under WAF > Common Attacks Detection)

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.

  • If the signature profile was created by being cloned from "High-Level-Security" profile, the "request-body-detection" is enabled already.

  • If the signature profile was created by "Create New", the "request-body-detection" is disabled.

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.

  • Signatures

  • SQL/XSS Injection Detection (Under WAF > Common Attacks Detection)

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 two ways to prevent the Web Scraping attacks.

  • WAF Signatures

  • Content Scraping (Under WAF > Common Attacks Detection > Advance Protection)

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.

HTTP scanpoints

Number

Attack

Solution

1 SQL Injection

FortiADC Supports it in two ways to prevent the SQL injection attack:

  • Signatures

  • SQL/XSS Injection Detection (Under WAF > Common Attacks Detection)

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.

  • Signatures

  • SQL/XSS Injection Detection (Under WAF > Common Attacks Detection)

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.

  • If the signature profile was created by being cloned from "High-Level-Security" profile, the "request-body-detection" is enabled already.

  • If the signature profile was created by "Create New", the "request-body-detection" is disabled.

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.

  • Signatures

  • SQL/XSS Injection Detection (Under WAF > Common Attacks Detection)

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 two ways to prevent the Web Scraping attacks.

  • WAF Signatures

  • Content Scraping (Under WAF > Common Attacks Detection > Advance Protection)