Applies To:

Show Versions Show Versions

Manual Chapter: Working with Wildcard Entities
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Wildcard entities are web application entities in the security policy that contain one or more shell-style wildcard characters. In Application Security Manager, wildcard entities can represent file types, URLs, parameters, and cookie headers. Wildcards provide flexibility for security policy building. By using wildcard entities, you can efficiently build a security policy without in-depth knowledge of the web application, and reduce the number of violations and false-positives.
This chapter describes how to manually create wildcard entities. If you are using automatic policy building, the Real Traffic Policy Builder® creates wildcards, adds explicit entities, and when the security policy is stable, removes wildcards and enforces the explicit entities that it discovered. When you use the Policy Builder, you do not need to create wildcards manually because the security policy is built automatically.
You can also use the selective learning mode with wildcards. The selective learning mode uses wildcards to discover the entities in the web application that need enforcing and adds those explicit entities to the security policy. This applies to the * wildcard for file types, URLs, and parameters.
The syntax for wildcard entities is based on shell-style wildcard characters. Table 8.1 lists the wildcard characters that you can use in a wildcard entity name.
The easiest wildcard to configure is the asterisk (*), which the system interprets as match everything. You can use the * character on its own, or in a name.
Note: If you add to the security policy a wildcard URL that does not begin with the asterisk (*) character (for example a*b), the system does not automatically add the slash (/) character before it. You must manually add the slash (/) character before this type of URL for the system to enforce it.
When you create a wildcard entity, you have the option to enable either staging or explicit learning for that entity. With explicit learning, the policy discovers entities and creates learning suggestions from which you can update the security policy. The system then automatically enables staging for entities you have learned.
The learn explicit entities feature uses wildcards to discover the entities in a web application (file types, URLs, parameters, and cookies). Staging is learning the attributes of an entity (wildcard or explicit), which provides additional granularity.
You use explicit learning on wildcard entities (file types, URLs, parameters, and allowed cookies) to identify explicit entities. When you enable explicit learning for a wildcard entity, and the system receives a request that includes data that matches the wildcard entity, the system generates an explicit entity suggestion for the found entity. You can then review the new entities, and decide which are legitimate entities for the web application.
The learn explicit entities feature gives you the option of developing a more specific policy, a policy that is more accurate and in alignment with the traffic. Such a policy can provide better security, but requires more tuning to make sure all the specific entities that you add are accurately configured.
If the Policy Builder is running and the traffic source is trusted (either by definition or because of heuristic decisions), the Policy Builder automatically adds the new specific entity to the security policy.
Note: When you accept learning suggestions, you add explicit entities to the security policy. The next time the system receives a request with that entity, the system applies the security policy to the explicit entry, and not to its parent wildcard entity. Note also that accepting many explicit entities may complicate security-policy maintenance.
Each security policy can have wildcards for file types, URLs, parameters, and cookies. When you create a security policy using the Deployment wizard, the system enables the learn explicit entities feature on wildcard entities (depending on the scenario you select). As traffic is sent to the web application, the system learns the explicit properties of the file types, URLs, parameters, and cookies.
Use the learn explicit entities feature on wildcard entities to build the security policy with explicit entities, and then when no more explicit entities are seen, remove the wildcard entity using the Enforce and Enforce Ready buttons.
When you accept explicit entity suggestions for a wildcard, the system automatically places the explicit entity into staging if the Perform Staging flag is available and enabled on the learning suggestion screen. Also, if the wildcard entity has the Perform Staging flag enabled, the explicit entity inherits the wildcard attributes (including whether the Perform Staging flag is on).
You can perform staging on either explicit or wildcard entities (file types, URLs, parameters, enforced cookies) and signatures to learn the properties of the entities, as described in Table 8.2.
Parameter settings, name meta characters, value lengths, and XML, JSON, and base64 violations
Cookie changes. You can put a cookie in staging to make sure that it does not change or cause violations that will block requests. If the security policy is in blocking mode, the system does not block requests with cookies that cause violations. It provides learning suggestions for issues that could be false positives.
When an entity is in staging, the system does not block requests that cause violations relevant to this entity. Instead, it posts learning suggestions for staged entities on the Learning screens. You can take an entity out of staging by clicking the Enforce button for that entity. You can also take the entity out of staging by disabling the Perform Staging setting on the file types, URLs, parameters, cookies, or signatures screen. This is necessary only if you are manually building a security policy, and not using automatic policy building.
Tip: Use staging on wildcard entities to build the security policy without explicit entities of this type, so that the wildcard entity itself is enforced with the settings found on it.
Staging is also extremely useful when a site update occurs for a web application. With staging, you can add new URLs or parameters to the security policy and stage only the new entities. You can keep existing policy entities in blocking mode, while placing the new entities in staging (making them transparent).
To enforce file types, URLs, parameters, cookies, and signatures that are ready to be enforced
1.
On the Main tab, expand Security, point to Application Security, Policy Building, and click Enforcement Readiness.
The Enforcement Readiness screen opens.
2.
In the Enforcement Readiness Summary area, check to see if a number other than 0 appears in the Ready To Be Enforced column.
3.
If yes, then select that entity type and click the Enforce Ready button.
A confirmation popup screen opens where you can confirm that you want to enforce all entities that are ready to be enforced for the selected entity types.
4.
Click OK.
The screen refreshes; the system performs the following on selected entities:
1.
On the Main tab, expand Security, point to Application Security, Policy Building, and click Enforcement Readiness.
The Enforcement Readiness screen opens.
2.
In the Enforcement Readiness Summary, check to see if a number appears in the Not Enforced column.
A number greater than zero indicates that entities of that type were discovered while in staging.
3.
Click the number to view the specific file types, URLs, parameters, cookies, or signatures that are ready to be enforced.
The allowed file types, URLs, parameters, cookies, or signatures list opens.
5.
Click the Enforce button.
A confirmation popup screen opens, where you confirm that you want to enforce all selected entities.
6.
Click OK.
The screen refreshes and removes selected entities (explicit and wildcard) from staging.
Check for explicit matches
First, the system checks for an explicit match by scanning the security policy for the exact entity. If the security policy contains an explicit matching entity, the system applies the checks that are specified for that entity.
Check for wildcard matches
If the security policy does not contain an explicit matching entity, the system checks the wildcard entities to determine whether any of them matches the requested entity. If the system finds a wildcard match, it applies any applicable security checks. If you have enabled learn explicit entities for the wildcard entity, the system generates a learning suggestion for the new entity, which the system displays on the Traffic Learning screen.
If the system does not find an explicit match or a wildcard match, the system generates a violation for the illegal entity. If the triggered violation is in blocking mode, the system drops the request and sends the Blocking Response page to the client.
If you don't want to populate the policy with new entities, you can disable violations (such as Illegal file type, Illegal parameter, Illegal URL, and Modified domain cookies) on the Blocking screen.
File types represent the file type extensions of the files that make up the web application, such as htm, jsp, and gif. You can specify wildcard file types in a security policy when you do not want the overhead of maintaining a list of explicit file types.
You can create a wildcard file type so that requests do not generate violations based on the requested file type. Any file type that matches the wildcard expression is considered legal. For example, the wildcard * specifies that any file type is allowed by the security policy. By default, allowed file types you create are put into staging. For more information, see Using the Enforcement Readiness summary.
1.
On the Main tab, expand Security, point to Application Security, and click File Types.
The Allowed File Types screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
Click the Create button.
The Add Allowed File Type screen opens.
4.
From the File Type list, select Wildcard from the list, and then type a wildcard string in the field (for example, *).
5.
Leave the Perform Staging setting enabled.
6.
Leave the Learn Explicit Entities setting at the default, Never (wildcard only).
Note: For the * pure wildcard entity, you can click the link to select Learn Explicit Entities on the Policy Building: Settings screen.
8.
If you want the system to validate responses to requests containing this file type, select Enabled for the Apply Response Signatures setting.
Tip: Checking this option enables attack signatures (that are designed to inspect server responses) to filter responses.
9.
Click the Create button to add the wildcard file type to the security policy.
The screen displays the updated Allowed File Types screen.
10.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
1.
On the Main tab, expand Security, point to Application Security, and click File Types.
The File Type Properties screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Allowed File Types list, in the Type column, click the name of the file type that you want to modify.
The File Type Properties screen opens.
5.
Click the Update button to update the file type with any changes you may have made.
The screen refreshes, and displays the Allowed File Types screen.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
You can delete wildcard file types once the explicit file types used in the application have been added to the security policy.
1.
On the Main tab, expand Security, point to Application Security, and click File Types.
The Allowed File Types screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Select column (far left), select the box next to the wildcard file type that you want to remove, and then click the Delete button.
The system displays a confirmation popup screen.
4.
Click OK.
The system deletes the wildcard file type from the configuration.
5.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
When you have configured more than one wildcard file type, you can set the enforcement order, which is the sequence in which the system searches for a match within those wildcard file types. If it finds a match, the system then applies the security checks that are associated with that wildcard entity to the matching entity.
You can organize wildcard file types in the sequence in which you want to enforce them, which is from most-specific to least-specific. The system enforces wildcard file types from the top down.
1.
On the Main tab, expand Security, point to Application Security, and click File Types.
The Allowed File Types screen opens.
2.
On the menu bar, click Wildcards Order.
The Wildcards Order screen opens.
3.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
4.
For the Wildcard File Types List setting, make any adjustment to the list order by using the Up and Down buttons.
5.
Click the Save button to save any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
URLs represent the pages and images that compose the web application. Wildcard URLs use wildcard characters in the URL name. When you are building a security policy, using wildcard URLs reduces the number of false-positives. You can also use wildcard URLs in a security policy when you do not want the overhead of maintaining explicit URLs. By using wildcard URLs, you can configure security checks for a set of URLs, rather than configuring the security checks for each individual URL.
You can create a wildcard URL so that requests do not generate violations based on the requested URL. Any URL that matches the wildcard expression is considered legal. For example, the wildcard expression * specifies that any URL is allowed by the security policy. By default, allowed wildcard URLs you create are put into staging. If you want to enable learn explicit entities, you can learn which URLs are used in the protected web application.
1.
On the Main tab, expand Security, point to Application Security, and click URLs.
The Allowed URLs screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
Click Create.
The New Allowed URL screen opens.
4.
For the URL setting, select Wildcard from the list
The screen refreshes and displays additional settings for meta characters.
5.
Continue with the URL setting: Select the web application protocol, and then type a wildcard expression in the field (for example, *) that resolves to the URLs that the security policy should allow.
6.
Leave the Perform Staging setting enabled.
7.
Leave the Learn Explicit Entities setting at the default, Never (wildcard only).
Note: For the * pure wildcard entity, you can click the link to select Learn Explicit Entities on the Policy Building: Settings screen.
8.
In the Meta Characters tab, the Check characters on this URL setting is enabled by default so that the system verifies meta characters in the URL. (If you do not want to check for meta characters, clear the check box, and proceed to step 9.)
a)
From the Global Security Policy Settings list, select any meta characters that you want to specifically allow or disallow, and move them to the Overridden Security Policy Settings list.
Note: The Overridden Security Policy Settings take precedence over the global settings for the web application character set.
9.
Click the Create button to add the wildcard URL to the security policy.
The screen displays the updated Allowed URLs screen.
10.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
Tip: If Policy Builder is enabled, the system analyzes traffic going to the web application and adds entities or their properties to the policy. If Policy Builder is not enabled, you can accept learning suggestions manually. For details, see Using the Enforcement Readiness summary.
To process requests for this wildcard URL according to the header content such as XML, JSON, or GWT, use the Advanced settings to create header-based content profiles. For details, refer to Enforcing requests for URLs based on header content.
1.
On the Main tab, expand Security, point to Application Security, and click URLs.
The Allowed URLs screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Allowed URLs List area, in the URL column, click the name of the URL that you want to modify.
The Allowed URL Properties screen opens.
5.
Click the Update button to update the security policy with any changes you may have made.
The screen refreshes, and displays the Allowed URLs screen.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
1.
On the Main tab, expand Security, point to Application Security, and click URLs.
The Allowed URLs screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Allowed URLs List area, select the box next to the wildcard URL that you want to remove, and then click the Delete button.
The system displays a confirmation popup screen.
4.
Click OK.
The system deletes the wildcard URL from the configuration.
5.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
When you have configured more than one wildcard URL, you can set the enforcement order, which is the order in which the system searches for a match within those wildcard URLs. If the system finds a match in the wildcard URLs, the system then applies the security checks that are associated with that wildcard entity to the matching entity.
1.
On the Main tab, expand Security, point to Application Security, and click URLs.
The Allowed URLs screen opens.
2.
On the menu bar, click Wildcards Order.
The Wildcards Order screen opens.
3.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
4.
In the Wildcards Order area, for the Wildcard URLs List setting, make any adjustment to the list order by using the Up and Down buttons.
5.
Click the Save button to save any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
You can specify wildcard parameters in a security policy when you do not want the overhead of maintaining a list of explicit parameters. Using wildcard parameters reduces the number of Illegal parameter violations you receive when creating a security policy.
If you create a wildcard parameter and enable staging, you can also learn the types or attributes of the parameter, and which parameters are used in the protected web application.
For wildcard parameters that you create, any parameter name that matches the wildcard expression is permitted by the security policy. For example, typing the wildcard * specifies that the security policy allows every parameter. By default, new parameters you create are put into staging.
1.
On the Main tab, expand Security, point to Application Security, and click Parameters.
The Parameters List screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
Click Create.
The Add Parameter screen opens.
4.
In the Create New Parameter area, for the Parameter Name setting, select Wildcard from the list, and then type a wildcard string in the field (for example, *).
5.
For the Parameter Level setting, select the appropriate option for this wildcard parameter.
Global: For more information, see Working with global parameters.
URL: For more information, see Working with URL parameters.
Flow: For more information, see Working with flow parameters.
6.
Leave the Perform Staging setting enabled.
7.
Retain the default Never (wildcard only) for the Learn Explicit Entities settings.
Note: For the * pure wildcard global parameter, you can click the link to select Learn Explicit Entities on the Policy Building: Settings screen.
8.
If the parameter can have an empty value, leave the Allow Empty Value setting enabled. Otherwise, uncheck the box.
9.
To allow requests to contain multiple parameters with the same name, enable the Allow Repeated Occurrences setting. The default setting is disabled.
10.
If you want to treat the parameter you are creating as a sensitive parameter (not visible in logs or the user interface), check Sensitive Parameter.
11.
For the Parameter Value Type setting, select the appropriate type from the list.
The screen refreshes to display additional settings that are relevant to the parameter value type that you selected.
Note: For detailed information regarding the parameter value type options, see Understanding parameter value types.
12.
Configure the remaining settings for data types, meta characters, and attack signatures as required, and then click the Create button.
The screen refreshes, and displays the new wildcard parameter.
13.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
Tip: If you enabled staging or learn explicit entities and Policy Builder is enabled, the system analyzes traffic going to the web application and adds entities or their properties to the policy. If Policy Builder is not enabled, you can accept learning suggestions manually. For details, see Using the Enforcement Readiness summary.
You may want to modify the settings for an existing wildcard parameter. You can change the properties of a parameter, but you cannot change its name.
1.
On the Main tab, expand Security, point to Application Security, and click Parameters.
The Parameters List screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Parameters List area, in the Parameter Name column, click the name of the wildcard parameter that you want to modify.
The Parameter Properties screen opens.
5.
Click the Update button to update the parameter with any changes you may have made.
The screen refreshes, and displays the Parameters List screen.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
A confirmation popup screen opens.
7.
Click OK.
The system applies the updated security policy.
1.
On the Main tab, expand Security, point to Application Security, and click Parameters.
The Parameters List screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
In the Parameters List area, in the Select column (far left), select the box next to the wildcard parameter that you want to remove, and then click the Delete button.
The system displays a confirmation popup screen.
4.
Click OK.
The system deletes the wildcard parameter from the configuration.
5.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
When you configure more than one wildcard parameter, you can set the enforcement order, which is the sequence in which the system searches for a match within those wildcard parameters. If the system finds a match in the wildcard parameters, the system then applies the security checks that are associated with that wildcard entity to the matching entity. For wildcard parameters, the system looks for matches in this order: flow parameters, URL parameters, then global parameters.
The system always looks for a match on an explicit parameter first. If the explicit parameter is not found, the system looks for the next possible wildcard match on the current level, that is, flow, URL, or global. This process continues for each parameter level, as shown in Figure 8.1.
Tip: When adding wildcard URLs, arrange them in the order in which you want to enforce them. The system enforces them from the top down.
1.
On the Main tab, expand Security, point to Application Security, and click Parameters.
The Parameters List screen opens.
2.
On the menu bar, click Wildcards Order.
The Wildcards Order screen opens.
3.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
4.
In the Wildcards Order area, for the Global Parameters Wildcards List, the URL Parameters Wildcards List, and the Flow Parameters Wildcards List options, adjust the order of the wildcards in the lists by using the Up and Down buttons for each option.
5.
Click the Save button to save any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
You can use wildcards for cookie headers to reduce the number of Modified domain cookie violations you receive when creating a security policy. For more information on cookie headers, refer to Creating cookies.
You can enable learn explicit entities on wildcard cookies to cause the system to build the security policy depending on the Cookies Settings screen (Application Security > Headers > Cookies Settings). The Cookies Settings determine how the system treats cookies and how to build the security policy: either by configuring which cookies are not allowed to be changed by the client (By adding enforced cookies), or by defining which cookies are allowed to be modified by the client (By adding allowed cookies).
If using enforced cookies (which is the default and preferred value), the system adds a * wildcard allowed cookie to the security policy. As a result, valid session cookies from the web application that were not modified and which match the wildcard cookie are suggested as additions to the list of enforced cookies. We do not recommend deleting the wildcard cookie.
If using allowed cookies, you can create a * wildcard with learn explicit entities enabled. The system lists explicit cookies that match the wildcard on the learning suggestions. When you finish adding the allowed cookies, you can remove the wildcard cookie to enforce the other cookies.
1.
On the Main tab, expand Security, point to Application Security, and click Headers.
The Cookies List screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
Click the Create button.
The New Cookie screen opens.
4.
In the Cookie Name field, select Wildcard from the list, and type the pattern string that matches the cookie name.
Tip: For wildcard syntax, refer to Understanding wildcard syntax.
5.
For Cookie Type, select how the system treats this cookie:
Select Enforced if clients are not allowed to change this cookie. The system automatically enables the Perform Staging setting.
Select Allowed if clients are allowed to modify this cookie. The system automatically enables the Learn Explicit Entities setting.
6.
Clear the Perform Staging check box if you do not want the system to generate learning suggestions for this wildcard cookie. This setting is available only for the Enforced cookie type.
7.
Clear the Learn Explicit Entities check box if you do not want the system to suggest explicit cookies that match the wildcard cookie. This setting is available only for the Allowed cookie type.
8.
Select the Insert HttpOnly attribute check box if you want the system to add the HttpOnly attribute to the response header of the domain cookie.
This attribute prevents the cookie from being modified, or intercepted on the client side, even if it is not modified, by unwanted third parties that run scripts on the client's browser. The client's browser will allow only pure HTTP or HTTPS traffic to access the protected cookie.
9.
Select the Insert Secure attribute check box if want the system to add the Secure attribute to the response header of the domain cookie.
This attribute ensures that cookies are returned to the server only over SSL, which prevents the cookie from being intercepted. It does not, however, guarantee the integrity of the returned cookie.
10.
Click the Create button.
The screen refreshes, and you can see the new cookie in the either the Enforced or the Allowed Cookies list.
11.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area, then click OK to confirm.
The system applies the updated security policy.

