We are used to the fact that websites contain links to another web services.
But, can automatic redirection to external domain be harmful? - about this in today's episode of "from 0 to pentesting hero".
If a part of the site's resources is available only to logged in users - after switching to restricted a subpage as a guest, we are
redirected to the login form. Often in the URL we can find parameters like 'redirect' or 'next', indicating the subpage to be displayed after authorization.
Today we will talk about these parameters and about the vulnerability called "Open redirection".
The described functionality is easy to implement. When the browser receives the Location header, it takes us to the address it leads to.
Most frameworks have functions to set this value. I will show very short example in Java where we pass the redirect parameter to the sendRedirect function.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class RedirectionExample extends HttpServlet {
@Override
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
response.sendRedirect(request.getParameter("redirect"));
}
}Normally, we pass here the address of the page to be displayed after logging in.
However, nothing prevents you from passing a different domain than the one currently used in this parameter.
For example, google.pl.
Now you can ask a question: but what's wrong with that?
Instead of going to our website, the user will only be directed to another site.
No data will leak. The visitor's bank account is safe - why so much noise?
To understand why - we have to learn what the phishing attack is.
- Phishing is a method of fraud where we impersonate someone or something to obtain some information that is interesting to us.
Example: we receive an email from our bank that someone tried to break into our account and for security reasons, we must change the account's password.
As we are aware of the danger - we check the address of the domain to which the link in the message directs.
The domain looks good - it is identical to the domain of our bank.
We click on the link and proceed to the password change procedure.
However, somehow we reach the website of the fruad who wants to extort our data.
But how did this happen? The bank's website was vulnerable to open redirection. - and the attacker made use of the confidence that is put in financial institutions and passed the particular redirection parameter.
While validating the name of the domain - the user saw the authentic domain of the bank, but he did not check the parameters following it.
We already know why we should check where the user is redirected.
It is time to present methods of bypassing the security.
The most common method is to check if the link starts with slash.
Such links refer to the content within our domain.
This filter can be bypassed by appending another slash to the slash. The double slash redirects you to the correct domain name.
Another idea is to check if the address starts with http or https.
The url can contain a login and password, that the user can use to log into a given site.
Using this functionality, we can provide the at sign after the required string, and then the domain to which we want to redirect.
Everything before the at sign will be treated as credentials.
The last frequently encountered filter is checking if the site that the user goes to contains our domain.
Here's an example: is google.pl in the name?
If the whole link is scanned for the occurence of this string, nothing can prevent us from creating a subdomain named google.pl that will be hosted under another domain.
The string that will bypass such filter can look like this: google.pl.szurek.pl.
And that's all in today's episode. Remember to redirect the user only to places you trust.
