Website Global Policy

Cookie flags

 HSTS - HTTP Strict Transport Security

HSTS is a mechanism enabling web sites to declare themselves accessible only via secure connections - HTTPS. The policy is declared by web sites via the Strict-Transport-Security HTTP response header field. When enabling HSTS in WAF the Strict-Transport-Security header will be injected in server responses if it is not already present.

CSRF protection configuration

 Request authorization configuration

Source status

When Credentials stuffing and Brute Force protection is enabled, source (as defined by Source IP Precision) activity is tracked on the protected pages (URL paths).

When a source triggers a violation by exceeding limits on the protected pages it is flagged as offensive and gets served a CAPTCHA regardless of what page on the protected website it requests next. Until the CAPTCHA is solved it won’t be able to reach the protected website.

Until the offensive status expires a new CAPTCHA will be served to the source IP tracking unit every time the CAPTCHA expires.

 IP pass through

IP pass through allows for configuring overriding of filter actions based on the source of the request.

Duplicate parameter names

If duplicate parameter names are allowed, wrongly configured web application behavior may result in Alert Logic Managed Web Application Firewall (WAF) not learning the web site correctly and may also lead to WAF bypassing vulnerabilities depending on the target application/web server technology.

An attacker may submit a request to the web application with several parameters with the same name depending on the technology the web application may react in one of the following ways:

In the case of concatenation it will allow an attacker to distribute the payload of for instance an SQL injection attack across several duplicate parameters.

As an example ASP.NET concatenates duplicate parameters using ',' so /index.aspx?page=22&page=42 would result in the backend web application parsing the value of the 'page' parameter as page=22,42 while WAF may see it as two parameters with values 22 and 42.

This behavior allows the attacker to distribute an SQL injection attack across the three parameters.

/index.aspx?page='select data&page=1 from table would result in the backend web application parsing the value of the 'page' parameter as 'select data, 1 from table while WAF may see it as two parameters with values 'select data and 1 from table.

By default, when WAF validates parameters negatively it automatically concatenates the payload of duplicate parameters. It is mostly in the case where a positive application or global rule allows a specific parameter with an input validation rule that makes room for attacks like the above the parameter duplication problem exists. In the page example above the attack would be stopped because the page parameter would be learned as numeric input (an integer). This would not allow text input like in the example above. Nevertheless it is important to configure WAF to mimic the target web applications parsing of requests as closely as possible.

The best option is to disallow duplicate parameter names. It may not be practical though as the use of duplicate parameters may be intended in some applications - the most prominent example being PHP which parses parameter names suffixed with [] as an array - like par1[]=22&par1[]=42 becoming array(22,42). If this feature is not in use block it.

If the application technology is ASP/IIS or ASP.NET/IIS and it is not possible to disallow duplicate parameters the recommended setting is to join duplicate parameters using ',' as in the join separator example above.

For each weekday enter opening hours.

To specify dates where the website is closed enter a list of dates in the format mm/dd separated by whitespace, comma or semicolon.

URL to redirect the visitor to when website is closed.

This field is required.

Some user input is so complex and unpredictable that, to avoid false positives, positive validation of input ends up being very general and loose. An example of this is free text input fields which often get mapped to the input validation class "printable" which basically allows all printable characters. It is often better validate such input negatively - which WAF does by default.

WAF determines if an input should be validated negatively based on the input validation class rank. By default the threshold is the class Printable. If a parameters input is learned/configured to be the class configured as threshold the signatures policy will be used instead of the class regular expression.

To determine whether a given session is anomalous or not, a machine learning algorithm is utilized. This evaluation is based on a set of features used to calculate a session "score". The score is then compared against a trained model to determine if the session is anomalous.

The session's features include HTTP methods, status codes, the types of resources being requested (e.g., images, JS, HTML, PDF, and dynamic resources like PHP or ASPX), the existence of a Referer header, and whether /robots.txt was requested.

Model status table

Detection sensitivity slider

The detection sensitivity slider allows users to adjust the threshold used to determine whether a session is anomalous or not. By sliding the control to the left, the sensitivity is decreased, resulting in fewer anomalies being detected. Conversely, sliding the control to the right increases the sensitivity and should detect more anomalies.

Increasing sensitivity effectively “lowers the bar” for when a session is considered anomalous and, consequently, also increases the risk of the model generating false positive anomalies. Conversely, lowering sensitivity raises the bar but also decreases the risk of false positives.

It is recommended to leave the slider in the default position for optimal performance.

Detected anomalies

When a session is detected as anomalous the observation is logged and client source IP is flagged as an Anomalous Session IP which can be managed in “L7 Source IP and Geolocation based controls” where different controls – like blocking, CAPTCHA challenge, and lowering connection trust can be applied to the source IP.

Load defaults

The "Load Defaults" button enables users to reset the current session anomaly detection models. Selecting "Load Defaults" erases any existing configurations, replaces them with the original default settings, and deletes any trained models. Additionally, the module status is set back to "Inactive".

Note that this action is permanent and cannot be undone, so take caution when selecting this option.

Normally it is not necessary to reset learning but if, for instance, website usage patterns change or substantial changes are made to the website and lots of redirects are sent to accommodate Google it may be necessary to reset the learning model.

Fortra Web Application Firewall (WAF) API Protection

The Fortra WAF provides robust protection for APIs by parsing OpenAPI definitions and creating policy rules for each endpoint. These rules are specific to the endpoint paths and support extracting values from named URL path parameters (e.g., /api/pets/{id}).

How it works

• Parsing OpenAPI Definitions: The WAF parses the provided OpenAPI definition to understand the structure and endpoints of the API.
• Creating Policy Rules: For each endpoint in the OpenAPI definition, the WAF creates positive policy rules to allow the HTTP methods defined in the OpenAPI specification.
• Input Validation: The WAF maps each endpoint's input parameters to an input validation class based on the OpenAPI data type and format.
• Policy Type: Input Validation Class mapping is dependent on policy type. While the WAF policy type input validation classes are fewer and more tailored towards a website with user input, the API policy type input validation classes are more directly mapped to the specific OpenAPI Data Types and Formats.

Input validation classes

Input validation classes are a collection of predefined named regular expressions used for positive policy rules. When changing a class, all policy rules using that class will be affected. Classes are ordered (ranked) by specificity, indicating how complex the input the class allows.

For each endpoint definition, parameters will be mapped to input validation classes based on their data type and format. For example, a parameter with the type string and format byte will be mapped to the string_byte validation class.

Classes with complexity above a configurable threshold (defined by class rank) can have signature validation added to the class-based validation. This is configured in the Input Validation Classes section of the WAF policy page. For the API policy type, the default is to add signature validation for the class string_printable ([^\x00-\x08\x0b\x0c\x0e-\x1f\x7f]+).

Policy type

The policy type can be either API or WAF. The policy type determines the default classes and how they map to OpenAPI data types. The API policy type is recommended for API protection because the default class definitions are different between the two policy types.

The policy type can be set in:

• Policy > Website Global Policy > Input Validation Classes
• By applying the WAAP_Defaults template
• By selecting the WAAP website type when a new website is created

It is recommend to separate API protection from the protection of a website with user interaction because of the difference in class definitions. If it is not possible to separate the two, then the API policy type is recommended for new website / API configurations because of a clearer mapping to OpenAPI data types.

When the API is served from the same domain name as a “conventional” user-facing website where the WAF policy is already tuned, it is not recommended to change the policy type to use API specific input validation classes as this will interfere with policy rules that are using existing WAF Type classes. Instead, the class mapping and possibly the class definitions should be modified to strike an acceptable balance between the existing policy and API validation.

API Definitions Management

The WAF UI provides a section for managing API definitions:

OpenAPI definitions

The OpenAPI definitions table enables bulk management of API definitions. Each row in the table represents an API definition, and you can use the Action drop-down menu to manage rules for the API.

