Once started, access [http: // localhost: 8080](http: // localhost: 8080). There is a section labeled "Vulnerability" in the middle of the screen below.
The tenth from the top is the "Open redirectable login screen" link. When you click it, the following screen will be displayed.
Enter "ʻadmin" as the user ID and "
password` "as the password, and click the login button. The following screen will be displayed.
This is the only feature, but it is vulnerable to open redirects. The focus is on the URL. The URL of the login screen you first accessed is http: // localhost: 8080 / openredirect / login? Goto = / uid / serverinfo.jsp
, and the URL after login is http: // localhost: 8080 / uid / serverinfo It is .jsp
. You can guess that the query string goto = / uid / serverinfo.jsp
specifies the transition destination after login.
Please log out and click the link below this time.
http://localhost:8080/openredirect/login?goto=%2f%2f%6b%2d%74%61%6d%75%72%61%2e%67%69%74%68%75%62%2e%69%6f%2f%6f%70%65%6e%72%65%64
The same login screen as before is displayed. Log in again with "ʻadmin" and "
password` ".
Did you log in? I think you were able to log in, but before that you should see a login error screen like the one below.
Did you notice that the re-entered user ID and password were sent to an external site at this time?
Look at the browser URL on the login error screen. It is the URL of the external site (https://k-tamura.github.io/openred
). Although the login error screen was displayed, the login was actually successful, and the transition was made to an external site with an error screen similar to the screen of this Web application. After re-entering the user ID and password and clicking the login button, the redirect was redirected to the original transition destination, so some people may not have noticed the transition to the external site.
What is an open redirect?
In this way, open redirect is an attack that exploits the redirect function of a web application to direct users to a malicious site.
The attacker causes the user to click on a link like the one above, and unknowingly directs the user to the attacker's site. In addition, like this time, you may try to set up an elaborately spoofed login error screen on an external site to enter your user ID and password ("phishing"). This time it was a redirect from the trial app to my non-malicious site (https://k-tamura.github.io/
), but if this is a redirect from online banking to a malicious site, it will be difficult. That is.
An open redirect vulnerability may exist in a web application that has the ability to redirect users to a URL specified in a request parameter, such as this web application (Easy Buggy).
However, it's okay if you check that your web application doesn't redirect users to unexpected URLs. If you redirect to an arbitrary URL without checking it, the attacker can rewrite the request parameters and lead the user to a dangerous site.
What kind of implementation is it
What kind of implementation is the login function I tried this time? Take a look at the Source Code (https://github.com/k-tamura/easybuggy/blob/master/src/main/java/org/t246osslab/easybuggy/vulnerabilities/OpenRedirectServlet.java). The important parts are:
String gotoUrl = request.getParameter("goto");
if (gotoUrl != null) {
response.sendRedirect(gotoUrl);
} else {
I'm doing a sendRedirect
without validating the value of the request parameter goto
.
Measures for open redirect
So what kind of measures should be taken?
The workaround is simple: ** Check if the redirect destination is an appropriate URL as the transition destination **. However, what you have to be careful about is ** how to implement the check process **.
Even if you reject URLs that start with " http
"to prevent redirects to external sites, most browsers will still use" // k-tamura.github.io/openred
" as in the example above. Since it is interpreted as " http://k-tamura.github.io/openred
", it cannot be said that it is an appropriate measure. If the redirect destinations that can be allowed are clearly listed, it is considered safer to implement an implementation that checks only for an exact match than an implementation that checks for a partial match or a regular expression.
If the redirect destination is only /uid/serverinfo.jsp
, it is safest to modify it to the following implementation.
String gotoUrl = request.getParameter("goto");
if ("/uid/serverinfo.jsp".equals(gotoUrl)) {
res.sendRedirect(gotoUrl);
} else {
However, it may be better to consider whether such a function is really necessary in the first place, and if not, consider another method.
reference