Обход блокировки счётчиков отслеживания посещаемости через прокси

logo

site-analytic-logo Большинство современных сервисов сбора статистики о посещаемости сайтов делают код счётчиков на JavaScript с прямой загрузкой со своих серверов, но такой способ давно неэффективен по причине блокировки скриптов со сторонних доменов самим браузером и/или установленным плагином типа uBlock.

Данная проблема блокировки JavaScript со сторонних доменов касается не только счётчиков отслеживания посещаемости. Так, для примера, есть куча сайтов подключающих скрипты из разных CDN-сетей, в итоге чего страдает функциональность сайта и отражается на его внешнем виде в браузере пользователя заблокировавшего скрипты со сторонних доменов, кроме посещённого в данный момент - открыл сайт, а он косой/кривой и нихера там нельзя понять, а далее начинаешь один за другим по-очереди разрешать кучи скриптов с около десятка сторонних доменов раз за разом перезагружая страницу, либо закрываешь его так и не добившись нормального его отображения.

Некоторые сервисы сбора статистики для обхода блокировки счётчика делают несколько специально созданных доменов/поддоменов, которые спустя некоторое время один шиш попадают в регулярно обновляющиеся чёрные списки блокировщиков скриптов и рекламы.

Таким образом, по предварительным подсчётам, из-за блокировки счётчика около трети визитов не учитываются в статистике посещаемости.

Для чего нужен обход блокировки счётчиков

Здесь кому как.


Владельцу веб-ресурса для анализа интересов, демографии, с последующей коррекцией своей деятельности.

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

Противники отслеживания (DNT, Do Not Track) сейчас видимо будут кидать в меня камни за попытку обхода блокировки счётчиков. Для учёта настроения пользователя/клиента в данном вопросе существуют два специальных HTTP-заголовка, - "DNT" (Expresses the user's tracking preference.) и "Tk" (Indicates the tracking status of the corresponding response.): https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers#Do_Not_Track

Противникам отслеживания (DNT, Do Not Track) хочу сказать, что незамеченным в современном мире не останется никто, включая Интернет юзеров, независимо от внутреннего/внешнего "хочу-не хочу" или настроек браузера на посыл заголовка "DNT: 1", который тупо может быть "похерен".

Здесь всё так же, как и в реальной жизни (сплошное разводилово и кидалово), если на продукте питания написано, что в его составе нет "Е" добавок, то это вовсе не означает, что их там действительно нет!

Тем же, кто реально хочет избежать отслеживания нужно как хамелеон гримироваться/маскироваться, а не тупо биться о стены на каждом шагу (в магазинах, на улицах/дорогах) увешанные видеокамерами и системами отслеживания посещаемости ;)

Как обойти блокировщики скриптов и рекламы

Как следует из заголовка данной статьи обход блокировки счётчиков посещаемости предполагается посредством проксирования запросов к тому или иному серверу сбора статистики (тьма их разных). Однако, как известно, дьявол кроется в деталях - рассмотрим их подробнее.

Ключевые слова в строке запроса и JavaScript функциях

Большая часть счётчиков посещаемости блокируется блокировщиками скриптов и рекламы по наличии определённых ключевых слов в строке запроса. Так, например запрос будет блокирован плагином uBlock/uMatrix при наличии в строке запроса хотя бы одного из ключевых слов:

Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!

Первые два ключевые слова из строки запроса к серверу top-fwz1.mail.ru, последнее ключевое слово "action_name" из строки запроса к движку сбора аналитики Matomo. Видно, что переменным строки запроса даются осмысленные имена, которые отлавливать проще простого.

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

Думаю, сам собой напрашивается вывод: почти любой JavaScript скрипт от большинства существующих сервисов статистики нуждается в редактировании имён переменных пересылаемых в строке запроса, и именно с этого нужно начинать проксирование счётчика, а после выбирать вариант проксирования коих на данный момент можно придумать только два - это серверное и программное проксирование.

И для того чтобы оно (проксирование) работало мы сразу же пропатчим код JavaScript счётчика от ".mail.ru" например, в котором заменим:

GET https://top-fwz1.mail.ru/js/code.js

var b="https://top-fwz1.mail.ru"+a
на
var b=location.protocol+"//"+location.hostname+a

