Applies To:

Show Versions Show Versions

Manual Chapter: Working with the Security Policy
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

The core of the Application Security Managers security functionality is the security policy, a collection of settings that define how the Application Security Manager secures traffic for a web application. The security policy is a map of the web application itself.
When the Application Security Manager receives an incoming HTTP or HTTPS request for the web application, the system compares the request to the active security policy. If some element of the request (or response) does not comply with security policy, the Application Security Manager processes the request according to the Blocking Policy settings, which include the enforcement mode and the Learn, Alarm, and Block flags. For more information about the Blocking Policy settings, see Working with the blocking configuration.
Deployment Wizard
The Deployment Wizard is a tool that automates the security policy setup tasks for a new unconfigured web application. The Deployment Wizard builds security policies based on one of several typical deployment scenarios. For more information, refer to the BIG-IP® Application Security Manager: Getting Started Guide guide, which is available on the AskF5SM web site, https://support.f5.com.
Security Policy Setup Wizard
The Security Policy Setup Wizard is a tool that automates most of the security policy setup tasks for web applications that already exist in the application security configuration. See Chapter 5, Working with the Security Policy Setup Wizard, for more information.
Manual configuration
If you prefer to not to use the wizards, you may configure the security policy manually. The remainder of this chapter describes the manual configuration tasks for the security policy components.
The Security Enforcer applies the active security policy to each request for the web application. If the request complies with the security policy, the Security Enforcer forwards the request on to the web application. If the request does not comply with the security policy, the Security Enforcer generates a violation (or violations), and then either forwards the request or blocks the request, depending on the enforcement mode of the security policy.
The Security Enforcer can also check responses from the web application.If the response complies with the security policy, the system sends the response to the client. If the response does not comply with the security policy, the Security Enforcer generates the relevant violation (or violations), and then either forwards the response or blocks the response, depending on the enforcement mode of the security policy. This prevents the transmission of information from the server to a malicious client.
See Appendix A, Security Policy Violations, for descriptions of all violations. For information on setting the learning, alarm, and blocking actions for the violations, see Configuring the blocking actions.
The Application Security Manager provides the Policy Builder to automate building a security policy. If you were to build the security policy manually, it would be a tedious undertaking, especially if the web application is updated frequently. You can use the Policy Builder to build the security policy based either on real traffic (both requests and responses), or on system-generated traffic. See Chapter 6, Building a Security Policy Automatically with the Policy Builder, for detailed information on using the Policy Builder.
Security policy properties
The security policy properties determine the overall characteristics and behavior of the security policy. The security policy properties specify how the security policy interacts with the security policy entities. The security policy properties also specify how the security policy processes and responds to security policy violations. See Working with the security policy properties, for more information.
Security policy entities
The security policy entities compose the security policy. The security policy entities can include URLs, file types, parameters, character sets, XML profiles, and attack signatures. See the corresponding sections of the chapter for more information.
Blocking policy configuration
The enforcement mode and the blocking policy determine what actions the system takes when a request or response triggers a violation. See Working with the blocking configuration, for more information.
Before you configure the security policy entities, which are the map of the web application, you configure the policy properties of the security policy. The policy properties are the general configuration options and settings that determine the overall behavior and functionality of the security policy. Note that not all policy properties apply to all security policies.
Important: Any time you make a change to a security policy, no matter how small, you must apply the security policy to make it the active security policy. To remind you that you need to set the active security policy, the system displays an [M] next to the modified security policy. Once you set the active security policy, the Security Enforcer enforces any changes you have made. To set the active policy, refer to Setting the active policy for a web application, for detailed information.
Each security policy that you configure has a unique name, which you configure on the Policy Properties screen as part of the general properties. At minimum, a new security policy must have a name. You can change the security policy name at any time. You can also provide a description of the security policy, to help you better identify the security policy.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Configuration area, for the Security Policy Name setting, type a unique name for the security policy.
4.
Optionally, in the Security Policy Description box, type a description, as required.
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 in the editing context area.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Configuration area, click the name of the web application in the Web Application setting.
The Web Application Properties screen opens, where you can view the details of the web application.
There are two enforcement modes for a security policy: transparent and blocking. When the system receives an incoming HTTP request that does not comply with the security policy, the system logs the HTTP request according to the logging profile for the web application, and generates alarms for the violations. If the security policy is in transparent mode, the system then forwards the request to the destination. If the enforcement mode is blocking, and the Block flag is enabled for the triggered violation, the system does not forward the request to the web application. Instead, the system sends the blocking response page to the client, which advises the client that the request was blocked, and provides a support ID number for the violating request.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Configuration area, for the Enforcement Mode setting, select either Transparent or Blocking.
4.
Click Save to save any changes you may have made to the security policy properties.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area near the top of the screen.
You specify a maximum HTTP header length so that the system knows the acceptable maximum length for the HTTP header in an incoming request. The system applies the length check to header names and value. You can use this setting to help prevent primary buffer overflow attacks.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
For the Maximum HTTP Header Length setting, select one of the following options:
Select Any to have the system accept HTTP headers of any length.
Select Length, and type a value, to accept HTTP headers up to a certain length. The default maximum length is 8192 bytes.
5.
Click Save to save any changes you may have made to the security policy properties.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You specify a maximum cookie header length so that the system knows the acceptable maximum length for any cookie headers in the incoming HTTP request. As with the maximum HTTP header length setting, you can use this setting to help prevent primary buffer overflow attacks.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
For the Maximum Cookie Header Length setting, select one of the following options:
Select Any to have the system accept cookie headers of any length.
Select Length, and type a value, to accept cookie headers up to a certain length.The default maximum length is 8192 bytes.
5.
Click Save to save any changes you may have made to the security policy properties.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
The allowed response codes determine which response codes are acceptable within a server response. If the HTTP response code is in the 4XX range or the 5XX range, then only responses with a response code that appears in this list are returned as-is to the client. If a response contains a response code other than those specified in the allowed response code list, and the response code is in the 4XX range or the 5XX range, then the system issues the Illegal HTTP status in response violation, and, if blocking is enabled for this violation, blocks the response.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
For the Allowed Response Codes setting, make any changes that are required.
5.
Click Save to save any changes you may have made to the security policy properties.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
When an application uses dynamic session ID in URLs, the Application Security Manager cannot use its normal functions to extract and enforce URLs or flows because the URI contains a dynamic element. If the web application that you are securing stores dynamic session ID information in a URL, you can enable the Dynamic Session ID in URL option. When the system receives a request in which the dynamic session information does not match the settings in the security policy, the Security Enforcer issues the Illegal session ID in URL violation.
When you enable the Dynamic Session ID in URL option, the Application Security Manager extracts the dynamic session information from requests or responses, based on the pattern that you configure. For requests, the Security Enforcer applies the pattern to the URI up to, but not including, the question mark (?) character of a query string.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Configuration area, select Advanced.
The screen refreshes, and displays additional configuration options.
4.
For the Dynamic Sessions in URL option, enable or disable the dynamic sessions in URL as required. For help with the settings, click the Help tab in the navigation pane.
5.
Click Update.
The system updates the configuration with any changes you have made.
At any given time, the Application Security Manager enforces only one security policy for a web application. The security policy that is currently protecting the web application is called the active security policy. The active security policy is marked with the Active icon in the Security Policies List for the web application.
1.
On the Main tab of the Application Security navigation pane, click Web Applications.
The Web Applications list screen opens.
2.
In the Name column, click the name of the web application for which you are activating a security policy.
The Web Application properties screen opens.
3.
In the Web Application Properties section, in the Active Security Policy list, select the security policy that you want to be the active security policy for the web application. Note that the system automatically checks the Apply Policy setting when you change the Active Security Policy setting on this screen.
4.
Click Update.
The screen refreshes, and in the Security Policies List, you see the Active Policy icon next to the new active security policy.
Tip: You can also set the active security policy from most of the screens throughout the Application Security Manager. Simply click the Apply Policy button in the editing context area.
Every time you change the configuration in a security policy, you must activate the security policy before the changes take effect. Throughout the Configuration utility, the following icons appear, and are there to let you know the state of a security policy.
The Active icon next to a security policy name indicates the active security policy. You may also see an A in square brackets [A] to indicate the active security policy. Only one security policy can be the active security policy.
The Modified icon next to a security policy name indicates that the security policy has been modified. You may also see an M in square brackets [M] to indicate a modified security policy.
The first security checks that Application Security Manager performs are those for RFC compliance for the HTTP protocol. If a request passes the compliance checks, then the system applies the security policy to the remainder of the request. You can configure the HTTP validations that the system performs on a per-security policy basis. You can also configure whether the system generates learning suggestions, alarms, or blocks requests for requests that trigger the HTTP protocol compliance failed violation.
When Application Security Manager receives a request from a client, the first aspect of the request that the system validates is HTTP protocol compliance. If the request is not compliant with the following subset of HTTP protocol validations, the Security Enforcer cannot continue enforcing the security policy, and may pass the request on to the web application resources even though it is not a valid request. The HTTP protocol validations that may cause this situation are:
Several Content-Length headers
We recommend that you retain the default blocking policy settings for the HTTP protocol validations. As an additional precaution, you may want to enable the blocking enforcement mode, and enable only the Block flag for the HTTP protocol compliance failed violation. When you do this, the Security Enforcer blocks requests that are not compliant with the HTTP protocol standards.
Important: The Request size exceeded maximum buffer size violation also causes the system to stop validating a request.
You can review and modify the validation options for the HTTP protocol compliance on the HTTP Protocol Compliance screen.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
From the Blocking menu, choose HTTP Protocol Compliance.
The HTTP Protocol Compliance screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
On the HTTP Protocol Compliance screen, make any adjustments that are required. For an explanation of the individual validations, refer to the online help.
5.
Click Save to retain any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
In the security policy, the file types represent the general file types that make up the web application. There are four types of file types: wildcard, no extension, explicit, and disallowed.
Wildcard file type
Wildcard file types are those whose name is, or contains, a pattern string. When you configure a wildcard file type, and enable tightening, as the security policy processes traffic, the system discovers the file types that match the wildcard. You can then decide whether to add those file types to the security policy. For detailed information on wildcard file types, refer to Configuring wildcard file types.
No extension file type
The no extension file type represents file types that do not have the typical file extension as part of the name. The slash character (/) is an example of a no_ext file type.
Explicit file type
Explicit file types have a known file extension name, for example, JSP or htm.
Disallowed file types
You can also configure a list of file types that the system always rejects. These objects are known as disallowed file types. Refer to Configuring disallowed file types, for more information.
Important: File types are case-sensitive. As a result, the security policy processes JPG and jpg files as separate file types.
Note: When you run the Policy Builder, the system automatically creates a no_ext file type in the following cases: URLs with no file extension, and URLs with file extensions longer than eight characters.
For allowed file types, which are file types that the system accepts, you can configure lengths, and whether the Security Enforcer checks responses for the associated requests. Table 7.1 describes the allowed file type properties.
1.
On the Main tab of the Application Security navigation pane, click File Types.
The Allowed File Types List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed File Types list, click the Create button.
The New Allowed File Type screen opens.
4.
In the Allowed File Type area, for the File Type setting, select the type for the URL, and then type a file extension or wildcard expression.
If you selected the No Extension file type, you do not need to type anything. The information is populated by default.
Tip: For more information about wildcard file types, see Configuring wildcard file types.
6.
Check the Check Response box if you want the system to validate responses for this file type.
7.
Click Create.
The screen refreshes, and you see the new file type on the Allowed File Types List screen.
8.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
To modify the allowed file type characteristics
1.
On the Main tab of the Application Security navigation pane, click File Types.
The Allowed File Types List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed File Types List area, click the name of the file type that you want to update.
The Edit Allowed File Type screen opens.
4.
Make any changes as required, and click Update.
The screen refreshes, and returns to the Allowed File Types List screen.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Since web applications can change on a regular basis, you may find that the file types list contains file types that are no longer used in the web application. You can remove the file type and any related URLs (if applicable) in one step.
1.
On the Main tab of the Application Security navigation pane, click File Types.
The Allowed File Types List screen opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed File Types List area, click the Select box to the left of the file type that you want to remove from the list.
4.
Click the Delete button below the list.
The system removes the file type from the configuration, and also removes any specific URLs of this type.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
For some web applications, there may be requests for certain file types for which you always want the Security Enforcer to deny access. In this case, you can create a set of disallowed file types. When the Application Security Manager receives a request whose file type matches a disallowed file type, the system rejects the request.
1.
On the Main tab of the Application Security navigation pane, click File Types.
The Allowed File Types List screen opens.
2.
On the menu bar, click Disallowed File Types List.
The Disallowed File Types List screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
Above the Disallowed File Types List area, click the Create button.
The New Disallowed File Type screen opens.
5.
For the File Type setting, in the box, type the file type that you want to disallow.
Note: File types are case-sensitive.
6.
Click Create.
The screen refreshes, and displays the updated Disallowed File Types List screen.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
In the application security configuration, URLs represent the pages and images that make up the web application that you are protecting. There are two types of URLs: wildcard URLs and explicit URLs.
Wildcard URLs
A wildcard URL is one whose name is or contains a pattern string, for example, * or *.png. When you configure a wildcard URL, and enable tightening, then as the security policy processes traffic, the system discovers the explicit URLs that match the wildcard. You can then decide whether to add those URLs to the security policy. For more information on managing wildcard URLs, refer to Configuring wildcard URLs.
Explicit URLs
An explicit URL has a specific name and represents one file or component of the web application, for example, /login.jsp or /sell.php.
Table 7.2 lists URL properties.
Table 7.2 URL properties
Specifies, when enabled, that whenever the Policy Builder runs, it adds to the security policy those URLs that do not exist in the security policy but match this wildcard URL.
Specifies, when checked, that the security policy validates the flows to the URL. If this setting is disabled, the Security Enforcer ignores the flows to the URL. For more information on flows, refer to Configuring flows.
Specifies, when checked, that the Security Enforcer verifies the XML data associated with requests for this URL. For more information on XML security, refer to Chapter 13, Protecting XML-Based Applications.
Explicit URLs and wildcard URLs
(Visible when Check XML is selected.) Specifies that the system validates XML data found in requests to this URL based on the settings you configure in a specific XML profile. For more information on XML profiles, refer to Associating an XML profile with a URL.
Explicit URLs and wildcard URLs
All specifies that the system validates XML data found in requests to this URL.
User defined specifies that the system validates XML data found in requests to this URL only if the context-type header includes a specific string.
Explicit URLs and wildcard URLs
Check AMF (When the content type matches "amf")
Specifies, when checked, that the Security Enforcer applies security checks to AMF requests. For more information, refer to Configuring AMF security for URLs.
Explicit URLs and wildcard URLs
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the URLs List area, click the Create button.
The New URL screen opens.
4.
To configure the advanced settings, select Advanced above the Create New URL area.
The screen refreshes to display additional settings.
5.
In the Create New URL area, for the URL Name setting, select the file type, and then type the explicit URL name. For explicit URLs, be sure to type the full resource path starting with the slash
( / ) character.
6.
In the Protocol list, select the protocol to be used to access the URL.
7.
Configure any additional settings as needed. For more information on the flow settings, refer to Configuring flows. for more information on checking XML data, refer to Associating an XML profile with a URL. For more information on checking AMF data, refer to Configuring AMF security for URLs.
8.
Click the Create button.
The screen refreshes, and on the Urls screen, you can see the new URL in the list.
9.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
4.
Click the Delete button.
A confirmation popup screen opens, where you confirm the deletion of the URL.
5.
Click OK.
The popup screen closes, and the system removes the URL from the security policy.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can review and modify the properties of an individual URL. Simply click the name of the URL in the Web Application URLs list. The URL Details screen for that URL opens.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the URLs List area, in the URL column, click the name of a URL.
The URL Properties screen opens, where you can view or modify the URL properties.
URL parameters are parameters that are associated with a specific URL. Extractions specify how the system discovers dynamic parameters and their properties. For full details on managing URL parameters and extractions, refer to Chapter 11, Working with Parameters.
Flows are the navigational relationships between the entities in a web application. Configuring flows may tighten the security policy, but this is an optional configuration option. For more information on flows, refer to Configuring flows.
Action Message Format (AMF) is a binary format that is loosely based on the Simple Object Access Protocol (SOAP). AMF is used primarily to exchange data between Adobe® Flash® applications and a database, by using the RPC (remote procedure call) protocol. The Application Security Manager secures applications that use AMF by applying attack signatures to parameters within POST requests, when the Content-Type header matches the pattern *amf*.
The Application Security Manager determines whether a request is an AMF request when the request meets the following criteria:
The Content-Type header matches the pattern *amf*
When a request matches the previous criteria, the system applies parameter-specific attack signatures to any parameters in the POST body of AMF requests. If the system finds a match, then the Security Enforcer issues the Attack signature detected violation, and handles the request according to the blocking policy settings.
Note: If a request contains a Content-Type header whose value matches the *amf* pattern, but the Check AMF option is not enabled for the corresponding URL, then the Application Security Manager does not apply the additional AMF checks.
You configure AMF security on a per-URL basis. You can configure AMF security for both wildcard URLs and explicit URLs.
Note: The following procedure assumes that you are configuring AMF security for a URL that already exists in the configuration. If this is not the case, refer to Creating an explicit URL, or Creating wildcard URLs, before proceeding.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the URLs List area, in the URL column, click the name of the URL for which you want to enable AMF security.
The URL Properties screen opens.
4.
Above the URL Properties area, select Advanced.
The screen refreshes, and displays additional configuration options.
5.
Check the box for Check AMF (When the content type matches "amf").
6.
Click Update.
The screen refreshes, and displays the URLs List screen.
When you first configure the web application properties in the Application Security Manager, you select a language encoding. The Security Enforcer then enforces the character set of that language encoding in the URL element in URIs, and also for any wildcard urls in the security policy. For example, by disallowing the characters <, >, ', and |, the Security Enforcer can protect against many cross-site scripting attacks and injection attacks. You can modify the character set as required by your web application.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
On the menu bar, click Character Set.
The URLs Character Set screen opens, where you can view the character set, and state for each character.
4.
Use the Filter option to display only those characters that you want to view.
5.
If you make any changes to the character set, after you save the changes, be sure to click the Apply Policy button (in the editing context area) to immediately put those changes into effect.
The application flow is the defined access path leading from one URL to another URL within the web application. For example, on a basic web page, you may have a graphic and a hyperlink to another page within the application. The calls to these other entities from the basic page make up the flow.
If you use either the Global Level or the URL Level security template, both the Policy Builder and the Security Enforcer ignore flows. If you decide to use the Flow Level security template for the Policy Builder, then the Policy Builder discovers and populates the application flow, and the Security Enforcer verifies the flow properties. For more informations, see Understanding the security templates for the Policy Builder.
Important: Configuring flows is an optional task. Unless you need the enhanced security of configured flows, we recommend that you do not configure a flow-based security policy.
When you view the flows for a particular URL, the system displays the flow to the particular URL. Note that flows may be associated with explicit URLs only.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the URLs List area, in the URL column, click the name of the URL for which you want to see the flow.
The URL Properties screen opens.
4.
On the menu bar, click Flows to URL.
The Flows to URL screen opens.
We recommend that you use the Policy Builder and the Learning process to create and maintain the application flow. Alternately, you can create a flow for a URL manually.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the URLs List area, in the URL column, click the name of the URL for which you want to see the flow.
The URL Properties screen opens.
4.
On the menu bar, click Flows to URL.
The Flows to URL screen opens.
5.
Above the Flows to URL list, click the Create button.
The Create a New Flow popup screen opens.
6.
In the Referrer URL box, select one of the following:
Entry Point: Specifies that the client can enter the application from this URL
URL Path: Specifies the URL, if the URL is not an entry point.
7.
In the Protocol list, select the appropriate protocol.
8.
In the Method list, select the appropriate HTTP method.
9.
In the Frame Target box, type the frame in which the URL belongs, if the web application uses frames.
Tip: If your web application does not use frames, type the value 1.
12.
Click OK.
The popup screen closes, and on the Flows to URL screen, you see the new flow in the Flows to URL area.
13.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Some web applications contain URLs with dynamic names, for example, the links to a server location for file downloads, where the file name may be unique to each user. You can configure the system to detect these URLs by configuring a dynamic flow. For a dynamic flow, you configure a regular expression that describes the dynamic name, and associate the flow with the URL. The Application Security Manager then extracts the dynamic URL names from URSL responses, for which the dynamic flow is configured.
Important: Dynamic flows are relevant only if you are configuring advanced flows with the Policy Builder and the Flow Level security template. Additionally, the URL for which you are configuring a dynamic flow must be configured as a referrer URL.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the URLs List area, in the URL column, click the name of the URL for which you want to see the flow.
The URL Properties screen opens.
4.
On the menu bar, click Dynamic Flows From URL.
The Dynamic Flows From URL screen opens.
5.
Above the Dynamic Flows From URL area, click the Create button.
The Create New Dynamic Flow popup screen opens.
6.
For the Prefix setting, type a string that occurs in the referring URLs source code, and is physically located before the reference to the dynamic name URL.
7.
For the RegExpValue setting, type a regular expression that describes the dynamic name.
8.
For the Suffix setting, type a string that occurs in the referring URLs source code, and is physically located after the reference to the dynamic name URL.
9.
Click the OK button.
The popup screen closes, and on the Dynamic Flows from URL screen, you see the new dynamic flow.
10.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
There may be URLs in your web application that should be accessed only through other URLs. For example, in an online banking application, account holders should be able to access their account information only by logging in through a login screen first. In the application security configuration, you can configure flow access to prevent access to restricted URLs. When you configure flow access, the system prevents forceful browsing to otherwise restricted URLs in the web application.
There are two violations related to flow access: Login URL bypassed and Login URL expired. When a user tries to bypass the login URL, the Security Enforcer issues the Login URL bypassed violation. When a user session passes the expiration time for the login URL, the Security Enforcer issues the Login URL expired violation. For both of these violations, when the enforcement mode is blocking, the system sends the Flow Access Response Page to the offending client. For information on configuring the Flow Access Response Page, see Configuring the response pages.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
On the menu bar, click Flow Access.
The Flow Access screen opens.
4.
Above the Flow Access area, click the Create button.
The New Flow Access screen opens.
5.
For the Login URL setting, select the appropriate protocol, and then type the URL name, beginning with the forward slash character (/).
6.
For the Applies to setting, type the name of the URL (including the / character) for which the login URL restricts access, and then click the Add button to add the URL to the list. Optionally, you can type a wildcard expression. There is no restriction on the number of URLs to which the login URL applies.
7.
Optionally, for the Logout URL setting, type the URL name for the URL that, when a user accesses this URL, the user cannot access the restricted URLs again until they re-enter the login URL criteria.
8.
If you want the login URL to be valid only for a certain length of time, enable the Expiration Time setting, and type a value, in seconds.
9.
In the Access Validation area, you can further refine the criteria for the flow access. See the online help for more information on these settings.
10.
Click the Create button.
The screen refreshes, and displays the new flow access URL.
11.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
Depending on the web application, a response may contain sensitive user information, such as credit card numbers or social security numbers (U.S. only). You can configure the Data Guard feature to prevent responses from exposing this sensitive information. This process is known as response scrubbing. In addition to protecting credit card numbers and social security numbers, you can configure custom patterns using PCRE regular expressions to match other types of sensitive information.
When the system detects sensitive information in a response, and you have enabled the Data Guard feature, the system generates the Information leakage detected violation. Additionally, if the security policy enforcement mode is blocking, the system does not send the response to the client.
Important: When you enable the Mask Data option, the system replaces the sensitive data with asterisk characters (****). We recommend that you enable this setting if the security policy enforcement mode is transparent. Otherwise, when the system returns the response, the sensitive data is exposed to the client.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Data Guard area, check the options that you want the system to identify in responses. The online help describes the options.
4.
Check the Mask Data box if, in the response, you want the system to replace the sensitive data with asterisk characters.
5.
Click the Save button to retain any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can configure the security policy to ignore certain cookie headers that are included in an HTTP request, even if they do not meet the expected criteria, and would otherwise trigger a security policy violation. You use the Allowed Modified Cookies property to manage the list of cookies that you want the Security Enforcer to ignore. Typically, allowed modified cookies are cookies that can change on client side, usually using JavaScript, and are not session-related.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed Modified Cookies area, click the Create button.
The New Allowed Cookie screen opens.
4.
From the Cookie Name Type list, select whether the system identifies the cookie by a specific name (Explicit), or by a regular expression (Wildcard).
5.
In the Cookie Name box, type either the name of the allowed cookie, or the pattern string that matches the cookie name.
6.
Click Create.
The screen refreshes, and you can see the newly-created allowed cookie in the Allowed Modified Cookies area.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
In addition to creating allowed cookies, you can also edit existing allowed cookies, as required by changes in the web application.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
In the Allowed Modified Cookies area, in the Cookie Name column, click the cookie name.
The Edit Allowed Cookie screen opens.
5.
Click Update.
The screen refreshes, and you can see the modified allowed cookie in the Allowed Modified Cookies area.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
In addition to creating and editing allowed cookies, you can also delete existing allowed cookies, as required by changes in the web application.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
Click the Delete button.
A confirmation popup screen opens, where you confirm the deletion of the allowed cookie.
5.
Click OK.
The popup screen closes, and the system removes the allowed cookie from the security policy.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
If your application uses custom headers that must occur in every request, you can use the mandatory headers option to include them in the security policy. If you specify mandatory headers in the security policy, then the Security Enforcer verifies that requests contain those headers. If a request does not contain the mandatory header, the system issues the Mandatory HTTP header is missing violation, and applies the blocking policy to the request.
2.
On the menu bar, click Mandatory Headers.
The Mandatory Headers screen opens.
3.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
4.
Above the Mandatory Headers area, click the Create button.
The New Mandatory Header screen opens.
5.
From the Header list, select New Header.
6.
In the New Header box, type the header name.
7.
Click Create.
The screen refreshes, and you see the new mandatory header in the list.
8.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
The Application Security Manager accepts HTTP methods by default. The default methods are GET and POST. The system treats any incoming HTTP request that uses an HTTP method other than the allowed methods as an invalid request. If your web application uses HTTP methods other than the default allowed methods, you can use the Allowed Methods property to manage them.
1.
2.
In the editing context area, ensure that the edited web application and security policy are those that you want to update.
3.
Above the Allowed Methods area, click the Create button.
The New Allowed Method screen opens.
4.
For the Method option, choose one of the following actions:
Select New Method, and then type the name of a method in the New Method box. Use this option if the method you want to allow is not in the system-supplied list.
5.
In the Act as Method box, select one of the following options.
GET: Specifies that the request does not contain any HTTP data following the HTTP headers or headers section.
POST: Specifies that the request contains HTTP data following the HTTP headers or headers section.
6.
Click Create.
The screen refreshes, and on the Allowed Methods screen, you can see the additional allowed method in the Allowed Methods area.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
In addition to creating allowed methods, you can also edit or delete existing allowed methods, as required by changes in the web application. Simply check the box next to an existing allowed method, and click either the Edit or Delete button below the Allowed Methods section.
Blocking policy
The blocking policy specifies the blocking actions for all of the security policy violations. The blocking policy also specifies the enforcement mode for the security policy. For more information, see Configuring the blocking policy, following.
Evasion techniques detection
Sophisticated hackers have figured out coding methods that normal attack signatures do not detect. These methods are known as evasion techniques. Application Security Manager can detect the evasion techniques, and you can configure blocking properties for them. For more information, see Configuring blocking properties for evasion techniques.
Response pages
When the enforcement mode is blocking, and a request (or response) triggers a violation for which the Block action is enabled, the system returns the response page to the offending client. If you configure flow access, you can also configure a response page for blocked access. For more information, see Configuring the response pages.
The Blocking Policy screen is where you configure how the security policy reacts to a request that does not comply with the security policy. On the Blocking Policy screen, you configure the enforcement mode for the security policy, and the blocking actions for all of the violations.
The security policy has two enforcement modes: transparent and blocking. In transparent mode, the system allows requests to reach the web application if the request violates some aspect of the security policy. In blocking mode, the system does not allow requests that violate the security policy to reach the web application, and instead returns the blocking response page to the client. Note that the system blocks requests only for those violations with enabled Block flags. See Configuring the blocking actions, for more information on the Block flag.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
3.
In the Configuration area, for the Enforcement Mode setting, select either Transparent or Blocking.
4.
Click the Save button to save any changes you may have made on this screen.
5.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
From the Blocking menu, choose Settings.
The Blocking Policy screen opens.
4.
In the Configuration area, for the Enforcement Mode setting, select either Transparent or Blocking.
5.
Click the Save button to save any changes you may have made on this screen.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
On the Blocking Policy screen, you can view, and enable or disable, the Learn, Alarm, and Block flags, or blocking actions, for most violations. The blocking actions determine how the system processes requests that trigger the corresponding violation.
Learn
When the Learn flag is enabled for a violation, and a request triggers the violation, the system logs the request and generates learning suggestions. The system takes this action when the security policy is in both transparent mode and blocking mode.
Alarm
When the Alarm flag is enabled for a violation, and a request triggers the violation, the system logs the request, and also logs a security event. The system takes this action when the security policy is in both transparent mode and blocking mode.
Block
When the Block flag is enabled for a violation and a request violates a security policy that has the Block flag enabled, that request is not forwarded to the server. Instead, the system sends the blocking response page (which contains a Support ID to identify the request) to the offending client. If the violating request meets the conditions of the logging-profile filter that is assigned to the web application, the system logs the information. If a response from the web application triggers a violation for which the blocking action is enabled, the system sends the blocking response page to the client instead of sending the response.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
From the Blocking menu, choose Settings.
The Blocking Policy screen opens.
4.
Review each violation and adjust the Learn, Alarm, and Block flags as required. Note that you can configure the Block flags only when the enforcement mode is blocking.
5.
Click Save to save any changes you may have made on this screen.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
For every HTTP request that the Application Security Manager receives, the Security Enforcer applies a pre-processor to the requests that detects coding methods for attacks designed to avoid detection by attack signatures. These coding methods are known as evasion techniques.
You can enable or disable the blocking properties for these evasion techniques, but you cannot disable the evasion techniques detection.The system analyzes every request for evasion techniques regardless of whether you have enabled the blocking properties for the techniques.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
From the Blocking menu, choose Evasion Techniques.
The Evasion Techniques screen opens.
4.
For each evasion technique, check or clear the Enable Evasion Technique Checks check box as required.
5.
Click the Save button to retain any changes you may have made.
6.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
The Application Security Manager has a default response page that it returns to the client when the client request, or the web server response, is blocked by the security policy. This page is the blocking response page. The system also has a blocking response page for flow access violations. This page is the flow access response page. The properties of both blocking response pages are the same.
All response pages contain a variable, <%TS.request.ID()%>, that the system replaces with a support ID number when the system issues the page. Customers can use the support ID to identify the request when making inquiries.
Note: Both the blocking response page and the flow access response page have the same configuration options. The following task describes modifying the blocking response page, however, you can use the same process to modify the flow access response page.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
On the menu bar, click Response Page.
The Blocking Response Page screen opens.
4.
Below the Blocking Response area, click the Edit button.
The Blocking Response Page Properties screen opens.
5.
For the Response Type setting, select one of the following options:
Default Response: Specifies that the system returns the system-supplied blocking response page. Note that you cannot edit HTML code on the default response page.
Redirect URL: Specifies that the system returns a redirect URL to the client.
Custom Response: Specifies that the system returns a user-defined response page.
SOAP Fault: Specifies that the system returns the system-supplied blocking response page in XML format.
Note: The settings on the screen change depending on the selection that you make for the Response Type setting.
6.
If you selected the Redirect URL option in step 5, then in the Redirect URL box, type the URL to which the system redirects the client. The URL that you configure should be for a page that is not within the web application itself.
7.
If you selected the Custom Response option in step 5, you can either modify the default text or upload an HTML file.
a)
For the Response Header setting, click the Paste Default Response Header button, and make any changes as required. Note that you should use standard HTTP syntax for this setting and the Response HTML Code setting.
b)
For the Response HTML Code setting, click the Paste Default Response HTML Code button, and make any changes as required.
a)
For the Upload HTML File setting, either type a path to an HTML response page in the box, or click Browse and navigate to an HTML response page.
b)
Click Upload when you are finished.
8.
Click Save to save any changes you may have made.
9.
To put the security policy changes into effect immediately, click the Apply Policy button near the top of the Policy Properties screen.
1.
On the Main tab of the Application Security navigation pane, click Policy.
The Security Policy Properties screen opens.
2.
On the menu bar, click Response Page.
The Blocking Response Page screen opens.
4.
Below the Blocking Response area, click the Show button.
The Blocking Response Page popup screen opens, where you can view the text as it appears to recipients.
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)