|
Definition by OWASP:
|
|
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.
|
· The
users are trick by the attackers making users to submitting request to
attackers’ website unknowingly.
· Attackers
link the unvalidated redirect and trick user into clicking it.
·
Unsafe
forward to bypass security checks by the attackers.
·
Target
page is specified in an unvalidated parameter, allowing attacker to choose
destination page.
·
Redirect
will attempt to install malware and identify the sensitive information.
·
Unsafe
forward may allow access control bypass.
·
Reputation
of business can lost and business value of your users trust get affected
How attackers achieve
it
Unvalidated Redirects
Attackers
find a page with a redirect on it:
Through
phishing or some mechanism attackers get modify the above the URL link make the
user to click the link
Clicked on a URL which clearly had
the host name of mytrustedsite.com, we’re now on myuntrustedsite.com. What’s
more, there’s a logon form asking for credentials which you’d naturally expect
would be handled properly under the circumstances.
The code behind the page simply takes
the URL parameter from the query string, performs some arbitrary logging then
performs a redirect which sends an HTTP 302 response to the browser:
var url = Request.QueryString["Url"];
LogRedirect(url);
Response.Redirect(url);
The above mytrustedsite.com is authorised domain so the
user will click the URL this will lead to unvalidated redirects.
Redirect can be achieved by JavaScript:
- location
- location.href
- location.pathname
- location.search
- location.protocol
- location.hostname
- location.assign
- location.replace
|
/<![CDATA[
(function(g){
var
a=location.href.split("#!")[1];
if(a){g.location=g.HBR=a;}
})(window);
//]]>
|
Unvalidated Forwards
An
application having login page and after successful login a protected page which
is not accessible normally. Using Forward bypassing login page go directly
access protected page
Avoid unvalidated
redirects and forwards
· To identify the
vulnerability one should review the redirects and forwards of their site and
verify the target URL in any redirection is an allowable destination.
For eg:
Response.Redirect(“DestinationPage”);
Server.Transfer(“DestinationPage”);
· Whitelist more
important. All input must be validated against a whitelist of acceptable value
ranges.
var url =
Request.QueryString["Url"];
if
(!Uri.IsWellFormedUriString(url, UriKind.Absolute))
{
//
Gracefully exit with a warning message
}
This validation will make the untrusted data conforms to expected pattern of
URL.
·
In
the case of unvalidated redirects, we don’t need to have the URL in the
query string, let’s try it like this:
http://mytrustedsite.com/Redirect.aspx?Id=AD420440-DB7E-4F16-8A61-72C9CEA5D58D
The
entire code would then look something like this:
var id =
Request.QueryString["Id"];
Guid idGuid;
if
(!Guid.TryParse(id, out idGuid))
{ //
Gracefully exit with a warning message }
var db = new MyTrustedSiteEntities();
var
allowableUrl = db.AllowableUrls.SingleOrDefault(u => u.Id == idGuid);
if
(allowableUrl == null)
{
//
Gracefully exit with a warning message
}
LogRedirect(allowableUrl.Url);
Response.Redirect(allowableUrl.Url);
We
are still validate against the data type
and checking it against whitelist this code will provide extra
protection and ensure against manipulation.
· Create / use spider
crawl your own website(Look at the Log statuses)
300
– Serious Statuses
302
– Old page moved from location
307
– Proper validation.
Prevent unvalidated
redirects and forwards
·
Avoid
using redirects and forwards.
·
If
implemented, don’t use user parameter for identify the destination page. This
can be usually done while developing.
·
If
the destination parameter is unavoidable, ensure the parameter supplied is
valid and verified by the user.
·
It is recommended that any such destination parameters be a
mapping value, rather than the actual URL or portion of the URL, and that
server side code translate this mapping to the target URL.
·
Applications can use ESAPI to override the sendRedirect() method to make sure all redirect destinations are safe.
Avoiding such flaws is extremely important as they are target of
phishers trying to gain the user’s trust.
References:
Example Attack
Scenarios
Scenario #1: The application
has a page called “redirect.jsp” which takes a single parameter named “url”.
The attacker crafts a malicious URL that redirects users to a malicious site
that performs phishing and installs malware.
http://www.example.com/redirect.jsp?url=evil.com
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 administrative functionality for which the attacker isn’t
authorized.
http://www.example.com/boring.jsp?fwd=admin.jsp
.png){kind=small}