/counter
на
/cntalias

/tracker
на
/trkalias

Сохраним изменённое содержимое файла "/code.js" на нашем сервере, в коде вставки счётчика изменим путь к нашему новому "/code.js". Теперь все запросы вместо "https://top-fwz1.mail.ru/counter?..." будут направлены на наш сервер "https://example.com/cntalias?...". Вместо "cntalias" и "trkalias" можно использовать любые "бла-бла" словосочетания на своё усмотрение, главное дабы они не носили осмысленного содержания сбора статистики.

Теперь же осталось выбрать вариант проксирования - проксирование сервером или программой (РНР скриптом, например).

Серверное проксирование счётчика

С некоторых пор владельцы сайтов имеющие собственный сервер, nginx например, для загрузки счётчика "Google Analytics" делают такой фокус:

server {
 
    ...
 
    # Google Analytics Proxy
    rewrite ^/ga.js$ /ga/ last;
    location /ga/ {
        proxy_pass http://www.google-analytics.com/ga.js;
        break;
    }
}

В данном примере проксируется только загрузка самого счётчика, но все запросы которые будет создавать "/ga.js" пойдут напрямую в http://www.google-analytics.com/ и будут блокированы, например плагином uBlock - это можно будет видеть открыв журнал сетевых запросов uBlock.

На примере счётчика от "top.mail.ru" имея уже пропатченый https://top-fwz1.mail.ru/js/code.js мы используем более извратный вариант для того же nginx-а:

Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!

Аналогичная конфигурация для Apache2:

<Location "/cntalias">
    ProxyPass "https://top-fwz1.mail.ru/counter"
    ProxyPassReverse "https://top-fwz1.mail.ru/counter"
    ProxyPassReverseCookieDomain  ".mail.ru"  ".itmag.pro"
</Location>

Данная конфигурация является простым и быстрым вариантом проксирования через собственный сервер запросов и создаваемых счётчиком "кукишей" (ака cookie).

Недостатки серверного проксирования

Как упоминалось, серверная конфигурация Apache2 является простым и быстрым вариантом проксирования через собственный сервер - только если он собственный и к его настройкам (server config, virtual host) есть доступ, .htaccess тут неканает.

Следовательно, решение в виде простых настроек для Apache2 и nginx - это аж никак не решение для владельцев сайтов на простых шаровых хостингах, где нет доступа к веб-серверу, а значит и нет прав использовать такие настройки, ИМХО:

  • https://httpd.apache.org/docs/current/mod/core.html#location
    Context: server config, virtual host

включая ProxyPass:

  • https://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass

Тоже самое с настройками для nginx:

  • http://nginx.org/ru/docs/http/ngx_http_proxy_module.html
    https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

Кроме того, с точки зрения, при условии вменяемости, администратора сети/сервера, ProxyPassReverseCookieDomain делает полный разрыв шаблона безопасности относительно кругооборота кукишей в сети!

Помните был такой "разрыв"?:)

  • Звонок в саппорт Стрима в три часа ночи
    https://www.youtube.com/watch?v=BsjAzOGe0cI

Перечисленные недостатки серверного проксирования могут быть сглажены/устранены программным проксированием, а относительно того, что "Скрипт добавляет много latency.", то этими самыми latency может "похвалиться" и сервант, - всё зависит от практических условий и рабочих нагрузок самого сервера и сети в целом.

Программное проксирование счётчика PHP скриптом

Реализацию проксирования счётчика PHP скриптом можно глянуть на примере аналитики для веб-мастеров от Finteza:

Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!

Потому, как уже есть готовый вариант программного проксирования счётчика PHP скриптом от Finteza, нет никакого смысла приводить здесь его куски кода, а достаточно просто перейти по ссылке на Github: https://github.com/finteza/web-sdk-php/blob/master/finteza-analytics.php

Данный "Finteza SDK" для "PHP web servers" довольно незамысловат, и это правильно, ведь всё гениальное просто, проксирование выполняется посредством CURL, состоит из не более десятка функций, которые при определённых навыках можно заточить под проксирование любого иного счётчика.

В ходе адаптации "finteza-analytics.php" под счётчик другого сервиса аналитики нужно учитывать основные важные моменты:

Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!

