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.
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.
If protection is enabled and no domains are configured, then only relative URIs are allowed (for example, /login.php).
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.
|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.|
The security policy now learns new redirection domains according to the explicit learning setting you specified.
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.