Google Open URL Redirection Vulnerability which does the Social Engineering part too.

Twitter: @teh_h3ck

Email: vag[d0t]mourikis[@]

Open URL Redirection definition, quoted by OWASP:

"An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it."

I found the continue GET parameter quite interesting in google applications.

If I modify the continue GET parameter with a custom non-Google (third party) url. This resulted to an expected 404 error.

Next, I found a url that contained the continue GET parameter and I put myself to thought on how this could be used to help me accomplish my mission: URL Redirection.

For the bypassing part, I used the following url:

I first tried to use as the redirection endpoint but I received an error due to a missing authentication value, collected in the login process:


In the meantime I set up the custom url in my webserver:  

with the following image for the lulz:

If a malicious user sends the following url to a victim:

It will prompt him for his Google credentials:

Then, he would be redirected to the site specified in the continue GET parameter.


Logs from the nginx server: - - [29/Jun/2016:19:07:13 +0300] "GET /_ah/conflogin/?state=~AJKiYcFLp5x20nQY0NIp1ulrRE9hssO47z1naxH4xliuqrpBEVLVxkYEzpaR02bwnvs-xIKHCVHbzwFKg4J4C6udqTtmbhd8WdYq3lsYic5J4LWddy7S36NMfY4KNozOg9EW0GeMy7Jh7vURNuq7Y5_Rm-IVxVpyO35q7SfzU2MxTgEBbP11C2jYXMpAvwhKegiezJR_YW8CSLD7WHzfKsMhlOx2Jbkv3aG_e_dJi5OYMG3AP_C4FPIYn1UV5jKWQCOCYRkjmPShYfX4k_-eP65W5MPu8dXvjg HTTP/1.1" 200 613 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/601.6.17 (KHTML, like Gecko) Version/9.1.1 Safari/601.6.17"

Proof of Concept Video

The open redirect vulnerability works across all browsers and across all operating systems (mobile OS included).

I am open to any further responses and questions. Email me at vag[d0t]mourikis[@] to share your opinion.

Thanks for reading this post.


29th of June 2016 | Vendor Contact.

30th of June 2016 | Vendor replied that the bug is triaged and will be further investigated.

30th of June 2016 | Vendor replied that the bug does not affect the confidentiality or integrity of Google users.

30th of June 2016 | I sent further details about the bug.

1st of July 2016 | Vendor replied that redirection is part of the AppEngine login flow. "The open redirector itself is not a security vulnerability".

2nd of July 2016 | I asked more information about why is the redirection to third party websited is allowed after the Google authentication.

2nd of July 2016 | Vendor replied that the redirection is part of the appengine application.

2nd of July 2016 | I replied that the redirection is part of the login process, as the redirection does not work with the appengine application itself.

4th of July 2016 | Vendor replied that the app is working as intented.

5th of July 2016 | Public disclosure.