Applies To:

Show Versions Show Versions

Manual Chapter: Automatically Creating Security Policies for AJAX Applications
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Application security for applications that use AJAX

Application Security Manager™ can protect AJAX applications including those that use JSON or XML for data transfer between the client and the server. If the AJAX application uses XML for data transfer, the security policy requires that an XML profile be associated with a URL or parameter. If the AJAX application uses JSON for data transfer, the security policy requires that a JSON profile be associated with a URL or parameter. If the AJAX application uses HTTP for data transfer, no profile is needed.

You can also set up AJAX blocking response behavior for applications so that if a violation occurs during AJAX-generated traffic, the system displays a message or redirects the application user to another location.

Overview: Creating a security policy for applications that use AJAX

AJAX (Asynchronous JavaScript and XML) applications make requests to the server and send responses to the client formatted using XML or JavaScript Object Notation (JSON). You can create a security policy automatically for applications that use AJAX.

Task Summary

Creating a security policy automatically

Before you can create a security policy, you must perform the minimal system configuration tasks including defining a VLAN, a self IP address, and other tasks required according to the needs of your networking environment.
Application Security Manager™ can automatically create a security policy that is tailored to help secure your web application.
  1. On the Main tab, click Security > Application Security > Security Policies > Active Policies. The Active Policies screen opens.
  2. Click the Create button. The Deployment Wizard opens to the Select Local Traffic Deployment Scenario screen.
  3. For the Local Traffic Deployment Scenario setting, specify a virtual server to use for the security policy.
    • Select Existing Virtual Server and click Next to use an existing virtual server (as long as it does not have an HTTP Class profile associated with it).
    • Select New Virtual Server and click Next to create a new virtual server and pool with basic configuration settings.
    The virtual server represents the web application you want to protect. The system automatically creates an HTTP class profile and a security policy with the same name as the virtual server. The Configure Local Traffic Settings screen opens.
  4. Configure the new or existing virtual server, and click Next. The Select Deployment Scenario screen opens.
  5. For Deployment Scenario, select Create a policy automatically and click Next. The Configure Security Policy properties screen opens.
  6. From the Application Language list, select the language encoding of the application, or select Auto detect and let the system detect the language.
    Important: You cannot change this setting after you have created the security policy.
  7. If the application is not case-sensitive, clear the Security Policy is case sensitive check box. Otherwise, leave it selected.
    Important: You cannot change this setting after you have created the security policy.
  8. If you do not want the system to distinguish URLs by protocol, clear the Differentiate between HTTP and HTTPS URLs check box.
  9. Click Next. The Configure Attack Signatures screen opens.
  10. To configure attack signatures, move the systems and platforms used by your web application from the Available Systems list into the Assigned Systems list. The system adds the attack signatures needed to protect the selected systems.
  11. For the Signature Staging setting, verify that the default option Enabled is selected.
    Note: Because the Real Traffic Policy Builder® begins building the security policy in Blocking mode, it is a good idea to keep signature staging enabled to make sure that false positives do not occur.
    New and updated attack signatures remain in staging for seven days, and are not enforced (according to the learn, alarm, and block flags) during that time.
  12. Click Next. The Configure Automatic Policy Building screen opens.
  13. For Policy Type, select an option to determine the security features to include in the policy.
    Option Description
    Fundamental Creates a security policy that enforces HTTP request protocol compliance, evasion techniques, explicit file types (including length checks), explicit global parameters (if learn explicit entities is enabled), attack signatures, the violation Request Length Exceeds Defined Buffer Size, and host names.
    Enhanced Creates a security policy with all the elements of the Fundamental policy type; also adds explicit URLs (if learn explicit entities is enabled) and global parameters (including length checks), checks meta characters in URLs, cookies, allowed methods, and applies the JSON or XML content profiles (if configured).
    Comprehensive Creates a security policy with all the elements of the Fundamental policy type; also checks for meta characters in URLs and parameters, adds explicit URL parameters, with length checks (more specific than global parameters), dynamic parameters, cookies, allowed methods, and applies the JSON or XML content profiles (if configured).
    A bulleted list on the screen describes which security features are included in each type.
  14. For Rules, move the slider to set the Policy Builder learning speed.
    Option Description
    Fast/High Use for a small number of requests from a small number of sessions; for example, useful for web sites with less traffic. However, there is a greater chance of adding false entities to the security policy.
    Medium Use for a medium number of requests, or if you are not sure about the amount of traffic on the application web site. This is the default setting.
    Slow/Low Use for a large number of requests from many sessions; for example, useful for web sites with lots of traffic. This option creates the most accurate security policy, but takes Policy Builder longer to collect the statistics.
    Based on the option you select, the system sets greater or lesser values for the number of different user sessions, different IP addresses, and length of time before it adds and enforces elements in the security policy.
  15. For Trusted IP Addresses, select which IP addresses to consider safe:
    Option Description
    All Specifies that the policy trusts all IP addresses. For example, if the traffic is in a corporate lab or pre-production environment where all of the traffic is trusted, the policy is created faster.
    Address List Specifies the networks to consider safe. Enter data into the IP Address and Netmask fields, then click Add. This option is typically used in a production environment where traffic could come from untrusted sources. The IP address can be either an IPv4 or an IPv6 address.
    If you leave the trusted IP address list empty, the system treats all traffic as untrusted. In general, it takes more untrusted traffic, from different IP addresses and over a longer period of time, to build a security policy.
  16. If you want the security policy to automatically detect JSON and XML protocols, select the JSON/XML payload detection check box. This option is available only for the Enhanced and Comprehensive policy types. If requests contain legitimate XML or JSON data, the Policy Builder creates content profiles in the security policy according to the data it detects.
  17. If you want to display a blocking response page when an AJAX request does not meet the security policy, select the AJAX blocking response behavior check box.
  18. Click Next. The Security Policy Configuration Summary opens where you can review the settings to be sure they are correct.
  19. Click Finish to create the security policy. The Automatic Policy Building Status screen opens where you can view the current state of the security policy.