API definitions can be uploaded to the WAF or, if a URL is provided, read from a remote location.

The fields in the OpenAPI Definitions table are:

• Name: The name of the OpenAPI definition (e.g., petstore).
• Location / Filename: The URL or name of the OpenAPI definition (e.g., petstore-expanded.json) as listed in the Uploaded API Definitions section.
• Enum: Create static validation rules for parameters with the enum property set. An enum property is a list of static values that are allowed as input.
• Pattern: When present, use input validation pattern definitions in the API specification to validate request parameter values.
• Validation: Class-based validation of OpenAPI data types and formats.
  • Class Map: Map OpenAPI data types and formats to Input Validation Classes as defined in the Data Type Mappings section.
  • Default Class: Use Default Class for all input as defined in Data Type Mappings.
• Color: Select which color the endpoint rules resulting from API definition should be coded with. This allows for distinguishing between endpoints from different API definitions in the list of endpoint policy rules.
• Last Action: Last action performed on the API definition.
• Action: Once the API definition is saved, you can manage it by selecting actions in the Action drop-down and then executing them by clicking the corresponding Go button.
  • Test Import: Perform a dry run on creating policy rules from the API definition. This will show if the API definition parses correctly.
  • Create Rules: Create policy rules from the API definition. The rules will be created in a disabled state to allow for adjustments before enforcing them.
  • Enable / Disable Rules: Toggle enabling or disabling the endpoint rules associated with the API definition.
  • Delete Rules: Delete all rules created from the API definition. You can recreate rules by selecting Create Rules.

Violations supported

JSON-based OpenAPI v3 definitions are supported.

Data type mappings

The WAF allows you to map OpenAPI basic types and formats to specific validation classes. The default mappings are shown below for API and WAF policy type (may vary slightly depending on WAF version).

You can change each mapping by selecting the drop-down menu in the WAF Input Validation Class field.

API Policy Type mappings

The API Policy Type input validation classes are tailored for and directly mapped to the OpenAPI data types and formats and require little or no adjustment of the mappings:

WAF Policy Type mappings

When the API is served from the same domain name as a “conventional” user-facing website where the WAF policy is already tuned, it is not recommended to change the policy type to use API specific input validation classes as this will interfere with policy rules that are using existing WAF Type classes.

In this case, it is necessary to adjust the mappings to balance API input validation with existing class usage – possibly with small changes to class definitions as required, like changing the num input validation class from \d{1,32} to [+-]?\d{1,64}.

The mapping recommendations in the table below provide a good starting point. Note that the Signature Validation is read only as it is defined in the Input Validation Classes section of the policy. The Signature Validation field is not updated until the new class mappings are saved.

The recommended mappings below must be configured manually. Once configured, the mappings apply to all imported API definitions.

Resulting endpoint policy rules

Rules created from an OpenAPI definition are of type API Path Definition. This type differs from the Web Application policy rule type in that the URL path is parsed differently. While the Web Application policy rule path is defined as a regular expression, the API Path Definition is following the OpenAPI path definition syntax that allows for path-based parameters.

Path-based parameters

Path-based parameters are dynamic parts of the URL path that capture specific values. For example, in the endpoint /api/pets/{id}, {id} is a path-based parameter that can capture the value of a pet's ID.

Fortra WAF creates a policy rule for each path-based parameter in the endpoint policy rule. In the case of /api/pets/{id}, the WAF will create a policy rule identified by its OpenAPi path - /api/pets/{id} - and a specific rule for the input parameter id to handle the validation and extraction of the value from the URL path.

Creating protection from an API definition

To create protection from an API definition, follow these steps to ensure your API is properly managed and secured within the WAF interface. This process involves uploading the API definition, configuring its settings, and managing the rules associated with it:

