Подмена (встраивание) спам-ссылок на страницы сайта плагинами браузеров, cpatext, Content-Security-Policy

В конце января в логах нашей внутренней системы анализа пользовательских кликов на сайте 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, и собственно, что мы увидели — »Мы автоматически подменяем ссылки, а Вы зарабатываете больше!".

image

Ребята предлагают подменять линки, различными способами, в частности через плагины для браузеров. Построили для этого целую систему и, естественно, они далеко не единственные.

Что делать?


Один из самых полезных вариантов борьбы с последствиями — заголовок 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?
KidsReview.ru 18,11
Компания
Поделиться публикацией
Комментарии 32
  • +2
    >Мы внутри команды пришли к соглашению, что расширения, которые лезут в контент страницы и позволяют себе изменять контент «идут лесом», но верно ли это в 100% случаев?
    Нет. Adblock как пример

    >3. И самое главное, почему спокойно себе живут сайты в духе: metabar.ru/, cpatext.ru/?
    Я их не одобряю, но кушать-то всем хочется, поэтому и живы.
    • 0
      >Нет. Adblock как пример
      К счастью, на нашем сайте нет баннерной рекламы :) Если же говорить точнее, то с помощью CSP в аспекте джаваскрипта возможно ограничить только обработку скриптов из «штатных» недоверенных источников (с доменов не из белого списка, инлайновых скриптов страницы). Непосредственный код плагинов браузера считается доверенным контентом и не подлежит ограничениям со стороны CSP. Срабатывания блокировок вылезают только когда расширения манипулируют DOM страницы и, например, инъектируют подгрузку внешнего js. Конкретно Adblock поэтому будет работать нормально.
      • +1
        Т. е. если этот плагин будет качать скрипт внутри себя и инлайтить в страницу, ваше решение не поможет?
        • +1
          Совершенно верно. От расширений браузера абсолютной защиты нет (и слава богу).
        • +1
          Ghostery еще.
      • +5
        Я правильно понимаю, что у пользователя стоит плагин, который он с большой вероятностью приткнул «условно сам» а не «получил от малваре»?
        • 0
          В системах, подобных metabar, по задумке предполагается, что пользователь сознательно поставит предлагаемый экстеншн. С другой стороны, есть подтверждения о троянах, которые вызывают подобные эффекты. В большинстве случаев, правда, их все-равно в том или ином виде требуется установить вручную
          • +1
            Ну я думаю что из соображений технократического гуманизма пользователей надо предупредить что у них стоит «подозрительный плагин», но вообще «глобально» сделать ничего нельзя — если пользователь собственноручно-добровольно сунул в свой браузер плагин, то с этим можно только смириться (и авторам плагина / хозяевам подозрительного сайта, если нет доказательств малварьности, предъявить нечего — мопед не их)
            • 0
              Совершенно верно. Был подобный случай, клиент жаловался на некоторые ссылки по ключевым словам на своем сайте, которые он не ставил.
              В результате в плагинах оказался левый плагинчик, как он попал — клиент не знал. После удаления плагина все починилось.
            • +7
              условно да.

              впрочем, такие плагины как правило находятся у (или после) юзеров, которые сами по себе ходячая малварь. есть такие странные люди, у которых руки даже не оттуда, откуда они сидят, а похоже вообще из пяток — и некоторые из них еще вдобавок нажимают на ВСЕ ссылки и ВСЕ баннеры, что видят. а потом «ой у меня компьютер тормозит». при 3 антивирусах с тухлыми базами, 4 браузерах и двух десятках разных тулбаров в них, хорошо если суммарно. флеш с макафи? пожалуйста! кипу с поиском от «подставить по вкусу»? не вопрос. и т.д, и т.п. наверное, они и «обновления оперы мини» качают на своих телефонах.
              • 0
                Недавно вылавливал такой: в опере подменял ссылки, в хроме вытаскивал ошибку (в логах)… Если в хроме нашел экстеншн, то с оперой пришлось мучиться… Итого нашел его в программах и компонентах и через обычное удаление программ он ушел.
                Удивило, но точно знаю, что сам не ставил
              • +5
                2. Какие best practices при решения подобных вопросов с зараженными пользователями на крупных сайтах?
                Никаких достойных сведений гуглением найти не удалось.

                Ну а каких решений вы ждете. Заразить ведь можно все — браузер, пользовательский режим ОС, ядро ОС, а в вашем распоряжении только открываемый в браузере web-ресурс.
                Как вариант-дополнение к Content-Security-Policy, поставьте обработчик на все сссылки.

                $('a').click(function(e){
                    if ( $(this).attr('href') && $(this).attr('href').indexOf(window.location.protocol + '//' + window.location.host)!==0)
                    {
                        alert('У вас на компьютере вирус или в браузере расширение, подделывающее наши ссылки, пожалуйста, проверьте или обратитесь к нам в техподдержку');
                        e.preventDefault();
                    }
                });
                
                • +1
                  Большинству сайтов все-таки требуется иногда показывать полезные внешние ссылки, а ведение глобального белого списка их хостов выливается в многие тысячи элементов… Соответственно, придется реализовывать сильно усложненную логику вайтлистинга хостов внешних ссылок для каждой отдельной страницы. Хотя можно конечно попробовать фильтр, криптоподписывающий все внешние ссылки из серверного ответа, и применять ваш скрипт только для всех неподписанных.
                  • +3
                    Так ведь и перенаправление с вашего сайта никто не отменял, более того это best practice в плане защиты от всяческих уязвимостей, например такой. Так что:
                    <a href="http://site.com/redirect.php?out=http://extern-site.cocm">Внешний сайт</a>
                    
                    • –1
                      К сожалению, редиректоры на сайте сами зачастую приводят к уязвимости CWE-938/CWE-601 ( www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards ), для избавления от которой опять же требуется вести белый список доверенных хостов или придумывать кастомную логику в стиле криптоподписи ссылок. И к тому же это не очень честно с сеошной точки зрения. Хотя конечно если бы хоть какая-то часть обсужденных нами способов была массово реализована, то веб стал бы чище.
                      • +1
                        По поводу SEO, ссылку можно подменить и по событию onclick. По поводу описанной уязвимости — ну я не знаю конкретно вашей ситуации с внешними ссылками (откуда берутся и куда ставятся), но думаю тоже решается просто.
                        Вы как будто ищете решение для всех случаев на свете, но тогда повторюсь — можно взломать и браузер и тогда хоть что придумывайте — ничего уже не поможет.
                  • +1
                    В вашем коде есть уязвимость: например, с домена example.com он будет пропускать ссылки вида
                    http://example.com.badguys.com/...
                    Нужно добавить еще один слеш в конце аргумента indexOf.
                    • 0
                      Я даже больше скажу — код вообще не очень, но это был всего лишь пример на скорую руку. Лучше вообще у элемента a проверить параметр host.
                      $('a').click(function(e){
                          if ( $(this).attr('href') && this.host !== window.location.host)
                          {
                              alert('У вас на компьютере вирус или в браузере расширение, подделывающее наши ссылки, пожалуйста, проверьте или обратитесь к нам в техподдержку');
                              e.preventDefault();
                          }
                      });
                      

                      .
                  • 0
                    Проблема усугубляется тем, что если раньше вредоносные действия имели локальный эффект (показать рекламный баннер или подменить текст на партнерскую ссылку), то в 2014 году начали действовать трояны, которые сразу проводят комплекс атак: одновременно инъектируются скрипты metabar, показывающие рекламные баннеры; скрипты cpatext, рандомно подменяющие текст на ссылки; появляются фишинговые ложные виджеты-формы входа в FB, VK, OK и т.п.
                    При этом многие схемы лавируют на грани легальной рекламы и вредоносного кода, поэтому далеко не все из них определяются и лечатся пользовательскими антивирусами.
                    По нашей статистике в среднем из 1000 внешних кликов 50 приходятся на подмененные спам-линки. И это только клики, а не факты инъекции js. А ведь эти скрипты в любой момент могут начать снифать платежные данные банковских карт или просто выступить в роли XSS-прокси для доступа к защищенной внутренней инфраструктуре организаций…
                    • 0
                      Тот у кого стоит такой плагин может выключить обработку CSP вроде
                      • 0
                        CSP выключается не плагином, а параметрами командной строки. Для трояна это несколько сложнее, чем просто поставить плагин.
                        • 0
                          Для Firefox есть security.csp.enable в about:config
                          • 0
                            Расширение эту настройку выключить может?
                            • +1
                              тогда как минимум плагин имеет право читать и изменять хедеры полученные от сервера. он может просто удалять CSP
                              • +1
                                Можно фильтровать хидеры, как уже написали.
                                Ещё я встречал такой фокус: если для доступа к данным нет API (как например для HTML5 storage), extensions не брезгуют открывать sqlite-базу в профайле юзера и читать/писать настройки напрямую.

                                Когда мне была интересна тема взаимодействия расширений с LocalStorage, я посмотрел код Self-Destructing Cookies и Foundstone HTML5 Local Storage Explorer — они ходят в базу webappsstore.sqlite. Изменения видны браузеру сразу.
                        • +2
                          Есть идея сделать некое API, которое будет детектить подобное и выводить пользователю предупреждение с просьбой проверить комп на вирусы или подробными инструкциями на удаление.
                          • +7
                            Только массовые публичные расстрелы подобных рекламщиков спасут Интернет!
                            • 0
                              С другой стороны, подмена ссылок может быть нужна самому владельцу сайта. Особенно, если он участвует в лидогенерации (работает с разными партнерскими программами). Например, чтобы избежать потери трафика (денег).
                              • 0
                                Если это нужно владельцу сайта — то это будет происходить с его ведома, не так ли?
                                • 0
                                  Конечно.

                                  Я привлек внимание к этой стороне проблемы потому что в других комментариях в основном рассматривался случай malware.
                                  • 0
                                    Возможно, это было потому что сам пост написан про малварю?..
                                    • 0
                                      Возможно. Я просто клюнул на cpatext, т.к. сам разрабатываю cpa-движок и думал о подобном сервисе (подмена ссылок) для вебмастеров.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое