.NET Remediation Guidance for CWE-601
Attackers may try to attempt to force a browser to redirect to a malicious site. The malicious site may be used to further abuse users’ trust in the form of a phishing attack or serving malicious content.
How does Veracode Static Engine detect flaws of this type?
- The analysis searches your binaries for locations that perform redirects, such as Response.Redirect(...).
- The analysis then checks if the URL contains data from an untrusted source, such as a web request, and opens a flaw.
How can I fix it and have the Veracode Static Engine automatically detect my fix?
We will look first at a strategies that remove the risk and that Veracode Static Engine will detect, then we will see strategies that reduce risk but require Mitigation by Design.Remediation: Hardcoded URL
One strategy to ensure that unsafe redirection does not occur is to not supply a redirection with untrusted data. This can be accomplished by ensuring that you only use hardcoded URLs for redirection:
Remediation: IsUrlLocalToHost
This flaw can be remediated by ensuring the URL is validated with the WebPages.RequestExtensions.IsUrlLocalToHost method. This method returns true if the provided URL is a local URL and not one with an authority/host external to the host. If there is functionality in your application to redirect a user to a return address after completing an operation, the following action may be present in a Controller:The problem with the above code snippet is that the “ret” parameter is not validated and could be any URL even to a malicious site. An attacker may construct a URL that to the user’s perspective will look like the following mysite.com/controller/login?ret=evilsite.com. This URL abuses the user’s trust of mysite.com which may have unknowingly been redirected to evilsite.com. The way to remediate this is to ensure that only local resources are redirected to with IsUrlLocalToHost:
This code snippet first checks that the “ret” parameter is local and only then redirects to the provided URL thus preventing external redirects.
Remediation: Whitelisted Hosts
In some cases it may be expected to redirect to an external service. In these cases it is recommended that before redirect the URL is validated to have a host/authority that is whitelisted. The only way for the scanner to detect that an external redirect is through hardcoding the URL being redirected to remove the untrusted data from the URL. This could be accomplished with a hardcoded dictionary that maps a request parameter to a key and returns a hard coded URL from the mapped value, like so:Mitigation: Whitelisted Hosts
In other cases where you are unable to map every single URL under the same host/authority, it is possible to still validate that the URL being redirected to is a whitelisted host. The scanner will not be able to detect that the whitelist is a code fix because the rest of the path is still populated with untrusted data. However, validating the URL’s authority is trusted can provide assurance that the redirection is not malicious. Such a strategy may be coded as:The above would not be recognized by the scanner due to not validating the path portion of the URL and replacing it with trusted data. This would require a mitigation proposal that would be then reviewed and approved by the security team within your organization. The residual risk is that any path of the whitelisted authorities could be specified.
Common Pitfall: string.EndsWith
In the above example, it may be tempting to write a whitelist that checks that the authority ends with a given whitelisted host. This would be useful in cases where you have redirects to subdomains and the top level domain (TLD) is whitelisted. One may try to code this as follows:However, such an example would result in any authority ending with “mysite.com” being trusted. This would include instances where an attacker registers a site with the authority of “evil-mysite.com” when the intent of the code was to only redirect to subdomains such as “trusted.mysite.com”. Ensure that validation routines are not overly permissive.
Mitigation: User Supplied External Redirects
In some applications it may not be feasible to build a whitelist of domains as is the case of social media sites when users post links to external sites. In such cases a notification should be displayed to the user prior to redirection clearly stating that they are leaving the trusted site and going to an external location, listing the location. Only upon acceptance from the user should the application perform the redirect.Additionally, if the URL is still a request parameter in this pattern, it is recommended to provide a nonce as well in the request so that the application can verify that the provided URL originated from the server. In such a case the server would show a hyperlink to an internal page with 2 parameters: one is the external URL, and the other the verifiable security nonce. This would limit an attacker from directly creating a URL to the redirection page in an attempt to trick people to accept the redirection to their malicious site. They would instead first have to have the application save the URL providing the application a chance to log where the malicious URL originated (IP address and/or authenticated user) for accountability.
.png){kind=logo}
