Підміна (вбудовування) спам-посилань на сторінки сайту плагінами браузерів, 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 / ?
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.