Программный вариант более гибкий и универсальный способ обойти разного рода блокировщики скриптов и рекламы нежели серверный ИМХО даёт больший спектр всевозможных действий над отправленным запросом. Хотя, и серверный вариант можно "заточить" до нужной кондиции если "допилить" и перекомпилировать тот же mod_proxy для Apache2, но геммора тут конечно чуть больше.

Тема проксирования подобных вещей довольно ненова. Подобные фокусы с программным проксированием рекламы, кажись, были у "Бегун-а", но по каким-то неизвестным причинам основная масса сервисов аналитики для вебмастеров не использует подобный подход, что почти в половину снижает эффективность таких сервисов и подталкивает владельца сайта к использованию своих собственных скриптов аналитики или же движков типа Matomo (https://matomo.org/), которые, кстати, также не идеальны и требуют определённого "допиливания".

Пассивность же сервисов аналитики в вопросе проксирования своих счётчиков по всей видимости связана с давней славянской традицией ничего неделания "не хотим не будем": "А кого шо не влаштовуе!? Выходьте на вулыци! Берить в рукы лопаты! И ремонтуйте!".

  • Голосуй ЗА ЛУПАНА!
    https://www.youtube.com/watch?v=h4y2e3PQ6q8

Блокировка счётчика прокси-сервером

Реализовав проксирование счётчика не стоит расслабляться. Уже проксируемые запросы могут быть заблокированы дополнительными модулями установленными на сервере такими, как например mod_security2.

[Sun Dec 08 09:59:39 2019] [error] [client 5.137.243.89] ModSecurity: [file "/etc/httpd/owasp/owasp-modsecurity-crs-3/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf"] [line "134"] [id "933120"] [msg "PHP Injection Attack: Configuration Directive Found"] [data "Matched Data: = found within ARGS:js: 13;id=2301166;u=https:/www.example.com/...;r=https:/yandex.ru/clck/jsredir?bu=azhg3g&from=yandex.ru;search/;web;;&text=&etext=8744.kyxdrifizfhoszqwkeqwu0k87qo2-5lm-m9po1davvmbgoimfi7fhjastoe9l8-qb9oppepzzwnelewhht3xpdy9zdxz1ubrrrrxrcuxlda.2c658fa3a79a283e7c8238376282cd3f904216b2&uuid=&state=petffutevd5kphnk9lio9dfa2epbdzx7kdtg1r8zf0arbi8_2i6jpgtryybhxrimezk5yudjtkq0li8l4nz8..."] [severity "CRITICAL"] [ver "OWASP_CRS/3.1.0"] [tag "application-multi"] [tag "language-php"] [tag "platform-multi"] [tag "attack-injection-php"] [tag "OWASP_CRS/WEB_ATTACK/PHP_INJECTION"] [tag "OWASP_TOP_10/A1"] Warning. Matched phrase "=" at ARGS:js. [hostname "example.com"] [uri "/cntalias"] [unique_id "Xeyta38AAAEAAE@LYewAAAAH"]

Поэтому, реализовав проксирование счётчика, сразу же рекоммендуется в конфигурации виртуального хоста отключить mod_security2 (если установлен):

<IfModule mod_security2.c>
    <Location ~ "/(cntalias)">
        SecRuleEngine Off
        SecRequestBodyAccess Off
        SecResponseBodyAccess Off
    </Location>
</IfModule>

Дополнительно проверить журнал ошибок сервера на наличие проблем с проксируемыми запросами.

Рекомендуемый контент

Об авторе
Олег Головский
Юрист, программист, спортсмен, бизнесмен и просто красавец.
Ещё статьи автора

Добавить комментарий

АХТУНГ! Все комменты модерасятся модерастом. Мессаги исключительно рекламного или оскорбительного содержания не публикуются, а поэтому злостным спамерам, пранкерам и прочей сетевой нечисти рекомендуем напрасно не тратить своего времени и удовлетворять свои больные фантазии на специализированных Интернет ресурсах! Разумная же критика, замечания, дополнения и хвалебные оды приветствуются, также допускается легкий флуд или троллинг :)


Защитный код
Обновить

Новое на форуме