Advisory: Open redirect on


An open redirect is operating at


Google’s main website provides a subsite for displaying mobile-optimized pages published using a special subset of HTML called AMP. While this works for mobile devices, for non-mobile devices, this redirects to the original site, thus resulting in an open redirect. The subsite operates at the following URL:

where XXXX is the URL of the site. Here is an example of a legit URL — in mobile browsers this would display the actual article (this can simulated using Chrome’s developer tools):

HOWEVER, on non-mobile devices this would redirect to:

Because the vendor accepts any site without whitelist, this can be used as an open redirect. Additionally, since this is hosted on the same main domain as the search engine, it can in theory be used to drive XSS or other similar attacks, although this is mitigated by the fact that AMP currently does not allow Javascript.

Vendor Response

The vendor communicated that they do not consider open redirects to be a security issue



Discovered and written by Yakov Shafranovich.


2016–04–07: Vendor notified
2016–04–07: Vendor response
2016–04–11: Public disclosure

Advisory: Open Redirect on


A marketing server at operated an open redirect.


Google’s main AdWords landing page takes a cd parameter indicating a specific country to target, which redirects to a country-specific page. Examples of such URL are as follows:



The cd parameter which specifies the country was not checked against a valid list of values. Instead, this parameter is used to replace the “com” value in the URL with the value from the cd parameter. For example:


This can be used to redirect users to a malicious page. Example URL with malicious content:

Redirects to:

The vendor communicated that they consider this a low level attack, and do not plan to track a fix for this issue. However, we have since confirmed that this issue has been fixed prior to publication.


Google Security CID: 9–6197000008153
Google’s view on open directs:


Discovered and written by Yakov Shafranovich


2015–08–07: Vendor notified
2015–08–07: Initial vendor response
2015–08–11: Vendor replicated the issue
2015–09–05: Follow up communications with vendor
2015–09–20: Fix confirmed
2015–10–12: Public disclosure

2016–03–14: Updated disclosure posted