Attacking Other Users
The majority of interesting attacks against web applications involve targeting the server-side application itself. Many of these attacks do of course impinge upon other users — for example, an SQL injection attack that steals other users’ data. But the essential methodology of the attacker is to interact with the server in unexpected ways in order to perform unauthorized actions and access unauthorized data.
Redirection Attacks
Redirection vulnerabilities arise when an application takes user-controllable input and uses this to perform a redirection, instructing the user’s browser to visit a different URL than the one requested. They are usually of less interest to an attacker than cross-site scripting vulnerabilities, which can be used to perform a much wider range of malicious actions. Redirection bugs are primarily of use in phishing attacks where an attacker seeks to induce a victim to visit a spoofed web site and enter sensitive details. A redirection vulnerability can lend credibility to the attacker’s overtures to potential victims, because it enables him to construct a URL which points to the authentic web site he is targeting, and which is therefore more convincing, but which causes anyone who visits it to be redirected silently to a web site controlled by the attacker.
In fact, many applications actually perform redirects to third-party sites as part of their normal function — for example, to process customer payments. This encourages users to perceive that redirection during a transaction is not necessarily indicative of anything suspicious. An attacker can take advantage of this perception when exploiting redirection vulnerabilities.
Finding and Exploiting Redirection Vulnerabilities
The first step in locating redirection vulnerabilities is to identify every instance within the application where a redirect occurs. There are several ways in which an application can cause the user’s browser to redirect to a different URL:
■ An HTTP redirect uses a message with a 3xx status code and a Location header specifying the target of the redirect. For example:
HTTP/1.1 302 Object moved
Location: https://wahh-app.com/showDetails.php?uid=19821
■ The HTTP Refresh header can be used to reload a page with an arbitrary URL after a fixed interval, which may be zero to trigger an immediate redirect. For example:
HTTP/1.1 200 OK
Refresh: 0; url=https://wahh-app.com/showDetails.php?uid=19821
■ The HTML <meta> tag can be used to replicate the behavior of any HTTP header and can, therefore, be used for redirection. For example:
HTTP/1.1 200 OK
Content-Length: 125
<html>
<head>
<meta http-equiv=”refresh” content=
”0;url=https://wahh-app.com/showDetails.php?uid=19821”>
</head>
</html>
■ Various APIs exist within JavaScript that can be used to redirect the browser to an arbitrary URL. For example:
HTTP/1.1 200 OK
Content-Length: 120
<html>
<head>
<script>
document.location=”https://wahh-app.com/showDetails.php?uid=19821”;
</script>
</head>
</html>
Circumventing Obstacles to Attack
It is very common to encounter situations in which user-controllable data is being used to form the target of a redirect, but is being filtered or sanitized in some way by the application, usually in an attempt to block redirection attacks. In this situation, the application may or may not be vulnerable, and your next task should be to probe the defenses in place to determine whether they can be circumvented to perform arbitrary redirection. The two general types of defense you may encounter are attempts to block absolute URLs, and the addition of a specific absolute URL prefix.
Blocking of Absolute URLs
The application may check whether the user-supplied string starts with http:// , and if so, then block the request. In this situation, the following tricks may succeed in causing a redirect to an external web site:
HtTp://wahh-attacker.com
%00http://wahh-attacker.com
http://wahh-attacker.com
[note the leading space]
//wahh-attacker.com
%68%74%74%70%3a%2f%2fwahh-attacker.com
%2568%2574%2574%2570%253a%252f%252fwahh-attacker.com
https://wahh-attacker.com
Alternatively, the application may attempt to sanitize absolute URLs by removing http:// and any external domain specified. In this situation, any of the preceding bypasses may be successful, and the following attacks should also be tested:
http://http://wahh-attacker.com
http://wahh-attacker.com/http://wahh-attacker.com
hthttp://tp://wahh-attacker.com
Sometimes, the application may verify that the user-supplied string either starts with or contains an absolute URL to its own domain name. In this situation, the following bypasses may be effective:
http://wahh-app.com.wahh-attacker.com
http://wahh-attacker.com/?http://wahh-app.com
http://wahh-attacker.com/%23http://wahh-app.com
Addition of an Absolute Prefix
The application may form the target of the redirect by appending the user-controllable string to an absolute URL prefix. For example:
GET /redir.php?target=/private/admin.php HTTP/1.1
Host: wahh-app.com
HTTP/1.1 302 Object moved
Location: http://wahh-app.com/private/admin.php
In this situation, the application may or may not be vulnerable. If the prefix used consists of http:// and the application’s domain name but does not include a slash character after the domain name, then it is vulnerable. For example, the URL
http://wahh-app.com/redir.php?target=.wahh-attacker.com
will cause a redirect to
http://wahh-app.com.wahh-attacker.com
which is under the control of the attacker, assuming that he controls the DNS records for the domain wahh-attacker.com .
If, however, the absolute URL prefix does include a trailing slash, or a sub- directory on the server, then the application is probably not vulnerable to a redirection attack aimed at an external domain. The best an attacker can probably achieve is to frame a URL that redirects a user to a different URL within the same application. This attack does not normally accomplish anything, because if the attacker is able to induce a user to visit one URL within the application, then he can presumably just as easily feed the second URL to them directly.
Preventing Redirection Vulnerabilities
The most effective way to avoid arbitrary redirection vulnerabilities is to not incorporate user-supplied data into the target of a redirect at all. There are various reasons why developers are inclined to use this technique, but there are usually alternatives available. For example, it is common to see a user interface that contains a list of links, each pointing to a redirection page and passing a target URL as a parameter. Here, possible alternative approaches include the following:
■ Remove the redirection page from the application, and replace links to it with direct links to the relevant target URLs.
■ Maintain a list of all valid URLs for redirection. Instead of passing the target URL as a parameter to the redirect page, pass an index into this list. The redirect page should look up the index in its list and return a redirect to the relevant URL.
If it is considered unavoidable for the redirection page to receive user- controllable input and incorporate this into the redirect target, one of the following measures should be used to minimize the risk of redirection attacks:
■ The application should use relative URLs in all of its redirects, and the redirect page should strictly validate that the URL received is a relative URL. It should verify that the user-supplied URL either begins with a single slash followed by a letter or begins with a letter and does not contain a colon character before the first slash. Any other input should be rejected, not sanitized.
■ The application should use URLs relative to the web root for all of its redirects, and the redirect page should prepend http://yourdomainname.com to all user-supplied URLs before issuing the redirect. If the user-supplied URL does not begin with a slash character, it should instead be prepended with http://yourdomainname.com/ .
■ The application should use absolute URLs for all redirects, and the redirect page should verify that the user-supplied URL begins with http://yourdomainname.com/ before issuing the redirect. Any other input should be rejected.
As with DOM-based XSS vulnerabilities, it is recommended that applications do not perform redirects via client-side scripts on the basis of DOM data, as this data is outside of the server’s direct control.
NEXT is..HTTP Header Injection………………………….,,,,,,,,,,,,,,,,,,,,,,,,,,
