Pornhub обходит блокировщики рекламы с помощью вебсокетов

Инженер из компании BugReplay нашёл отличный способ продемонстрировать, как работает его сервис скринкаста с записью сетевого трафика и демонстрацией ошибок, в том числе WebSockets и JavaScript. Он записал скринкаст загрузки Pornhub с отображением лога трафика, который синхронизирован с видео. Так вот, на этой демонстрации отлично видно, каким образом Pornhub обходит блокировщики рекламы и пропихивает рекламу с помощью вебсокетов.

Pornhub работает очень грамотно. Когда вы заходите на сайт, он проверяет наличие блокировщика. Если такой обнаружен, то сайт открывает новое соединение WebSocket, которое действует в качестве резервного механизма доставки рекламы.

На скринкасте с сетевым логом можно увидеть множество запросов, которые заблокировал uBlock Origin. Они помечены как Failed в сетевом трафике.

http://cdn1b.static.pornhub.phncdn.com/www-static/js/ph-tracking.js?cache=2016102525
GET Failed

https://www.etahub.com/trackn?app_id=971&product_name=2&category=loadEventEnd&action=other&label=&value=1850
GET Failed

При нажатии на запрос отображаются подробности. Причина блокировки: net::ERR_BLOCKED_BY_CLIENT. Такая ошибка возникает, когда блокировщик рекламы в браузере блокирует некоторые Ajax-вызовы (по крайней мере, в Chrome всё работает именно так).

Сразу после сообщения об ошибке в логе мы видим запрос на создание вебсокета и фреймов, на который в итоге получен положительный ответ.

ws://ws.adspayformy.site./nsoj
webSocketCreate

ws://ws.adspayformy.site./nsoj
webSocketFrameReceived

Словно извиняясь перед пользователями, Pornhub использует для создания вебсокета домен adspayformy.site. Шутка явно нацелена на тех, кто использует блокировщики рекламы.

После загрузки вебсокета создаётся фрейм, куда загружается закодированный JSON-контент для каждого места на странице, где должен быть рекламный баннер.

{
"zone_id": 32,
"link": "http://cp.pleasedontslaymy.download/_z/eyJj...In19",
"media_type": "image",
"media_encoding": 0,
"img_data": "/9j/4QA.....Wh+n//2Q==",
"img_type": "image/jpeg"
}

В данном случае указан zone_id 32, который указывает на место для внедрения рекламы. Обычно туда вставляется видео, но в данном примере это графический баннер, что указано в media_type. Контент кодируется в base64 и восстанавливается в браузере в соответствии со схемой data: URL (или data: URI), которая поддерживается практически всеми современными браузерами. На и затем в эту схему передаются данные помеченные как image/jpeg.

Блокировщики рекламы обычно отслеживают вебсокеты, поэтому кодирование данных в base64 – тоже грамотный шаг.

Разумеется, после раскрытия грязных методов Pornhub долго музыка играть не будет. Уже 25 октября один из разработчиков в сообществе Chromium под ником pkalinnikov предложил патч, с помощью которого в браузере появится возможность блокировать вебсокеты через webRequest API. Если патч примут, то блокировщики рекламы смогут спокойно реализовать нормальный способ блокировки таких хаков в Chrome, ну а владельцам Pornhub придётся искать новые трюки в вечной борьбе с блокировщиками, которая никогда не прекратится.

После выхода публикации от разработчика BugReplay выяснилось, что некоторые блокировщики рекламы научились блокировать вебсокеты проде тех, что использует Pornhub. По крайней мере, вебсокет уже не пролазит через uBlock Origin (соответствующий тикет) и AdBlock Plus (тикет). А вот блокировщик AdBlock и некоторые другие пока не обновились.

История с «багом» Chrome webRequest API, который не позволяет перехватывать запросы WebSocket (тикет 129353) очень интересная. Этот тикет открыт ещё в мае 2012 года. И до сих пор остаётся открытым. Обсуждение продолжалось очень долго. Пользователи жаловались в обсуждении, что из-за невозможности блокировать вебсокеты сайты могут относительно просто обходить блокировщики рекламы. Ведь если блокировщик не отслеживает вебсокеты через стандартные API, то для блокировки такой рекламы нужно искать очень трудные обходные пути. В первое время это была чисто теоретическая проблема. Вроде бы в 2012 году ни один сайт не использовал такие методы обхода блокировщиков рекламы, да и сами блокировщики были в то время не настолько популярны, как сейчас.

Ситуация изменилась в 2015 и 2016 году. Сейчас Pornhub не единственный сайт, который додумался до такого хака. Что самое интересное, в обсуждении тикета в Chromium в августе 2016 года выступил один из разработчиков. Он убедительно объяснял, что блокировщики рекламы пытаются переписывать содержимое вебсокетов — и это реально угрожает безопасности пользователей, потому что ломает базовую функциональность Javascript. То есть внедрять этот патч — значит, жертвовать безопасностью. Всё бы ничего, но этот разработчик routeh...@gmail.com работает в компании MindGeek, которой принадлежит и сайт Pornhub, и рекламная сеть By Traffic Junky, которая поставляет туда рекламу. Кстати говоря, аналогичные трюки по обходу блокировщиков рекламы действуют не только на Pornhub, но и на других сайтах компании MindGeek.

Похоже на то, что в порнокомпаниях работают довольно продвинутые программисты. Как известно из истории, именно порноиндустрия часто двигала вперёд технологический прогресс. Оказывается, и сейчас они кое в чём опережают всех остальных. Хотя бы в самых инновационных методах обхода блокировщиков рекламы. Правда, в том же обсуждении в трекере Chomium сообщали, что трюк с вебсокетами применяют и некоторые другие рекламные сети, упоминалась некая сеть RevDefender.

Пожелаем удачи товарищу pkalinnikov, чтобы его патч приняли в кодовую базу Chromium. Судя по всему, это один из ведущих разработчиков Chromium, так что положимся на его авторитет.

Автор: alizar

Источник