Manage Parameters

Overview

MParameters 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.

Wildcard syntax

If you are creating parameters for your policy, the syntax for wildcard entities is based on shell-style wildcard characters. This table lists the wildcard characters that you can use in the names of parameters, file types, URLs, or cookies so that the entity name can match multiple objects.

Wildcard Character Matches
* All characters
? Any single character
[abcde] Exactly one of the characters listed
[!abcde] Any character not listed
[a-e] Exactly one character in the range
[!a-e] Any character not in the range

Prerequisites

  • Verify any attached application services to ensure proper security after changes are deployed.

  • You need to have a user role of Security Manager or Administrator to manage a WAF policy.

How to manage policy parameteres

Add new parameters

Define new parameters that protects against attacks to your applications by doing following steps:

  1. Click the workspace icon next to the F5 icon, and click Security.

  2. From the left menu click Policies under WAF.

  3. Select the name of the policy.

    A panel for the General Settings opens.

  4. From the panel menu, click Parameters.

  5. Click + Create.

  6. Enter a parameter Name.

  7. Select a Parameter Type:

    1. Explicit - The policy identifies the parameter by its specific name.

    2. Wildcard - The policy identifies the parameter by regular expression. Any parameter name that matches the wildcard expression is permitted by the security policy.

    Note: The pure wildcard () is automatically added to the policy so you do not need to add it. You can add more specified wildcards such assite.com. See Wildcard syntax for more information.

  8. Select a Location where the parameter is found in the request:

    1. Query String - Parameter is found as a query string in the request.

    2. Form Data - Parameter is found in the form data of the request.

  9. Select a parameter Value Type:

    1. Auto Detect - The policy automatically detects the parameter within the request. This value type is useful in reducing false positives for detecting violations in XML or JSON parameter values in a request.

    2. User Input - The parameter data is provided by user-added input. Once you select user input, select a Data Type.

      1. Alpha-Numeric - Parameter data can be any text consisting of letters, digits and the underscore character. Once you select this value, you can specify whether this data type has minimum and maximum limits:

        1. Minimum Length - To enforce limits on the minimum size parameter, select Value and enter the minimum alpha-numeric character limit.

          Note: The default value is 0.

        2. Maximum Length - To enforce limits on the maximum size parameter, select Value and enter the maximum alpha-numeric character limit.

          Note: The default value is 10.

      2. File Upload - Prevent uploading of executable files. Once you select this value, you can configure the policy to block file uploads that contain binary executable content by enabling Disallow File Upload of Executables.

    3. Dynamic content value - Enforce parameters where the application sets the value on the server side to extract dynamic parameters from responses to requests from allowed URLs.

      Note: You must add allowed URLs to configure dynamic parameters. See Add allowed URLs.

      1. Select an allowed URL from Extract from Allowed URLs.

  10. To log, but allow, requests even with the detected parameter, enable Staging. If you would like to enforce the parameter, do not enable this option.

    Note: You can later change the enforcement status in the parameters list.

  11. Enable Mask Value in Logs if the parameter detects sensitive information. By enabling this option request information is not visible in logs or user interface.

  12. To enable additional parameter values, enable Advanced View to the top right of the panel:

    1. Enable Allow Empty Value if the parameter is acceptable without a value. By default, this setting is disabled, and requires the parameter to always include a value.

    2. Enable Allow Repeated Occurrences to allow users to send a request that contains multiple parameters with the same name.

  13. Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.

  14. Click Deploy to deploy changes.

The new parameter is now in the Parameters list. If you note a high number of block or alert events for allowed parameters, you may require a signature override. See Override an attack signature on BIG-IP Next Central Manager.

Modify parameters

Manage parameter violations

You can specify how WAF policies handle traffic with detected parameter violations. For more information about these violations, see Reference: parameters.

See Reference: Violation Protection for information about template default settings.

  1. Click the workspace icon next to the F5 icon, and click Security.

  2. From the left menu click Policies under WAF.

  3. Select the name of the policy.

    A panel for the General Settings opens.

  4. From the panel menu, click Parameters.

  5. Click Violations.

    The Parameter Violations panel opens.

  6. Modify the policy settings:

    1. Alarm - Sends an alert to the event log that the parameter violation was detected in traffic to protected applications.

    2. Alarm & Block - Sends an alert to the event log and blocks traffic that includes the parameter violation/s.

    3. Disabled - The policy does not enforce parameter violations.

  7. Click Save. The changes are saved to the policy, but are not yet deployed to the BIG-IP Next instance.

  8. Click Deploy to deploy changes.

Resources

Configure using API

Parameter management using the policy Editor

Edit the WAF policy JSON declaration directly through the WAF policy editor.