Manual Chapter : Creating Security Policies for AJAX Applications

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 13.0.0
Manual 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.

Some web applications use AJAX authentications that submit the login form as an AJAX POST request, with the login details and response in JSON format. If so, you can create a login page with an authentication type of JSON/AJAX Request to protect against brute force attacks. You can use this login URL when configuring session awareness or login enforcement.

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.

Creating a simple security policy

Before you can create a security policy, you must perform the minimal system configuration tasks required according to the needs of your networking environment.
You can use Application Security Manager™ to create a robust, yet simple, security policy that is tailored to protect your web application. This is the easiest way to create a security policy.
  1. On the Main tab, click Security > Application Security > Security Policies > Policies List .
    The Policies List screen opens.
  2. Click Create New Policy.
    You only see this button when no policy is selected.
  3. In the Policy Name field, type a name for the policy.
  4. Leave Policy Type, set to Security.
  5. For Policy Template, select Fundamental.
  6. For Virtual Server, click Configure new virtual server to specify where to direct application requests.
    1. For What type of protocol does your application use?, select HTTP, HTTPS, or both.
    2. In the Virtual Server Name field, type a unique name.
    3. In the HTTP Virtual Server Destination field, type the address in IPv4 (10.0.0.1) or IPv6 (2001:ed8:77b5:2:10:10:100:42/64) format, and specify the service port.
      Tip: If you want multiple IP addresses to be directed here, use the Network setting.
    4. In the HTTP Pool Member setting, specify the addresses of the back-end application servers.
    5. From the Logging Profile list, select a profile such as Log illegal requests to determine which events are logged on the system.
  7. In the upper right corner, click Advanced.
    You can use default values for the Advanced settings but it's a good idea to take a look at them.
    • If you selected Fundamental or Comprehensive for the Policy Template, Learning Mode is set to Automatic and Enforcement Mode is set to Blocking.
      Tip: If you need to change these values, set application language to a value other than Auto detect.
    • If you know the Application Language, select it or use Unicode (utf-8).
    • To add specific protections (enforcing additional attack signatures) to the policy, for Server Technologies, select the technologies that apply to the back-end application servers.
    • You can configure trusted IP addresses that you want the security policy to consider safe.
  8. Click Create Policy to create the security policy.
ASM™ creates a security policy that immediately starts protecting your application. The enforcement mode of the security policy is set to Blocking. Traffic that is considered to be an attack such as traffic that is not compliant with HTTP protocol, has malformed payloads, uses evasion techniques, performs web scraping, contains sensitive information or illegal values is blocked. Other potential violations are reported but not blocked.

The system examines the traffic to the web application making suggestions for more specifically building the security policy. The Policy Builder selectively learns new entities like file types, parameters, and cookies used in requests to the application. When ASM processes sufficient traffic, it automatically adds the entities to the security policy, and enforces them.

The system applies a basic set of attack signatures to the security policy and puts them in staging (by default, for 7 days). If you specified server technologies, additional attack signatures are included. ASM reports common attacks discovered by comparison to the signatures but does not block these attacks until the staging period is over and they are enforced. That gives you a chance to be sure that these are actual attacks and not legitimate requests.

Tip: This is a good point at which send some traffic to test that you can access the application being protected by the security policy and check that traffic is being processed correctly by the BIG-IP® system. Send the traffic to the virtual server destination address.

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.

Overview: Adding AJAX blocking and login response behavior

Normal policy blocking and login response behavior could interfere with applications that use AJAX. If you want to display a message or redirect traffic without interfering with the user experience while browsing to an AJAX-featured web application, you need to enable AJAX blocking behavior (JavaScript injection). You can implement blocking and login response behavior for applications that use AJAX with JSON or XML for data transfer.

Important: You can implement AJAX blocking behavior only for applications developed using one of the following frameworks:
  • Microsoft® ASP.NET
  • jQuery
  • Prototype®
  • MooTools

By default, if you enable AJAX blocking behavior, when an AJAX request results in a violation that is set to Block, Application Security Manager performs the default AJAX response page action. The system presents a login response if the application user sends an AJAX request that attempts to directly access a URL that should only be accessed after logging in.

Note: Enabling AJAX blocking behavior has performance implications.

Configuring the blocking response for AJAX applications

Before you can complete this task, you need to have already created a security policy for your web application. The application needs to have been developed using ASP.NET, jQuery, Prototype®, or MooTools to use AJAX blocking behavior.
When the enforcement mode of the security policy is set to blocking and a request triggers a violation (that is set to block), the system displays the AJAX blocking response according to the action set that you define. If a login violation occurs when requesting the login URL, the system sends a login response page, or redirects the user.
  1. On the Main tab, click Security > Application Security > Policy > Response Pages .
  2. In the Current edited security policy list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click the AJAX Response Page tab.
  4. Select the Enable AJAX blocking behavior (JavaScript injection)? check box.
    The system displays the default blocking response and login response actions for AJAX.
  5. For the Default Response Page action setting, select the type of response you want the application user to receive when they are blocked from the application:
    • Custom Response lets you specify HTML text or upload a file to use as a replacement for the frame or browser page that generated the AJAX request. Include the text, then click Show to preview the response.
    • Popup message displays text in a popup window (default text is included).
    • Redirect URL redirects the user to the URL you specify. You can also include the support ID. For example: http://www.example.com/blocking_page.php?support_id=<%TS.request.ID()%>.
  6. For the Login Page Response action, select the type of response (types are the same as for default response page in Step 5).
  7. Click Save.
  8. To put the security policy changes into effect immediately, click Apply Policy.