The Policy Builder starts and automatically begins building the security policy by examining the traffic to the web application. The system sets the enforcement mode of the security policy to Blocking, but it does not block requests until the Policy Builder processes sufficient traffic, adds elements to the security policy, and enforces the elements.
Tip: This is a good point at which to test that you can access the application being protected by the security policy.

Reviewing security policy status

You can monitor the general progress of the Real Traffic Policy Builder®, see what policy elements the system has learned, and view additional details on the Automatic Policy Building Status screen.
  1. On the Main tab, click Security > Application Security > Policy Building > Status (Automatic). The Status (Automatic) screen opens.
  2. In the Current edited policy list, verify that the edited security policy is the one you want to work on.
  3. Review any messages in the identification and messages area to learn what is currently happening on the system. For example, messages say when the Policy Builder is enabled, when the security policy was last updated, and the number of elements that were learned.
  4. Review the status of the Real Traffic Policy Builder:
    Option Description
    Enabled The system is configured to automatically build a security policy, and the Policy Builder is processing traffic.
    Disabled The system is not processing traffic. Check the automatic policy building configuration.
    Detecting Language The system is still configuring the language after analyzing responses to identify the language of the web application. The Policy Builder is enabled, but it cannot add elements to the security policy until the language is set.
  5. Examine the General Progress of the security policy. A progress bar indicates the stability level of the security policy. The progress bar reaches 100% when the policy is stable, no new policy elements need to be added, and time and traffic thresholds have been reached.
  6. In the Policy Elements Learned area, review the number of elements that the Policy Builder has analyzed and added to the security policy, and the attributes that need to be updated.
    Tip: Click the number in the Elements column to see the specific elements that were added.
  7. Optional: In the Details tree view, click any item name to learn more about that security policy element. Below the Details tree view, the system displays information about the element, and what it will take to stabilize the element.
  8. Optional: Click a Staging sub-item to see details about elements that are available for addition to the policy. If you are confident the staged element should be in the security policy, click the Enforce button in the Action column to start enforcing that element in the security policy.
When enough traffic from unique sessions occurs over a period of time, the system starts to enforce the file types and other elements in the security policy. When enforced as part of a stable policy, the files types and other elements are removed from the staging list.

Implementation result

The Real Traffic Policy Builder® creates a security policy that can protect applications that use AJAX with JSON or XML for data transfer between the client and the server. The system examines the traffic and creates an appropriate profile. If the application uses XML, the security policy includes one or more XML profiles associated with URLs or parameters. If the application uses JSON, the security policy includes one or more JSON profiles associated with URLs or parameters.

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)