An hourglass indicates that no learning suggestions are available, but the staging period is not over.

A scholars cap indicates that learning suggestions are available. Move the cursor over the icon to view whether the staging period is over.

A shield indicates that no learning suggestions are available and the staging period is over. This entity is ready to be enforced.
1.
On the Main tab, expand Security, point to Application Security, and click Headers.
The Cookies List screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one you are interested in.
3.
If you want to search for cookies containing a specific string, for the Cookie select Contains setting, type the string.
4.
For the Cookie, select Wildcard.
6.
On the Enforced Cookies tab, in the Staging column, point to the status icon for a listed cookie.
The system displays information about this wildcard entity.
7.
If the status indicates that learning suggestions are available for any of the cookies, on the Main tab, point to Application Security, Policy Building, then click Enforcement Readiness.
The Enforcement Readiness Summary screen opens.
8.
In the Cookies row, click a number (greater than 0) in the Have Suggestions column.
Learning suggestions for that cookie are displayed.
9.
Review the suggestions that match the wildcard, decide which are legitimate for the web application, and accept them to the security policy.
10.
To put the security policy changes into effect immediately, click the Apply Policy button, then click OK to confirm.
The system applies the updated security policy.
You can delete wildcards for cookies that you do not need in the security policy by enforcing the cookies. You can enforce a cookie when no more learning suggestions are available.
1.
On the Main tab, expand Security, point to Application Security, and click Headers.
The Cookies screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one that you want to update.
3.
On the Enforced Cookies tab, select the box next to the wildcard cookie which you want to enforce, select the Enforce check box, and then confirm.
If the security policy is in By adding enforced cookies mode, click the Enforce button to remove all selected cookies (explicit and wildcard) from staging. If the security policy is in By adding allowed cookies mode, click the Enforce button to delete the selected wildcard cookies, configured to learn explicit entities that match them, from the security policy.
4.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)