Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.
As you can see in the official definition, the issue here is redirection. Or, to be precise, the issue is redirection in a non secure manner.
The official documentation suggests that the best ways to find out whether some software includes dangerous forwarding of redirects are as follows:
- Revise the code for any redirection or forwarding (transfer in .NET). Once identified, check whether the target URL is included in any parameter values. In case it is, the target URL is not being validated against a whitelist, and therefore, you are vulnerable.
- The other possibility is that the site generates redirects, which correspond to HTTP response codes 300-307, and, typically a 302 code. Here, we should check the parameters supplied before redirection in order to see whether they look like a target URL or a fragment of a URL. If they do, you have to change the URL target and observe whether the site redirects to the new target.
- If there's no code to review, then you should check all the parameters in the search for the same URL patterns, testing those that really perform redirection.
The documentation includes a couple of samples of an attack, which we can adapt to a .NET environment:
- Scenario #1: The application has a page called
redirect.aspx, which takes a single parameter namedurl. The attacker crafts a malicious URL that redirects users to a malicious site that performs phishing and installs malware:http://www.example.com/redirect.aspx?url=evil.comIn this case, the problem is that next to the
urlparameter, the attacker might get redirected to a site of their own or another kind. - Scenario #2: The application uses forwards to route requests between different parts of the site. To facilitate this, some pages use a parameter to indicate where the user should be sent if a transaction is successful. In this case, the attacker crafts a URL that will pass the application's access control check and then forwards the attacker to the administrative functionality for which the attacker isn't authorized:
http://www.example.com/something.aspx?fwd=admin.aspx
Remember that this type of behavior is common in web development.