Applies To:

Show Versions Show Versions

Manual Chapter: Mitigating Open Redirects
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Mitigating Open Redirects

Overview: Mitigating open redirects

Application Security Manager™ (ASM) can protect users from open redirects. An open redirect is a vulnerability where the server tries to redirect the user to a target domain that is not defined in the security policy. This vulnerability is one of the OWASP top ten application security risks.

Spammers use open redirects in phishing attacks to get users to visit malicious sites without knowing it. Often, the request includes a parameter, which contains a URL that redirects a user to an external web application without any validation. An example of this vulnerability is a request such as: https://www.good.com/redirect.php?url=http://www.evil.com.

This type of request may result in a response containing a Location header that points to a new target. For example:
    HTTP/1.1 200 OK 
    Location: http://www.evil.com

You can configure redirection protection and the domains where users are permitted to be redirected on a response header in an existing security policy. By default, redirection protection is enabled in ASM with a pure wildcard configured as an allowed domain (effectively providing no enforcement). You can adjust the settings so that the security policy allows redirect to specific domains, and protects against unvalidated redirects.

This feature does not affect internal redirection, which is always allowed. For example, the following example would be allowed even if redirection protection is enabled on the system.
       Location: /<anotherpage>/<onthisserver>/internal_redirect.php

Task Summary

Mitigating open redirects

You can configure an existing security policy in Application Security Manager™ (ASM) to protect users from being redirected by unvalidated redirects. By enabling redirection protection, you can help prevent users from being redirected to questionable phishing or malware web sites.
  1. On the Main tab, click Security > Application Security > Headers > Redirection Protection .
    The Redirection Protection screen opens.
  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. Make sure that the Redirection Protection check box is selected.
  4. In the Allowed Redirection Domains setting, configure the domains where users can be redirected.
    1. In the Domain Name field, type the name of the domain (in English-only, such as yahoo.com), or its IP address.

      If protection is enabled and no domains are configured, then only relative URIs are allowed (for example, /login.php).

    2. If you want users to be able to be redirected to sub-domains of the specified domain, select Include Sub-domains.
      If this check box is selected for f5.com, for example, then redirects to www.f5.com, mail.f5.com, and websupport.f5.com are also allowed. If it is not selected, redirection to sub-domains, such as www.f5.com, is not allowed. You need to add all allowed domains and sub-domains explicitly in that case.
    3. Click Add.
      The system adds the domain to the security policy’s list of allowed redirection domains.
    You can add up to 100 redirection domains. If you are using the Policy Builder for automatic policy building, you can leave the * wildcard configured to Add All Entities in the policy. When the tightening period is over and the policy is stable, the system will have added the redirection domains occurring within the traffic that it saw (if any), and then the system deletes the wildcard. If not using the Policy Builder, consider removing the * wildcard.
  5. In the Allowed Redirection Domains setting, select the * wildcard and click the Enforce button to delete it.
  6. Click Save to save your settings.
If ASM™ receives a request that attempts to redirect the user to a domain other than one that is listed in the redirection protection, the system issues an Illegal redirection attempt violation, which is an attack type of Open/Unvalidated Redirects. The violation is set to Learn, Alarm, and Block, by default. If the policy is in transparent mode, responses are always forwarded to the client. If the policy is in blocking mode, illegal redirection attempts are blocked.

Configuring how open redirects are learned

You can adjust the explicit entities learning settings for redirection domains. Explicit learning settings specify when Real Traffic Policy Builder® adds, or suggests you add, explicit redirection domains to the security policy.

  1. On the Main tab, click Security > Application Security > Policy Building > Settings .
    The Settings screen opens.
  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. In the General Policy Building Settings area, for the Explicit Entities Learning setting, for Redirection Domains, select the option for which Learning suggestions (based on real traffic) to use.
    Option Description
    Never (wildcard only) Specifies that when false positives occur, the system suggests relaxing the settings of the wildcard. If Policy Builder is running, it does not add domains to the list of allowed redirection domains, and does not remove the wildcard.
    Add All Entities Creates a comprehensive whitelist policy that includes all observed domains to the list of allowed redirection domains. If Policy Builder is running, it adds explicit domains to the security policy. When the security policy is stable, the * wildcard is removed. If Policy Builder is not running, the system suggests adding explicit domains. This is the default value.
  4. Click Save to save your settings.
  5. To put the security policy changes into effect immediately, click Apply Policy.

The security policy now learns new redirection domains according to the explicit learning setting you specified.

Enforcing redirection domains

After you create a security policy and traffic is sent to the web application, the system adds domains where users are redirected by means of learning explicit entities. Redirection protection is enabled by default with a pure wildcard. You can review the redirection domains that are ready to be enforced, and add them to the security policy.
  1. On the Main tab, click Security > Application Security > Policy Building > Enforcement Readiness .
    The Enforcement Readiness summary screen opens.
  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. To enforce all entities that are ready to be enforced, click Enforce Ready.
    If you click this button, you are done. Continue only if you want to review learning suggestions for redirection domains.
  4. In the Enforcement Readiness Summary, check to see if a number appears in the Have Suggestions column next to redirection domains.
    A number greater than zero indicates that an Illegal Redirection Attempt occurred, and the system made a learning suggestion.
  5. Click the number in the Have Suggestions column.
  6. Select the domains to which you want the security policy to allow users to be redirected, and click Accept.
  7. Click Security > Application Security > Blocking and check to be sure that the Learn, Alarm, and Block settings for the Illegal Redirection Attempt violation are selected.
The system adds selected redirection domains to the security policy and allows users to be redirected to them. Attempts at redirection to other domains will be blocked when the system is in blocking mode.
On the Policy Building Status (Automatic) screen, you can review the status of the security policy, see the policy elements that were added including the redirection domains, and view details about them.

Implementation results

When you configure redirection protection, Application Security Manager™ (ASM) protects users from being redirected to a web site that is not listed in the allowed redirection domains. If the pure wildcard is listed as an allowed domain, ASM™ allows redirection to all domains. If you want to check whether users are redirected by the application, you can leave the wildcard as an allowed domain and let the system learn the redirect domains.

For the allowed domains, the system does not enforce protocol differences: HTTPS and HTTP are treated the same.

ASM sets the explicit entities learning for redirection domains in the general policy building settings. The security policy learns, by default, all domains (Add All Entities) where users are redirected. If you are using automatic policy building, the system adds to the security policy the redirect domains that match the pure wildcard, and lists how many it added, in the policy elements learned table on the Status screen. When the security policy is stable, the Policy Builder removes the wildcard redirect domain from the security policy, and allows users to be redirected only to the redirect domains that were added to the policy.

If you are building the security policy manually, the system learns and suggests that you add the redirect domains that it detects. You can determine whether there are redirection domains with learning suggestions by looking at the Enforcement Readiness Summary. After you add the legitimate redirect domains to the security policy, you can consider removing the wildcard redirect domain from the security policy. As a result, the policy on redirects becomes more strictly enforced.

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)