В 2017 году Google заплатил около 3 млн. долларов экспериментаторам в рамках Vulnerability Reward Program, нашедшим уязвимости в продуктах Google. На этой неделе также получил вознаграждение Tom Anthony, сеошник из Великобритании, за выявление уязвимости, из-за которой можно было быстро индексироваться и получать чужой трафик. Ниже представлен перевод поста Тома с подробностями взлома.

Краткая версия:

Google имеет URL, по которому можно пингануть XML Sitemap. После пинга Google сканирует карту и парсит адреса в нём. Для любых сайтов с открытым редиректом (таких как LinkedIn, Facebook и тысячи eCommerce-сайтов) возможно пингануть сайтмап, который хостится у вас, и Google будет доверять этой карте также, как и зараженному сайту.

Используя в карте сайта большого интернет-магазина в Великобритании директиву hreflang я моментально был в ТОПе по разным конкурентным запросам в США.

Google уже пофиксил баг и заплатил вознаграждение в размере $1337.

Недавно мне удалось найти особенность в Google, которая позволяет атакующему отправить XML sitemap для сайта, к которому нет доступа. Так как этот файл может содержать директивы индексации, такие как hreflang, это позволяет атакующему использовать эти директивы и помогать своим сайтам ранжироваться в Google. В рамках эксперимента мне удалось попасть новым доменом без обратных ссылок на первую страницу поиска по очень сладким ключевым словам.

XML Sitemap и механизм пинга

Google позволяет владельцам сайтов отправлять xml-сайтмапы, это помогает ему узнать о новых адресах для краулинга, но также учитывает директивы hreflang, которые помогают узнать о существовании международных версий страницы. Google не рассказывает, как именно учитываются эти директивы в алгоритмах, однако, hreflang позволяет получать ссылочный вес и траст с другого урла, используя эти сигналы для ранжирования новых URL (например, многие люди ссылаются на английскую .com версию сайта, немецкая версия использует эти сигналы и лучше ранжируется в Google.de).

Вы можете отправлять сайтмапы для домена через Search Console, внутри файла robots.txt или с помощью специального URL для пинга. После отправки sitemap.xml с помощью ping Google сканирует файл в течение 10-15 секунд. Но это сканирование не будет отображаться в Search Console.

Помимо hreflang в sitemap.xml я пробовал другие директивы, такие как noindex или rel-canonical, но Google похоже их не использует.

Отправка файла в Google Search Console

Если вы попробуете отправить в GSC sitemap.xml, который включает урлы на другой домен, не принадлежащий вам, то консоль отклонит их.

Мы вернемся к этому моменту позже (извини, Jono!).

Открытые редиректы

Многие сайты используют URL-параметры для управления редиректами.

В этом примере после логина вас должно средиректить на page.html. Некоторые сайты с плохой гигиеной позволяют совершать открытые редиректы на другие домены. Часто даже не нужно дополнительное взаимодействие типа логина, они сразу перенаправляют пользователя.

Открытые редиректы встречаются часто и не рассматриваются, как опасные. Однако, некоторые компании пытаются защититься от подобных багов, но часто вы можете обойти их защиту.

Tesco является крупным ретейлером в Великобритании с оборотом £50 млрд. Я отправил этот пример Tesco (а также другим компаниям, об уязвимостях которых я знал в рамках эксперимента) и они уже это пофиксили.

Пинг sitemap.xml через открытые редиректы

Вышло так, что когда вы пингуете sitemap.xml, Google следует по редиректу, даже если он кросс-доменный. И что важно, он ассоциирует этот XML с доменом, который сделал редирект, и обрабатывает эту карту как для подтвержденного сайта.

В этом примере, evil.xml хостится на blue.com, но Google ассоциирует его с green.com. Используя это, вы можете отправлять сайтмапы для сайтов, которые вам не принадлежат, и отправить в них нужные директивы.

Эксперимент: Использование hreflang для воровства авторитета и бесплатного ранжирования

Мне было интересно, действительно ли Google доверяет кросс-доменным редиректам и пришлось провести эксперимент.

Я создал фейковый домен для компании в Великобритании, которая не работает в США и установил AWS сервер. Имитация сайта включала сбор нужного контента и небольшую перенастройку, смену валют/адресов и пр). Я не называю здесь имени компании, чтобы не навредить, поэтому назовем их условно victim.com.

Далее я создал фейковый sitemap, который хостился на evil.com, но содержащий только урлы с victim.com. Эти адреса содержали hreflang и ссылались на эквивалентный адрес на evil.com, указывая, что это US-версия victim.com. Далее я отправил этот sitemap через открытый редирект на victim.com через механизм пинга от Google.

В течение 48 часов сайт начал получать небольшое количество трафика по низкочастотным запросам (см. скриншот из Семраша).

Через несколько дней сайт начал показываться в ТОПе по конкурентным запросам на первой странице, насмотря на наличие в выдаче Amazon и Walmart.

Далее, для домена evil.com в панели для вебмастеров появилась ссылка с victim.com, хотя самой ссылки не было.

И тут я обнаружил, что могу отправлять sitemap.xml для victim.com прямо внутри Search Console домена evil.com.

Похоже, что Google связал сайты и Search Console для домена evil.com имеет возможность влиять на victim.com.

Searchmetrics показала увеличение трафика.

По отчетам Google Search Console сайт заработал миллионы показов и более 10 000 кликов из поиска, при этом я не сделал ничего для продвижения, а всего лишь отправил sitemap.xml!

Должен сказать, что я не давал людям возможность оплаты на evil.com, но если бы хотел, то можно было украсть много денег, настроить рекламу или как-то иначе монетизировать трафик. На мой взгляд это серьезные риски для пользователей Google, а также для компаний, которые полагаются на трафик из Google. Трафик моего сайта рос, но я остановил эксперимент.

Заключение

Этот метод полностью незаметный для victim.com — карты сайта не показываются на их стороне. Это первый известный мне пример прямого эксплойта алгоритма, а не простое манипулирование поисковыми факторами. Таким черным методом можно иметь неочевидное финансовое влияние на ряд компаний.

Первый баг-репорт был отправлен в Google 23 сентября 2017. 25 марта Google пофиксил все дырки и разрешил опубликовать эту статью.