Overview: Parameters¶
Parameters are an integral part of any web application, and they need to be protected so clients cannot access them, modify them, or view sensitive data. When you define parameters in a security policy, you increase the security of the web application and prevent web parameter tampering.
WAF evaluates parameters, meta characters, query string lengths, and POST data lengths as part of a positive security logic check. When the security policy includes known parameters, you are creating an allowlist of acceptable parameters. The system allows traffic that includes the parameters that you configure in a security policy.
Security policies can include parameters defined as global parameters or URL parameters. You can further specify parameters as being particular value types: static content, dynamic content, dynamic parameter name, user-input, JSON, or XML. You can also create parameters for which the system does not check or verify the value.
Note: BIG-IP Next Central Manager currently supports global parameters, limited value types (auto detect and user-input), and dynamic content value parameters (for allowed URLs) .
Global Parameters¶
Global parameters are parameters that are not associated with specific URLs. The advantage of using global parameters is that you can configure a global parameter once, and the system enforces the parameter wherever it occurs. You create a global parameter to address these conditions:
The web application has a parameter that appears in several URLs.
You want the Application Security Manager to enforce the same parameter attributes on all parameters.
When you first create a global parameter, the system places the parameter in staging by default and does not block requests even if a violation occurs and the system is configured to block the violation. The system makes learning suggestions that you can accept or clear.
URL Parameters¶
URL parameters are parameters that are defined in the context of a URL. You can use a URL parameter when it does not matter where users were before they accessed this URL, or whether the parameter was in a GET or POST request. You can create a parameter that goes with a URL that already exists in the security policy.
When you define a URL parameter, the system applies the security policy to the parameter attributes in the context of the associated URL. When you first create a URL parameter, the system places the parameter in staging by default and does not block requests even if a violation occurs and the system is configured to block the violation. The system makes learning suggestions that you can accept or clear.
Sensitive Parameters¶
WAF stores incoming requests in plain text format. Some requests include sensitive data in parameters, such as an account number, that you want to hide from system users. You can create sensitive parameters as described in the procedure, following, or by enabling the Sensitive Parameter setting when creating or editing any parameter. All parameters defined as sensitive, regardless of how you configured them, appear in the Sensitive Parameters list.
When you create sensitive parameters, the system replaces the sensitive data, in the stored request and in logs, with asterisks (***).
Dynamic Content Value Parameters¶
Dynamic content value (DCV) parameters are parameters where the web application sets the value on the server side (so, for example, the content can change depending on who the user is). When you create a DCV parameter, you also specify where and how to get the dynamic information. For example, in an auction application, you can configure the price parameter as a DCV parameter to keep users from tampering with the price. You can also use DCV parameters for user identities in web applications that use sessions. As an example, user identity is often passed between pages as a hidden parameter, which could be exploited by malicious users, unless protected.
When WAF receives a request that contains an entity (for example, a file extension or URL) with a dynamic content value parameter, the system extracts the parameter value from the web application response and stores it away. The next time the system receives a request containing that parameter, it uses the stored value to validate the dynamic content value parameter. The system verifies that the client is not changing the parameter value that the server sets from one request to the next, or using the values from a different user.
By default, the system saves up to 950 values that it finds for a dynamic content value parameter. If the number of values exceeds 950, the system replaces the first-extracted values with the new values.
Base64-Encoded Parameters¶
Base64 encoding is a convenient encoding method that uses a compact presentation, and is relatively unreadable to the casual observer. Many applications apply base64 encoding to binary data, for inclusion in URLs or in hidden web form fields. Unfortunately, it is also possible to mask application attacks in base64-encoded data. To provide better security for applications that use base64 encoding, WAF can decode user-input parameter values that are base64-encoded.
Base64 decoding to a new user-input parameter¶
If your application uses base64 encoding, the system can apply base64 decoding to a user-input parameter. When the decoding is successful, the system applies the parameter checks specified in the security policy. When the decoding is not successful, the system issues the Illegal base64 encoded value violation and responds to the offending request according the associated blocking policy.
Base64 decoding to an existing user-input parameter¶
When enabled, the system can decode base64 encoding in a user-input parameter. If the decoding is successful, the system applies the parameter checks specified in the security policy. If the decoding is not successful, the system issues the Illegal base64 encoded value violation and responds to the offending request according to the associated blocking policy.