This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Client Side URL Redirect (OTG-CLIENT-004)"

From OWASP
Jump to: navigation, search
(Created page with "{{Template:OWASP Testing Guide v4}} == Brief Summary == aaa == Description of the Issue == aaa <pre> code here </pre> == Black Box testing and example == Blackbox testi...")
 
Line 2: Line 2:
  
 
== Brief Summary ==
 
== Brief Summary ==
aaa
+
In this phase, we check for Client Side URL Redirection, also known as Open Redirection, that is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be a malicious one. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.
 +
<br>
  
 
== Description of the Issue ==  
 
== Description of the Issue ==  
aaa
+
This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
 
+
<br>
 +
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.
 +
<br>
 +
A phishing attack example could be the following:
 +
<br>
 
<pre>
 
<pre>
code here
+
http://www.bank.com?redirect=http://www.fake-bank.com/
 
</pre>
 
</pre>
 
+
<br>
 
+
The victim that visits bank.com will be automatically redirected to fake-bank.com where an attacker could place a fake page to steal victim's credentials.
 +
<br>
 +
Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access. 
 +
<br>
  
 
== Black Box testing and example ==
 
== Black Box testing and example ==
Blackbox testing for XXX is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed.<br>
+
Blackbox testing for Client Side URL Redirect is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed. 
 +
<br>
  
 
== Gray Box testing and example ==  
 
== Gray Box testing and example ==  
'''Testing for XXX vulnerabilities:'''<br>
+
'''Testing for Client Side URL Redirect vulnerabilities:'''<br>
For example, looking at the following URL:
+
When we have to manually check for this type of vulnerability we have to identify if there are client side redirections implemented in the client side code (for example in the JavaScript code).
XXX
+
<br>
 
+
These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. (as you can see in the following snippet of code).
The HTML code will contains the following script:
 
 
 
 
<pre>
 
<pre>
XXX
+
var redir = location.search.substring(1);
 +
if (redir)
 +
window.location='http://'+decodeURIComponent(redir);
 
</pre>
 
</pre>
aaa
+
In the previous example the script does not perform any validation of the variable “redir”, that contains the user supplied input via the query string, and in the same time does not apply any form of encoding, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability.
 +
This implies that an attacker could redirect the victim to a malicious site simply by submitting the following query string: www.victim.com/?www.malicious-site.com
 +
When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
 +
<br>
 +
Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/
 +
<br>
  
 
== References ==
 
== References ==
Line 35: Line 49:
 
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
 
* Browser location/document URI/URL Sources - https://code.google.com/p/domxsswiki/wiki/LocationSources
 
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
 
** i.e., what is returned when you ask the browser for things like document.URL, document.baseURI, location, location.href, etc.
 +
* Krzysztof Kotowicz: "Local or Externa? Weird URL formats on the loose" - http://kotowicz.net/absolute/
 +
'''Tools'''<br>
 +
* DOMinator - https://dominator.mindedsecurity.com/

Revision as of 16:42, 16 December 2013

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

Brief Summary

In this phase, we check for Client Side URL Redirection, also known as Open Redirection, that is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be a malicious one. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.

Description of the Issue

This vulnerability occurs when an application accepts untrusted input that contains an URL value without sanitizing it. This URL value could cause the web application to redirect the user to another page as, for example, a malicious page controlled by the attacker.
By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Since the redirection is originated by the real application, the phishing attempts may have a more trustworthy appearance.
A phishing attack example could be the following:

http://www.bank.com?redirect=http://www.fake-bank.com/ 


The victim that visits bank.com will be automatically redirected to fake-bank.com where an attacker could place a fake page to steal victim's credentials.
Moreover open redirections could also be used to maliciously craft an URL that would bypass the application’s access control checks and then forward the attacker to privileged functions that they would normally not be able to access. 

Black Box testing and example

Blackbox testing for Client Side URL Redirect is not usually performed since access to the source code is always available as it needs to be sent to the client to be executed. 

Gray Box testing and example

Testing for Client Side URL Redirect vulnerabilities:
When we have to manually check for this type of vulnerability we have to identify if there are client side redirections implemented in the client side code (for example in the JavaScript code).
These redirections could be implemented, for example in JavaScript, using the “window.location” object that can be used to take the browser to another page by simply assigning a string to it. (as you can see in the following snippet of code).

var redir = location.search.substring(1); 
if (redir) 
window.location='http://'+decodeURIComponent(redir); 

In the previous example the script does not perform any validation of the variable “redir”, that contains the user supplied input via the query string, and in the same time does not apply any form of encoding, then this unvalidated input is passed to the windows.location object originating a URL redirection vulnerability. This implies that an attacker could redirect the victim to a malicious site simply by submitting the following query string: www.victim.com/?www.malicious-site.com When trying to check for this kind of issues, consider that some characters are treated differently by different browsers.
Moreover always consider the possibility to try absolute URLs variants as described here: http://kotowicz.net/absolute/

References

OWASP Resources

Whitepapers

Tools