1. Navigate to the API Definitions Management section in the WAF GUI.
2. Click Upload API Definition, and then select the OpenAPI definition file to upload.
3. In the API Definitions Table, add the following API definitions:
   1. In the Description box, enter a name for the API definition (e.g., Petstore API).
   2. In the Location / Filename box, select the uploaded API definition file from the drop-down menu. Alternatively, enter a URL if the API definition is located on an external server.
   3. In the Validation drop-down menu, select the validation type.
      1. Class Map will map API definition data types to WAF validation classes (recommended).
      2. Default Class will map all inputs to the default validation class.
   4. In the Color drop-down menu, select the color coding for the API endpoints. This is useful when endpoints from multiple API definitions are served from the same domain name.
   5. The Action drop-down menu will appear dimmed until the new API settings are saved.
4. Click Save. The Action drop-down menu will become enabled.
5. In the Action drop-down menu, select one of the following actions and then click Go to execute it:
   1. Test Import: Performs a dry run on creating policy rules from the API definition. This will show if the API definition parses correctly.
   2. Create Rules: Creates policy rules from the API definition. The rules will be created in a disabled state to allow for adjustments before enforcing them.
   3. Enable / Disable Rules: Enables or disables the endpoint rules associated with the API definition.
   4. Delete Rules: Deletes all rules created from the API definition. Rules can be recreated by selecting Create Rules.
6. Click Save.

When creating rules, it may be necessary to adjust endpoints to accommodate factors such as limitations on request body size for large upload requests. In such cases, switching to streaming body inspection might be required.

When enabling rules, consider either putting the policy or individual endpoint rules in Detect (log only) mode to validate everything is working as expected before switching to Protect mode.

Resulting policy

Importing and creating rules for the Fortra Petstore Example API definition will result in three OpenAPI endpoint rules.

The rules are created in a disabled state and until enabled they are not effective. When enabled the color of the URL path changes in the list.

Basic concepts

The /v1/pets/{petId} rule illustrates some basic concepts.

Path based parameters – The parameter named petId is in the URL path – the {petId} part. The value is extracted from the URL path. As an example, the petId value in the URL path /v1/pets/42 will become 42.

Pattern – The parameter name has a pattern property in the API definition. The resulting validation rule is of type regex and using the validation from the definition.

Enum – The parameter status has an enum property in the API definition. The resulting validation rule is of type static and using the list of static values in the definition.

Class-based validation – Parameters id and petId have type (integer) and format (int64) properties in the API definition. Integer/int64 is mapped to the WAF input validation class integer64 ( [+-]?\d{1,64} ) as shown in the list.

Methods allowed – The API path has specifications for both GET and POST methods so both methods are allowed. All other methods are disallowed.

Streaming inspection – When the requestBody definition of an API path specifies a content type that the WAF does not parse, streaming inspection is automatically enabled for all specified content types for that specific API path.

In the case of the /v1/pets/{petId}/upload rule, the requestBody has specifications for the application/octet-stream content type. This content type is not parsed by Fortra WAF so streaming HTTP body inspection with inspection of the unparsed request body is enabled for that specific API path. As a result, signatures suitable for inspection of raw data are used to validate the request body data while it is streamed to the protected backend.

DEFAULT is set to Allow=no, meaning any content type, but application/octet-stream is disallowed and will be blocked.

Streaming inspection allows for inspecting request bodies of unlimited size.

Open API

API definition formats

Fortra WAF supports OpenAPI version 3 definitions, which allows for a wide range of API specifications to be used for creating protection rules. Since Swagger is the original name for OpenAPI, any Swagger definitions already in the OpenAPI format can be used directly with the Fortra WAF.

Additionally, API definitions in other formats can be converted to OpenAPI format using various tools and services. Examples include:

• Postman Collections
• RAML (RESTful API Modeling Language)
• API Blueprint
• WSDL (Web Services Description Language)

Tools like API Transformer and API Spec Converter can be used to convert these formats to OpenAPI.

OpenAPI API definition format

The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to HTTP APIs, allowing both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or network traffic inspection. An OpenAPI definition is a document that describes the surface of an API and its operations in a machine-readable format. It can be written in either JSON or YAML. Fortra WAF supports JSON, and YAML can easily be converted to JSON if needed.

