URL commonly referred to as a webaddress, which determines up the exactlocation of a webresourceovertheinternet. But what, if this URL gets redirects and takes you to the place where you never expected to? Today, in this article, we’ll take a tour on OpenRedirection and would learn how an attacker can deface a website by simply redirecting its URL to a malicious one.
Table of Content
· What is the URL?
· Introduction to Open Redirection
· Open Redirection Impact
· Open Redirection Exploitation
o Basic Redirection
o Base 64 Encoded Redirection
o URL Redirection with Hash values
o Redirection with Hash values using salt.
o Redirection over inside a Web page
o DOM-based Open Redirection
· Mitigation Steps
What is the URL?
A URL is an abbreviation to Uniform Resource Locator, which is nothing but an addresstoa unique resource or a file over the Internet. These resources can be anything, an HTML page, an image, or a CSS document.
A URL is composed of different segments – including a protocol, a domainname, or a path– which instructs the webbrowser about how to fetch a resource and thus are even managed by the webserver. However, it is the responsibility of the developer to validate the resources and its associated URLs and even the user-input parameters.
A basic URL is structured in a way as:
Introduction to Open Redirect
Have you ever noticed about the responsecodes that the web-application offer as “301” or “302”, they simply speak out about the URLredirection!
Many developers set up their web-applications in order to requestresourcesoverfrom the webpages or to send their visitorsto somedifferentlocation, that residewithin or outside the web-interface. To do so, they implement some basic functions such as header() in PHP, redirect() in Python, Response.Redirect() in C# and many others.
But this URL Redirection is often overlookedbythedevelopers, as the function they use, sometimes are notproperlyvalidated or filtered or even they lettheusers entertheirdesiredinput which thus further, could lead to one of the most common vulnerabilities i.e. “Open Redirect”.
“Open Redirect” or“Unvalidated Redirection” is possible when a web application acceptsuntrustedinput that could causethe webapplication to redirecttherequestto a URLcontainedwithinuntrustedinput. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing attack and steal user credentials.
Didn’t understood well, let’s check out the following scenario:
The user get’s a phishing email stating that “Example.com – A movie booking web-app” is giving its users “a free movie ticket” over the URL specified in the email as:
“ www.example.com/?url=www.abc.in“
The URL seems to be the genuine one, as it is having the domain name of “example.com”, but the same URL is thus having a redirecting over to “abc.in” which is nothing but the attacker’s fake web application.
Now, when the user opens up the URL and enters her credentials over the “example’s login portal”, and as she clicks on the loginbutton, she thus gets redirected to a different login page rather than example’s home page, as the Login button over example.com was suffering from “Open Redirect Vulnerability”. Therefore, now when she enters up her credentials again, they got compromised and thus then she’ll get redirected to the home page.
Open redirection Impact
Open Redirection is itself a minor vulnerability, but, it thus itself can cause major damage to the web-application when integrated with others as with “RCE” or “XSS”.
Therefore, it thus has been reported with “Medium Severity” with a CVSS score of “6.1” under:
· CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
So, in order to exploit this all, we’ve developed some PHP codes as the similar way the developer creates them to enable URL redirections into their applications, further we’ve even used a bWAPP-a vulnerable web-application and the PortSwigger lab.
Let’s Start !!
Basic Redirection
There are chances when the developer doesnotcare about the inputvalidations or filtrations or anything specific and simply implements the redirectionfunctions as header() and let the redirectedURL be in the cleartexts.
From the below image you can see that the redirected URL over at the “here” text, is simply reflected as in the cleartext, which means that if we click over on it, we’ll be redirected to “hackingarticles.in”.
So, let’s try to capture this all in our burpsuite monitor and check what we could manipulate over on.
From the above image, you can see that, in the “url=” parameter http://www.hackingarticles.in is travelling, let’s try to manipulate this simple clear text with “http://www.google.com”.
Simple !! From the below image you can see that, we’ve been redirected to “google.com” with a basic manipulation.
Encoded Redirection
In order to secure up the redirection process, sometimes the developers encode up the “url=”values and let the URL travel over on the internet as in with the redirection. The major encoding methods that a developer can implement are as the URL-encoding or the base-64 encoding.
But, as we are aware that encoding is a 1-way technique, thus this security can simply be breached if we know about what encoding methodology the developer used into all this.
URL Encoded Redirection
URL Encoding is one of the most common encoding methodologies that the developer use in order to disallowsome vulnerablecharacters such as “<” or “>”, to get embedded into the URL.
The following PHP code snippet shows up a basicURLdecoding redirection, which first decodes up the encoded input URL and then redirects it over to its desired destination.
Let’s try to bypass this encoding with some simple tricks.
From the following image, you can see that, as when I capturedup the ongoingHTTPRequest over of the “here” text, I was presented with the “url=” parameter containing the URLencodedredirectionlink.
By analyzing the captured request, it makes us clear that the “url=” parameter is having a simple basicURLencoded value. Though, let’s now try to encode our URL i.e. “https://www.ignitetechnologies.in” over from the encode tab in our burpsuite.
Cool!! Let’s check whether this would work or not. Manipulate the “url=” parameter with the ignite’sencoded value.
From the below image, you can see that, we’ve successfully defaced the website over with the “OpenRedirection”vulnerability with some simple clicks.
Double URL Encoded Redirection
Being a developer, he knows that, basicURLencoding can easily be bypassed with somesimpleclicks, therefore in order to make his application more secure with the redirection section, he implements “Double URL Encoding”, where he used the “urlencode() and urldecode()”function twice one after the other as in the home page and the redirection page respectively.
The following is the redirectioncodesnippet which speaks out about how the decoding is to be performed, thus this first take up the encoded URL and decodes it up, further with another urldecode function, it will thus decode the previous decoded URL and then pass it for the redirection.
So now, as we hover on the “here” text, we’ll find that this time the URL is not in the readable format, thus to be more precise let’s capture this all over in the burpsuite.
From the below image, you can see that the “url=” parameter’s value is different from the one that we see earlier when we hovered on the text, which simply means that, there is some more encoding over it.
Let’s copy it out and check it over in the decodetab. From the below image, you can see that we got the decoded URL to be as “http://hackingarticles.in” when we opted the “URL Decode” option for about two times.
Until now, we are aware that, this application is taking up the URL’s that are double-encoded.Let’s now try to deface this web-application by manipulating up its “url=” parameter value again with “https://ignitetechnologies.in”.
But wait, before that, we need to implement the doubleencoding methodology, which will thus make the redirection successful.
Copy the double encoded value, and paste it over to the “url=” value.
Great!! We are almost done, let’s click on the Forward button, and check out what it displays to us.
Base64 Redirection
URL Encoding is not the only encoding methodology that the developer implements, thus in order to make the redirectionprocessmoresecure, they may use base64, hex, octal, binary, HTML or anything specific.
From the below image, you can see that if we hover over the “here” text, we get the “url=” value in the encoded form. So, let’s try to bypass this encoding:
From the above image, you can see that if we hover over the “here” text, we get the “url=” value in the encoded form. So, let’s try to bypass this encoding:
In my burp suite monitor, I’ve captured up the ongoing request and have copied the “url=” value.
Now, with the copiedencodedvalue, I tried to decode it with differentencodingmethodologies, and thus there, I got it for Base64.
Cool !! As we are now aware of the encodingmethod, let’s now try to encode some other URL’s and check for their outcomes.
Back in the burpsuite, and in the decode tab, I’ve tried to encode “google.com” over with Base64. There I’ve further copied up its encoded value.
Let’s now manipulate the “url=” parameter with the copied value and thus then fireup the Forward buttonand check the response over back in the browser.
Great!! From the below image, you can see that we’ve again successfully bypassed this security.
Let’s check out why this all happened:
From the below code snippet, you can see that the developer is again trusting his visitors and is reliable on the header() function which firstdecodes up the encodedinputURL with URL decode and then with base-64 decoding, thus further redirects the user to his desired webpage.
URL Redirection with Hash values
Experienced developers use hash values, which immunesup the web–applications from the “Open Redirect” vulnerability, they could have used anyhashingalgorithm, whether it is MD5, SHA512 or SH1 or any other.
Some developers even implement the combination of URL and the hashvalues as we’ve used in this section i.e. when choose the “Copy Link Location” of “here” text we’ll get the output
From the below image, you can see that this time rather than the “url=” parameter, we have one more as “hash=”.
Now, if we manipulate the “url=” with “https://www.bing.com”and leavesupthehashvaluethesameasitwas, thus then we will face the error.
“As when we clicked on the “here” text, the redirection script will catch the passedURL and generateitshashvalue and compare the generated hash value with the hash value we have sent with the request, if both the hash values match the redirection would work else it will fail.”
Here in this segment, the developer used the MD5hashalgorithm.
So, let’s now try to exploit this major security again with some manipulations, but this time we need to encrypt our URL over with the MD5 hash.
With a basic MD5Hashgenerator, we’ve encrypted https://www.bing.com. Copy this all and craft it in with the URL.
Great!! From the below image you can see that, as soon as I execute the above-manipulated URL in the browser, I got redirected to my desired result.
Redirection with Hash values using salt
EncodedURL’s can be bypassed, URLparameter with a hash can even be misguided, but what, if the redirectedURLisencryptedwith asaltvalue?
Salt could be anything, it could be a combinationofcharacters, digits, alphanumeric, specialcharacter or anythingwewant. A salt further increases the security for redirecting the URL or even it make up impossible to deface a web-application.
But, there is still a chance to misguide the users, if we could guess up the salt value or even if the developer displays it in the URL itself.
From the below image, you can see that here the developer passed up his salt value in the URL as “ignite”. Cool!! This was all we need to deface this web-application, let’s try to do so.
Over in burpsuite, I’ve captured the ongoing HTTP Request that was generated with the “here” text.
Great!! So its time to manipulate the URL as we are nowawareofthesaltvalue, but wait we don’tknow the type of hashit is using. Okay !! with some permutations and combinations and some hit & trial methods, I got it as a SHA256 hash.
So let’s now try to deface this web-application by generating the hash value of our “URL” with the same procedure we decrypted that earlier.
Therefore you can do so over through this
SHA256 hash generator.
Copy this all - the URL and the generated Hash value; and thus manipulate it over in our burpsuite.
Woah!! We’ve successfully bypassed this security level which was expected to the most secure one.
Redirection over inside a web-page
So, up till now, we have seen that the developer redirects his visitors to the resources that were outside the web-application, but there are chances that he might set the redirect() or header()function to make its users, to travel the web-pages which reside inside the application's interface.
Let’s boot into our vulnerable web-application bWAPP as “bee : bug” and set the “Choose your bug” option to “Unvalidated Redirects & Forwards (2)”.
Thus, there on the page, if we hover the “here” text we can see that there is a “ReturnUrl=” parameter.
Let’s capture the passing HTTP Request over of the “here” text and check what we could grab with it.
From the below image, you can see that the “ReturnURL=” parameter is forwarding the user back to the “portal.php” page, which is thus nothing but a URL redirection and therefore can be leveraged to an “Open Redirect” vulnerability.
Isn't it great, that, if being a low privileged user, we can grabthecontent of the "configuration files"or anything specific for which we're not authorized to, and this all happens, when the developer patch up the “LFI” vulnerability?
So let’s try to do so - as we’re aware, that the configuration files reside inside the web-applications default folder. Thus it would be easy to call that up over from the “here” text, by manipulating the captured request with our desired URL.
http://192.168.0..11/bWAPP/unvalidated_redir_fwd_2.php?ReturnURL=config.php
As soon as we hit the Forward button, we got redirected to the config.inc which thus contains up all the basic configurations.
Great!! We’re into the config.inc file and though we are now having more information about our target’s server.
DOM-based Open Redirect
DOM-based open-redirectionvulnerabilitiesarise when a scriptwritesattacker-controllabledata into a sink that cantriggercross-domainnavigation which thus facilitatesphishingattacks against users of the websites.
So what is a sink?
A sink is a potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it.
The major sinks that could lead to DOM-based Open Redirection vulnerability are “location”
“location.hostname” “location.href” “location.pathname”.
So, let’s try to implement it, in some real scenarios over at
The Portswigger Academy and exploit this DOM-based Open Redirect vulnerability.
As we hit the “Access the lab” button, we get redirected over to a blog which is somewhere or the other suffering from “Open Redirection”.
But before that, we got something new as “Go to exploit server”, let’s check that out.
That’s nice, we’re having our exploit server here, let’s copy its URL and we’ll try to redirect that blog to our server.
So let’s open a specific blog-post, say the first one and check its source code with a simple right-click over any segment of the page.
Great!! From the below image, I was able to see that the “Back to Blog” text is with some URL and this seems to be an “Open Redirect”as “location” property is not validated or sanitized to user’s input and thus it is even having an onclickevent over it as “url=(https”
However, if we manipulatethe web-pageURL by integratingourexploitserver’sURL with “&url=” parameter as
web-security-academy.net/post?postId=1&url=https://acae1fa01f50080b2d7d801d30034.web-security-academy.net
From the above image, you can see that, now if I hover the “Back to Blog” section, I got the redirection link to as the one I manipulated earlier.
Let’s check out its output, by clicking over the “Back to Blog” text.
Great!! From the below image you can see that we’ve successfully solved this lab and we are thus redirected over to our exploit server.
Mitigation Steps
· The user-input should be properly sanitized and must be validated.
· The developer should set up a whitelist of his trustworthy URLs.
· If the developer is setting up any hash or a salt value, it should be hidden and not to be displayed in the URL.
· Instead of using the redirect function, the developer should implement specific links over on the text keywords.
· The web-application should pop out a warning when a user tries to redirect to an untrusted domain.
