В конце января в логах нашей внутренней системы анализа пользовательских кликов на сайте kidsreview.ru появились сотни переходов по странным линкам вида:
compareiseries.in/goto.php?url=aHR0cDovL24uYWN0aW9ucGF5LnJ1L2NsaWNrLzUyZDhmODY2ZmQzZjViMjYxYTAwNDFjNS82OTIzMy81MDI1OS9zdWJhY2NvdW50
Недолгое расследование показало, что сайт compareiseries.in является прослойкой, скрипт выдает js-редирект на ссылку, которая была передана в адресе. В данном случае base64 скрывала реальный адрес:
n.actionpay.ru/click/52d8f866fd3f5b261a0041c5/69233/50259/subaccount
Как не трудно догадаться, сайт оказался биржей трафика с оплатой за клики (с параметрами чьей-то конкретной учетки в урле). То есть кто-то накручивал клики, зарабатывал денег — и все на нашем сайте и, самое обидное, без нашего разрешения.
Проблема: при просмотре сайта в браузерах большого количества посетителей имеют место спам-линки на множество разнородных рекламных ресурсов.
Вопрос: на каком именно уровне они появляются?
Варианты, приходящие в голову (в субъективно оцененном порядке убывания вероятности):
1. В браузер пользователя, в результате вируса на компьютере / завирусованного плагина к браузеру / других вирусов во всем их многообразии, инъектируются вредоносные джаваскрипты в посещаемые сайты;
2. Наши сервера в результате взлома и последующего затроянивания кода сайта или веб-сервера или драйвера сетевой карты сами выдают спам-скрипты / ссылки посетителям;
3. Какой-то из js, которые мы подгружаем с внешних ресурсов, в результате взлома начал попутно заниматься распространением рекламного спам-контента
(rambler top100, vk/fb, twitter, google, yandex metrika,… их около десятка);
Тщательный поиск каких-либо следов на наших серверах ничего не дал, пункт 3 же отмели как самый маловероятный. Параллельно с этим мы внесли правки в нашу систему анализа переходов — чтобы контент страниц, на которых осуществлялись клики на «левые» урлы, логировался.
Первые же часы работы нашей импровизированной «ловушки» поймали несколько десятков страниц, а вместе с ними и иньектированные js вида:
api.cpatext.ru/js/cpatext.js?r5
ayrqejixqe.ru/js/start_ad.js?u=7_05032014
yhcwxeqhzg.ru/?d=kidsreview.ru&t=KidsReview.ru%20%7C
www.superfish.com/ws/sf_main.jsp?dlsource=pcom&userId=4826451239324129823&CTID=p1272
Или, например, вот так:
«data:text/javascript;base64,KGZ1bmN0aW9uKHdpbmRvdykgew0KICAgIHZhciBkb21haW5fbGlzdCA9ICcsMS5hemFydG55ZS1pZ3J5LXBva2VyLnJ1LDEwMGNhc2luby5uZXQsMTAxb25saW5l…”
и.т.д.
Got it! — решили мы и открыли cpatext.ru, и собственно, что мы увидели — »Мы автоматически подменяем ссылки, а Вы зарабатываете больше!".
Ребята предлагают подменять линки, различными способами, в частности через плагины для браузеров. Построили для этого целую систему и, естественно, они далеко не единственные.
Один из самых полезных вариантов борьбы с последствиями — заголовок Content-Security-Policy (http://en.wikipedia.org/wiki/Content_Security_Policy), который позволяет сайту декларировать ограничения на работу страниц сайта с внешним контентом. В частности, это позволяет передать современным браузерам инструкции по тому, с каких внешних доменов сайт разрешает подгружать внешние JS.
Этот способ особенно хорош, если все js размещаются в рамках одного домена (например, CDN), но в общем случае, когда на сайте может быть куча сторонних js (например виджетов, как у нас) возникает несколько проблем:
1. Необходимо составить полный whitelist, проанализировав все подгружаемые внешние js
2. Необходимо по ходу разработки поддерживать whitelist в актуальном состоянии
3. Изменения в тонкостях хостинга легитимных внешних скриптов: например, смена домена CDN фейсбука или появление нового стороннего легитимного домена — приводит к ошибке.
4. Помимо прочего блокируется уйма скриптов от рекламных тулбаров и потенциально легитимных браузерных расширений.
Мы внутри команды пришли к соглашению, что расширения, которые лезут в контент страницы и позволяют себе изменять контент «идут лесом», но верно ли это в 100% случаев?
После включения блокировки с помощью Content-Security-Policy «левых» кликов становится на порядки меньше (остаются только клики с древних версий браузеров, не поддерживающих CSP), но несколько вопросов осталось:
1. Есть ли какие-то подвижки со стороны разработчиков браузеров в плане ограничения
расширений на инъекции js в страницы сайтов?
2. Какие best practices при решения подобных вопросов с зараженными пользователями на крупных сайтах?
Никаких достойных сведений гуглением найти не удалось.
3. И самое главное, почему спокойно себе живут сайты в духе: metabar.ru, cpatext.ru?
compareiseries.in/goto.php?url=aHR0cDovL24uYWN0aW9ucGF5LnJ1L2NsaWNrLzUyZDhmODY2ZmQzZjViMjYxYTAwNDFjNS82OTIzMy81MDI1OS9zdWJhY2NvdW50
Недолгое расследование показало, что сайт compareiseries.in является прослойкой, скрипт выдает js-редирект на ссылку, которая была передана в адресе. В данном случае base64 скрывала реальный адрес:
n.actionpay.ru/click/52d8f866fd3f5b261a0041c5/69233/50259/subaccount
Как не трудно догадаться, сайт оказался биржей трафика с оплатой за клики (с параметрами чьей-то конкретной учетки в урле). То есть кто-то накручивал клики, зарабатывал денег — и все на нашем сайте и, самое обидное, без нашего разрешения.
Проблема
Проблема: при просмотре сайта в браузерах большого количества посетителей имеют место спам-линки на множество разнородных рекламных ресурсов.
Вопрос: на каком именно уровне они появляются?
Варианты, приходящие в голову (в субъективно оцененном порядке убывания вероятности):
1. В браузер пользователя, в результате вируса на компьютере / завирусованного плагина к браузеру / других вирусов во всем их многообразии, инъектируются вредоносные джаваскрипты в посещаемые сайты;
2. Наши сервера в результате взлома и последующего затроянивания кода сайта или веб-сервера или драйвера сетевой карты сами выдают спам-скрипты / ссылки посетителям;
3. Какой-то из js, которые мы подгружаем с внешних ресурсов, в результате взлома начал попутно заниматься распространением рекламного спам-контента
(rambler top100, vk/fb, twitter, google, yandex metrika,… их около десятка);
Тщательный поиск каких-либо следов на наших серверах ничего не дал, пункт 3 же отмели как самый маловероятный. Параллельно с этим мы внесли правки в нашу систему анализа переходов — чтобы контент страниц, на которых осуществлялись клики на «левые» урлы, логировался.
Первые же часы работы нашей импровизированной «ловушки» поймали несколько десятков страниц, а вместе с ними и иньектированные js вида:
api.cpatext.ru/js/cpatext.js?r5
ayrqejixqe.ru/js/start_ad.js?u=7_05032014
yhcwxeqhzg.ru/?d=kidsreview.ru&t=KidsReview.ru%20%7C
www.superfish.com/ws/sf_main.jsp?dlsource=pcom&userId=4826451239324129823&CTID=p1272
Или, например, вот так:
«data:text/javascript;base64,KGZ1bmN0aW9uKHdpbmRvdykgew0KICAgIHZhciBkb21haW5fbGlzdCA9ICcsMS5hemFydG55ZS1pZ3J5LXBva2VyLnJ1LDEwMGNhc2luby5uZXQsMTAxb25saW5l…”
и.т.д.
Got it! — решили мы и открыли cpatext.ru, и собственно, что мы увидели — »Мы автоматически подменяем ссылки, а Вы зарабатываете больше!".
Ребята предлагают подменять линки, различными способами, в частности через плагины для браузеров. Построили для этого целую систему и, естественно, они далеко не единственные.
Что делать?
Один из самых полезных вариантов борьбы с последствиями — заголовок Content-Security-Policy (http://en.wikipedia.org/wiki/Content_Security_Policy), который позволяет сайту декларировать ограничения на работу страниц сайта с внешним контентом. В частности, это позволяет передать современным браузерам инструкции по тому, с каких внешних доменов сайт разрешает подгружать внешние JS.
Этот способ особенно хорош, если все js размещаются в рамках одного домена (например, CDN), но в общем случае, когда на сайте может быть куча сторонних js (например виджетов, как у нас) возникает несколько проблем:
1. Необходимо составить полный whitelist, проанализировав все подгружаемые внешние js
2. Необходимо по ходу разработки поддерживать whitelist в актуальном состоянии
3. Изменения в тонкостях хостинга легитимных внешних скриптов: например, смена домена CDN фейсбука или появление нового стороннего легитимного домена — приводит к ошибке.
4. Помимо прочего блокируется уйма скриптов от рекламных тулбаров и потенциально легитимных браузерных расширений.
Мы внутри команды пришли к соглашению, что расширения, которые лезут в контент страницы и позволяют себе изменять контент «идут лесом», но верно ли это в 100% случаев?
После включения блокировки с помощью Content-Security-Policy «левых» кликов становится на порядки меньше (остаются только клики с древних версий браузеров, не поддерживающих CSP), но несколько вопросов осталось:
1. Есть ли какие-то подвижки со стороны разработчиков браузеров в плане ограничения
расширений на инъекции js в страницы сайтов?
2. Какие best practices при решения подобных вопросов с зараженными пользователями на крупных сайтах?
Никаких достойных сведений гуглением найти не удалось.
3. И самое главное, почему спокойно себе живут сайты в духе: metabar.ru, cpatext.ru?