Key components of an OpenAPI definition

• OpenAPI Object: Specifies the version of the OpenAPI Specification being used.
• Info Object: Provides metadata about the API, such as the title, version, and description.
• Paths Object: Lists the available API endpoints and the operations that can be performed on each endpoint.
• Components Object: Defines reusable schemas, parameters, responses, and other components.
• Security Object: Specifies the security mechanisms that can be used across the API.
• Tags Object: Allows for logical grouping of operations by resources or any other qualifier.
• External Documentation Object: Provides additional external documentation references.

Example of an OpenAPI definition (JSON)

The following example is a modified version of the petstore.json API definition used on OpenAPI and Swagger websites to demonstrate OpenAPI capabilities.

{ 
    "openapi": "3.0.0", 
    "info": { 
        "title": "Fortra Petstore Example", 
        "description": "A sample API to illustrate OpenAPI concepts", 
        "version": "1.0.0", 
        "license": { 
            "name": "MIT" 
        } 
    }, 
    "servers": [ 
        { 
            "url": "http://petstore.swagger.io/v1", 
            "description": "Main (production) server" 
        } 
    ], 
    "paths": { 
        "/pets": { 
            "get": { 
                "summary": "List all pets", 
                "operationId": "listPets", 
                "tags": [ 
                    "pets" 
                ], 
                "parameters": [ 
                    { 
                        "name": "limit", 
                        "in": "query", 
                        "description": "How many items to return at one time (max 100)", 
                        "required": false, 
                        "schema": { 
                            "type": "integer", 
                            "maximum": 100, 
                            "format": "int32" 
                        } 
                    } 
                ], 
                "responses": { 
                    "200": { 
                        "description": "A paged array of pets", 
                        "headers": { 
                            "x-next": { 
                                "description": "A link to the next page of responses", 
                                "schema": { 
                                    "type": "string" 
                                } 
                            } 
                        }, 
                        "content": { 
                            "application/json": { 
                                "schema": { 
                                    "$ref": "#/components/schemas/Pets" 
                                } 
                            } 
                        } 
                    }, 
                    "default": { 
                        "description": "unexpected error", 
                        "content": { 
                            "application/json": { 
                                "schema": { 
                                    "$ref": "#/components/schemas/Error" 
                                } 
                            } 
                        } 
                    } 
                } 
            }, 
            "post": { 
                "summary": "Create a pet", 
                "operationId": "createPets", 
                "tags": [ 
                    "pets" 
                ], 
                "requestBody": { 
                    "description": "Pet object that needs to be added to the store", 
                    "required": true, 
                    "content": { 
                        "application/json": { 
                            "schema": { 
                                "$ref": "#/components/schemas/Pet" 
                            } 
                        } 
                    } 
                }, 
                "responses": { 
                    "201": { 
                        "description": "Null response" 
                    }, 
                    "default": { 
                        "description": "unexpected error", 
                        "content": { 
                            "application/json": { 
                                "schema": { 
                                    "$ref": "#/components/schemas/Error" 
                                } 
                            } 
                        } 
                    } 
                } 
            } 
        }, 
        "/pets/{petId}": { 
            "get": { 
                "summary": "Info for a specific pet", 
                "operationId": "showPetById", 
                "tags": [ 
                    "pets" 
                ], 
                "parameters": [ 
                    { 
                        "name": "petId", 
                        "in": "path", 
                        "required": true, 
                        "description": "The id of the pet to retrieve", 
                        "schema": { 
                            "type": "integer", 
                            "format": "int64" 
                        } 
                    } 
                ], 
                "responses": { 
                    "200": { 
                        "description": "Expected response to a valid request", 
                        "content": { 
                            "application/json": { 
                                "schema": { 
                                    "$ref": "#/components/schemas/Pet" 
                                } 
                            } 
                        } 
                    }, 
                    "default": { 
                        "description": "unexpected error", 
                        "content": { 
                            "application/json": { 
                                "schema": { 
                                    "$ref": "#/components/schemas/Error" 
                                } 
                            } 
                        } 
                    } 
                } 
            }, 
            "post": { 
                "summary": "Update a pet", 
                "operationId": "updatePet", 
                "tags": [ 
                    "pets" 
                ], 
                "parameters": [ 
                    { 
                        "name": "petId", 
                        "in": "path", 
                        "required": true, 
                        "description": "The id of the pet to update", 
                        "schema": { 
                            "type": "integer", 
                            "format": "int64" 
                        } 
                    } 
                ], 
                "requestBody": { 
                    "description": "Pet object that needs to be updated", 
                    "required": true, 
                    "content": { 
                        "application/json": { 
                            "schema": { 
                                "$ref": "#/components/schemas/Pet" 
                            } 
                        } 
                    } 
                }, 
                "responses": { 
                    "200": { 
                        "description": "Pet updated successfully", 
                        "content": { 
                            "application/json": { 
                                "schema": { 
                                    "$ref": "#/components/schemas/Pet" 
                                } 
                            } 
                        } 
                    } 
                } 
            } 
        }, 
        "/pets/{petId}/upload": { 
            "post": { 
                "summary": "Upload pet documentation and pictures", 
                "operationId": "uploadPetFiles", 
                "tags": [ 
                    "pets" 
                ], 
                "parameters": [ 
                    { 
                        "name": "petId", 
                        "in": "path", 
                        "required": true, 
                        "description": "The id of the pet to upload files for", 
                        "schema": { 
                            "type": "integer", 
                            "format": "int64" 
                        } 
                    } 
                ], 
                "requestBody": { 
                    "description": "Pet documentation or picture to upload", 
                    "required": true, 
                    "content": { 
                        "application/octet-stream": { 
                            "schema": { 
                                "type": "string", 
                                "format": "binary" 
                            } 
                        } 
                    } 
                }, 
                "responses": { 
                    "201": { 
                        "description": "File uploaded successfully", 
                        "content": { 
                            "application/json": { 
                                "schema": { 
                                    "type": "object", 
                                    "properties": { 
                                        "fileName": { 
                                            "type": "string" 
                                        }, 
                                        "uploadedAt": { 
                                            "type": "string", 
                                            "format": "date-time" 
                                        }, 
                                        "fileSize": { 
                                            "type": "integer" 
                                        } 
                                    } 
                                } 
                            } 
                        } 
                    }, 
                    "400": { 
                        "description": "Invalid input, file type not supported" 
                    }, 
                    "default": { 
                        "description": "unexpected error", 
                        "content": { 
                            "application/json": { 
                                "schema": { 
                                    "$ref": "#/components/schemas/Error" 
                                } 
                            } 
                        } 
                    } 
                } 
            } 
        } 
    }, 
    "components": { 
        "schemas": { 
            "Pet": { 
                "type": "object", 
                "required": [ 
                    "id", 
                    "name" 
                ], 
                "properties": { 
                    "id": { 
                        "type": "integer", 
                        "format": "int64" 
                    }, 
                    "name": { 
                        "type": "string", 
                        "pattern": "^[a-zA-Z0-9 ]+$" 
                    }, 
                    "tag": { 
                        "type": "string" 
                    }, 
                    "status": { 
                        "type": "string", 
                        "enum": [ 
                            "available", 
                            "pending", 
                            "sold", 
                            null 
                        ], 
                        "nullable": true 
                    } 
                } 
            }, 
            "Pets": { 
                "type": "array", 
                "items": { 
                    "$ref": "#/components/schemas/Pet" 
                } 
            }, 
            "Error": { 
                "type": "object", 
                "required": [ 
                    "code", 
                    "message" 
                ], 
                "properties": { 
                    "code": { 
                        "type": "integer", 
                        "format": "int32" 
                    }, 
                    "message": { 
                        "type": "string" 
                    } 
                } 
            } 
        } 
    } 
}