Allowed Parameters in Security Policies

In Application Security Policies, parameters are a crucial part of enforcing secure and controlled access. These parameters are categorized based on their association with URLs or application flows and can be explicitly defined or used with pattern matching (wildcards).

Types of Parameters

1. Global Parameters

   • Definition: These parameters are not tied to any specific URL or flow but are applied globally across all requests.

   • Advantages: Once configured, the global parameter is enforced wherever it occurs in the application, making it easier to manage parameters that should apply throughout the entire application.

2. URL Parameters

   • Definition: Parameters that are linked to specific URLs.

   • Use Case: These are useful when it doesn't matter where the user comes from or whether the request is made via GET or POST. It is just tied to a URL's query string or body.

3. Flow Parameters

   • Definition: These parameters are applied to specific flows, where it is important to enforce parameters only when certain conditions are met, such as when a parameter is received from a particular Referer URL.

   • Use Case: Provides strict, flow-specific security for applications, ensuring that parameters are only accepted under certain flow conditions (e.g., from a specific source URL).

Adding Allowed Parameters

1. Explicit Parameters

   • Specifies one specific named parameter that is allowed in the security policy.

   • Example: user_id

2. Wildcard Parameters

   • Uses a wildcard pattern to match parameters, offering more flexibility.

   • Example: param_* would match all parameters starting with param_.

3. No Name (Unnamed Parameters)

   • Parameters with no explicit name are labeled as “UNNAMED”. These could be generic or dynamic parameters that don’t fit into predefined categories.

Learning Explicit Entities for Parameters

You can control how explicit entities (parameters) are added to the policy with these options:

• Never (Wildcard Only): Only wildcard patterns are used for learning and adding parameters, no explicit named parameters are added.

• Selective: Adds explicit entities for parameters when false positives are detected.

• Compact: Suggests adding entities with a higher learning score, and those that meet certain thresholds.

• Always: Adds all matching parameters to the security policy as explicit entities.

Properties of Parameters

1. Allow Empty Value

   • Function: Determines whether the parameter can have an empty value. If set to Yes, the parameter is allowed even when its value is missing.

   • Example: param1= (without a value).

2. Allow Repeated Occurrences

   • Function: Allows the same parameter to appear multiple times in a single request. This is useful when a parameter might need to appear more than once, such as in query strings or form submissions.

   • Example: param1=val1&param1=val2

3. Sensitive Parameter (Mask Value in Logs)

   • Function: If enabled, the value of the parameter is treated as sensitive and will be masked in logs, preventing it from being exposed in logs or reports.

   • Example: Masking the value of password or credit_card_number in logs.

4. Parameter Value Type

   • Function: Specifies the expected format or type of the parameter value, which can affect how the system treats or validates it. This could be a specific data type (string, integer, etc.), or it could define patterns (e.g., regex patterns for email validation).

   • Example: Defining user_id to be an integer, or email to follow an email address pattern.

Example: Defining Allowed Parameters

1. Global Parameter Example:

   • Parameter: session_id

   • Configuration: Applies globally to all URLs in the application. The system will enforce this parameter wherever it appears in requests.

2. URL Parameter Example:

   • URL: /login

   • Parameter: user_token

   • Configuration: This parameter is only enforced for requests to /login.

3. Flow Parameter Example:

   • URL: /payment

   • Parameter: user_id

   • Flow Condition: The parameter must only come from the https://www.example.com/dashboard referer URL.

   • Configuration: This enforces that only requests with a valid user_id from the dashboard page are allowed to proceed.

Security Enforcement Strategy for Parameters

• Explicitly Define Allowed Parameters: Specify what parameters should be allowed for each URL or flow.

• Use Wildcards for Flexibility: When the exact parameters are dynamic or less predictable, wildcards can be used to capture patterns.

• Sensitive Data Protection: Use the “Sensitive Parameter” feature to mask sensitive data in logs to prevent exposure of critical information.

• Tighten Security with Flow Parameters: For sensitive or important flows, enforce parameters strictly from trusted sources (e.g., from a specific referer).