Google отказалась устранять баг на странице входа в учетную запись Google, связанный с параметром continue. Более того, корпорация заявила, что не считает этот баг уязвимостью, сообщает исследователь по безопасности Айдан Вудс (Aidan Woods), который передал компании о найденной ошибке и получил ответ.
Добавление параметра continue в URL сервера Google.com позволяет при правильном введении пароля перенаправить пользователя в тот сервис Google, в который он намеревался войти.
Чтобы избежать фишинговых ссылок, Google ограничила работу параметра continue серверами в домене google.com. Таким образом, редирект может выполниться, например, на drive.google.com или docs.google.com, но не может на example.com.
Айдан Вудс нашел способ, как это ограничение обойти. Сервер Google.com поддерживает технологию проекта Accelerated Mobile Pages (AMP), которая позволяет выполнять редирект на мобильную версию сайта (при ее наличии), если пользователь переходит по ссылке на этот сайт с мобильного устройства. Для того чтобы заставить технологию работать, необходимо дописать к google.com выражение /amp/, после которого указать адрес сайта, например, google.com/amp/example.com. На мобильном устройстве в этом случае откроется версия сайта, оптимизированная под небольшой экран. На десктопе пользователь увидит полноценную страницу.
Баг, по мнению Вудса, заключается в том, что сервер Google никак не проверяет безопасность ссылки, указанной после параметра amp, а также в том, что ссылка может быть любая, на любой сайт в мире (иначе смысл технологии нарушается).
Таким образом, добавив к google.com параметр continue и написав после него сылку с выражением amp, можно заставить сервер выполнить редирект на любой сайт. Например, http://acounts.google.com/ServiceLogin?continue=https://www.google.com/amp/example.com&service=mail после удачного ввода пароля приведет на сайт example.com, который не имеет с Google ничего общего.
Вудс утверждает, что это может быть орудием злоумышленников: достаточно распространить письмо с соответствующей ссылкой на сайт Google.com, подставив в него ссылку на вредоносный сайт, на который пользователь в итоге попадет. Этот вредоносный сайт можно сделать копией интерфейса любого из сервисов Google, а после того, как пользователь на нем окажется, попросить ввести пароль и похитить его. В этом суть фишинга.
Злоумышленник может поступить еще проще: просто сделать редирект на вредоносный файл, хранящийся в drive.google.com, так как этот адрес проходит проверку при редиректе (он находится в зоне Google). Файл скачается на компьютер жертвы автоматически.
В переписке с Google Вудс объяснил ситуацию и предоставил примеры. «Спасибо за ваше исследование и отчет, которые помогают нам повышать безопасность наших пользователей! Мы изучили предоставленную вами информацию и приняли решение не считать вашу находкой уязвимостью», — ответили в компании.
Примечательно, что в блоге Google Webmasters представители компании еще в 2009 г. написали, что не считают открытый редирект с сайта Google.com уязвимостью.
Добавление параметра continue в URL сервера Google.com позволяет при правильном введении пароля перенаправить пользователя в тот сервис Google, в который он намеревался войти.
Чтобы избежать фишинговых ссылок, Google ограничила работу параметра continue серверами в домене google.com. Таким образом, редирект может выполниться, например, на drive.google.com или docs.google.com, но не может на example.com.
Айдан Вудс нашел способ, как это ограничение обойти. Сервер Google.com поддерживает технологию проекта Accelerated Mobile Pages (AMP), которая позволяет выполнять редирект на мобильную версию сайта (при ее наличии), если пользователь переходит по ссылке на этот сайт с мобильного устройства. Для того чтобы заставить технологию работать, необходимо дописать к google.com выражение /amp/, после которого указать адрес сайта, например, google.com/amp/example.com. На мобильном устройстве в этом случае откроется версия сайта, оптимизированная под небольшой экран. На десктопе пользователь увидит полноценную страницу.
Баг, по мнению Вудса, заключается в том, что сервер Google никак не проверяет безопасность ссылки, указанной после параметра amp, а также в том, что ссылка может быть любая, на любой сайт в мире (иначе смысл технологии нарушается).
Таким образом, добавив к google.com параметр continue и написав после него сылку с выражением amp, можно заставить сервер выполнить редирект на любой сайт. Например, http://acounts.google.com/ServiceLogin?continue=https://www.google.com/amp/example.com&service=mail после удачного ввода пароля приведет на сайт example.com, который не имеет с Google ничего общего.
Вудс утверждает, что это может быть орудием злоумышленников: достаточно распространить письмо с соответствующей ссылкой на сайт Google.com, подставив в него ссылку на вредоносный сайт, на который пользователь в итоге попадет. Этот вредоносный сайт можно сделать копией интерфейса любого из сервисов Google, а после того, как пользователь на нем окажется, попросить ввести пароль и похитить его. В этом суть фишинга.
Злоумышленник может поступить еще проще: просто сделать редирект на вредоносный файл, хранящийся в drive.google.com, так как этот адрес проходит проверку при редиректе (он находится в зоне Google). Файл скачается на компьютер жертвы автоматически.
В переписке с Google Вудс объяснил ситуацию и предоставил примеры. «Спасибо за ваше исследование и отчет, которые помогают нам повышать безопасность наших пользователей! Мы изучили предоставленную вами информацию и приняли решение не считать вашу находкой уязвимостью», — ответили в компании.
Примечательно, что в блоге Google Webmasters представители компании еще в 2009 г. написали, что не считают открытый редирект с сайта Google.com уязвимостью.
.png)