Большинство современных сервисов сбора статистики о посещаемости сайтов делают код счётчиков на 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
Т.е. вместе с кукишами по-праву предназначенными для ".mail.ru" туда же кучей пойдут/уйдут/проксируются и все кукиши ".itmag.pro"!
Какие кукиши проксировать, а какие нет, настройки сервера выбирать не дают, например несуществующей директивой "ProxyPassReverseCookieName" (зато "ProxyPassReverseCookiePath" есть :) Кроме того, сторона ".mail.ru" сможет не только читать, но устанавливать от имени домена ".itmag.pro" куки с любыми именами!
Это два.
Перечисленные недостатки серверного проксирования могут быть сглажены/устранены программным проксированием, а относительно того, что "Скрипт добавляет много 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>
Дополнительно проверить журнал ошибок сервера на наличие проблем с проксируемыми запросами.
