F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Implementations
  5. Creating Security Policies for AJAX Applications
Manual Chapter : Creating Security Policies for AJAX Applications

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>

Creating Security Policies for AJAX Applications

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 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 secure your web application.
  1. On the Main tab, click Security > Application Security > Security 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.
    • To secure an existing virtual server that has no security policy associated with it, select Existing Virtual Server and click Next.
    • To create a new virtual server and pool with basic configuration settings, select New Virtual Server and click Next.
    • To create an active but unused security policy, select Do not associate with Virtual Server and click Next. No traffic will go through this security policy until you associate it with a virtual server. The Policy Builder cannot begin automatically creating a policy until traffic is going to ASM through the virtual server.
    The virtual server represents the web application you want to protect.
    The Configure Local Traffic Settings screen opens if you are adding a virtual server. Otherwise, the Select Deployment Scenario screen opens.
  4. If you are adding a virtual server, configure the new or existing virtual server, and click Next.
    • If creating a new virtual server, specify the protocol, virtual server name, virtual server destination address and port, pool member IP address and port, and the logging profile.
    • If using an existing virtual server, it must have an HTTP profile and cannot be associated with a local traffic policy. Specify the protocol and virtual server.
    • If you selected Do not associate with Virtual Server, you will have to manually associate the security policy with a virtual server at a later time. On the policy properties screen, you need to specify a name for the security policy.
    The Select Deployment Scenario screen opens.
  5. For Deployment Scenario, select Create a security policy automatically and click Next.
    The Configure Security Policy Properties screen opens.
  6. In the Security Policy Name field, type a name for the policy.
  7. From the Application Language list, select the language encoding of the application, or use Auto detect and let the system detect the language.
    Important: You cannot change this setting after you have created the security policy.
  8. 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.
  9. If you do not want the security policy to distinguish between HTTP/WebSocket and HTTPS/WebSocket Secure URLs, clear the Differentiate between HTTP/WS and HTTPS/WSS URLs check box. Otherwise, leave it selected.
  10. Click Next.
    The Configure Attack Signatures screen opens.
  11. To configure attack signatures, move the systems 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.
  12. For the Signature Staging setting, verify that the default option Enabled is selected.
    Note: Because ASM begins building the security policy in Blocking mode, you can keep signature staging enabled so you can check whether legitimate traffic is being stopped to reduce the chance of false positives.
    New and updated attack signatures remain in staging for 7 days, and are recorded but not enforced (according to the learn, alarm, and block flags in the attack signatures configuration) during that time.
  13. Click Next.
    The Configure Automatic Policy Building screen opens.
  14. For Policy Type, select an option to determine the security features to include in the policy.
    Bulleted lists on the screen describe the exact security features that are included in each type.
    Option Description
    Fundamental Creates a robust security policy that is appropriate for most applications.
    Enhanced Creates a more specific security policy with additional customization such as learning URLs, cookies, and content profiles; includes tracking of user login sessions and brute force protection.
    Comprehensive

    Creates the most secure policy providing the greatest amount of customization, including all the Enhanced features and more traffic classification at the parameter and URL levels, dynamic parameters, and CSRF URLs.
  15. For the Policy Builder Learning Speed setting, select how fast to generate suggestions for the policy.
    Option Description
    Fast Use if your application supports a small number of requests from a small number of sessions; for example, useful for web sites with less traffic. Policy Builder requires fewer unique traffic samples to make decisions in Automatic Learning Mode, or to reach a high learning score. However, choosing this option may present a greater chance of adding false entities to the security policy.
    Medium Use if your application supports 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 Use if your application supports a large number of requests from many sessions; for example, useful for web sites with lots of traffic. Policy Builder requires a large amount of unique traffic samples to make decisions in Automatic Learning Mode, or to reach a high learning score. This option creates the most accurate security policy, but it 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 suggestions to the security policy and if you are using automatic learning, enforces the elements.
  16. For Trusted IP Addresses, select which IP addresses to consider safe:
    Option Description
    All Specifies that the policy trusts all IP addresses. This option is recommended for traffic in a corporate lab or preproduction environment where all of the traffic is trusted. The policy is created faster when you select this option.
    Address List Specifies networks to consider safe. Fill in 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, over a longer period of time to build a security policy.
  17. If you want to display a response page when an AJAX request does not adhere to 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 Policy Properties screen opens.
ASM™ creates the virtual server with an HTTP profile (or associates an existing one), and on the Security tab, Application Security Policy is enabled and associated with the security policy you created. A local traffic policy is also created and by default sends all traffic for the virtual server to ASM. The Policy Builder automatically begins examining the traffic to the web application and making suggestions for building the security policy (unless you did not associate a virtual server). 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 and check that traffic is being processed correctly by the BIG-IP® system.

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 policy list near the top of the screen, verify that the edited security policy 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.
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information