Как защититься от накрутки показов?
30.11.2010
Свершилось, впервые за год существования Daos на одном из сайтов начали орудовать вредители — накручивают показы. Какой вариант защиты придумать?
- Засчитывать только уникальные показы — очень плохой вариант, и может сильно ударить по производительности, да и объем данных лишний. Это ж каждый IP придется записывать и сравнивать. Хотя, можно с использованием cookies, но это тоже обходится.
- Определять слишком частые запросы с одного IP — также очень легко обходится, да ещё и таким макаром можно за накрутчика принять обычного пользователя, который быстро открыл несколько вкладок.
Что думаете, как лучше всего поступить? Какие решения вы знаете, или какие приходят на ум, если поразмыслить? По каким признакам определять ложные запросы вредителей? У меня пока ступор…
Кстати, знакомые заметили, что не мешало бы сделать аудит безопасности сайта, поэтому я уже нашёл специалистов, чего и вам советую.
P.S. После выяснилось, что накрутчика и не было, у клиента взбесился один из скриптов, то есть инцидент не был злоумышленным. Однако, через полтора месяца всё же нашёлся кадр, который решил показать свой ум. Что из этого вышло, читайте здесь. Более чем за год на сотне установок Daos лишь один реальный случай. А всё почему? Да глупо накручивать, просто глупо. Но если не делать защиту от дурака, дурак всё же найдётся. Рано или поздно.
Комментарии
Комментирование этой статьи закрыто.
А я не понял, кому выгодно накручивать показы? Владельцу блога?
А прямой выгоды нет никакой, это именно вредительство, какой-то мудак развлекается. Мотивы могут быть такие: а) скомпрометировать владельца сайта, б) скомпрометировать Daos, в) просто так. Я не вижу других вариантов, а ты?
А, ну хотя может быть ещё г: насолить конкретным рекламодателям.
Владелец сайта, конечно, тоже может накручивать, но это маловероятно — он тогда вообще полнейшим дебилом должен быть. Рекламодатели не вернутся, если от рекламы не будет никакого толка. А при накрутке толка и не будет.
У тебя же через JavaScript только работает?
В каком смысле? Если ты клонишь к тому, чтобы сделать подсчёт показов только через интерпретацию JS, то, во-первых, это не просто (всё равно ведь будет точка соприкосновения с серверной частью), во-вторых, вредитель может тупо браузер запустить на автообновление.
Вот и до тебя добралась эта зараза)) Мне так пришлось несколько раз откатывать статистику на день назад, один раз вообще глупейший случай – просто пользователь поставил на страничке «обновлять раз в 30 секунд» и забыл))
Для защиты от совсем глупых накруток (типа while(0) file_get_contents(«site.ru/daos/JSblock.php») ) – простая проверка реферера (если подгружать сам сайт – то не загрузится яваскрипт). Можно еще куки вешать на сайте и проверять, есть ли она. Однако если кто-то возьмется всерьез – ничего из этого не поможет, эмулировать можно даже поведение пользователя на странице :) Про простейшее прикручивание кучи айпишников и юзерагентов я уже молчу.
Остается надеяться, что Just For Lulz никто сильно напрягаться не будет.
Как у тебя счетчик работает? Один вызов ‘http://brokenbrake.biz/DaosWorks/JSblock.php’ – автоматом увеличивает счетчик на единицу?
Spryt, да, придется блокировать прямой вызов файла — это как минимум.
Евгений, да, именно так.
А как ты понял, что счетчик накрутили?
IP:время последнего показа. Если время нового показа менее 3 секунд – считаем фродом. Или, например, более разумная схема – между 1 и 2 3 секунды && 2-3 3 секунды.
Вот и все.
Евгений, понять очень просто — быстро открутилась 1000 показов (я был рекламодателем), а кликов было всего три. Причём показов строчки за сутки было больше, чем показов страниц на всём сайте.
Бутылкус, см. текст заметки. Плохой вариант.
Ну мне видится так:
1. Загружается скрипт JSBlock
2. Через секунду (или несколько секунд) запускается js-код который дергает скрипт counter.php, и он увеличивает счетчик.
Важно! Как понять, что у клиента прошло пять секунд ничего не храня на сервере?
Я предлагаю при формировании ссылки счетчика зашивать в него текущее время, тогда при обращении по этой ссылке мы сможем узнать время когда она была сформирована.
Единственный вопрос как не дать пользователю ее подделать?
Я предлагаю так(далее примерный php код):
Код отправки:
$realTime = time();
$encreptedTime = md5($realTime + SALT);
$url = «/counter.php?realtile=$time&encrepted_time=$encreptedTime»;
Код приемки:
$userRealTime = $_GET[‘realtime’];
$userEncreptedTime = $_GET[‘encreptedtime’];
$isTimeFaked = md5($userRealTime+SALT) != $userEncreptedTime;
Мне в свое время тем и понравилась твоя идея даоса (когда клики и показы не важны, важна только сама очередь), что ее не было никакого смысла читить, все просто и понятно.
А показы/клики всегда можно накрутить. Любые фильтры приведут только к тому, что все в разы усложнится + не будет засчитываться часть реальных показов/кликов.
Если читер просто не отстанет, нелегко придется.
Э…
1. «browser fingerprinting»
2. panopticlick.eff.org
Привязка к хосту и печенькам.
Чиорт… без привязки к печенькам с привязкой к хосту и отпечатку веб просмотрщика.
Евгений, на первый взгляд идея хорошая, ага, но как спрятать counter.php? :-D
DimaX, есть ещё модель оплаты за время размещения (сутки, месяц и т. п.). Тогда хоть занакручивайся — самое худшее, что может произойти, искажение реального CTR. В Daos 2.0 запланирован вариант с выкупом времени.
1. От тупого обновления браузера защитит сессия $_SESSIONS.
2. Хранить ip-адреса за последние несколько секунд, как уже предложили выше. Но на файлах это будет ой как непросто сделать, а от mysql ты отказываешься.
А зачем его прятать?
Евгений, прости не вник сразу в твой код. Идея очень хорошая. Пожалуй, лучше трудно придумать. Спасибо! Супер. Пока не вижу серьезных недостатков такого решения.
>Это ж каждый IP придется записывать и сравнивать.
мб hash-table?
Да никак надежно не защититься. Технологии защиты от скликивания всякие яндексы и гуглы берегут как зеницу ока.
При желании, можно вообще написать скрипт, который найдет все установленные даосы и скликает всю рекламу на них. И так каждый день.
ПистоГанза, речь не о скликивании, вообще-то, а о накрутке показов. И эффективный надёжный способ пять минут назад предложил Evgeny Sergeev.
Тормоз, ну не такой он надежный… :-)
Идеала нет, увы. При большом желании вполне можно сделать Web-робота, неотличимого от человека для всяких таких грязных делишек.
Тормоз, а я тебе рассказывал как у нас на pr-cy сделано, особо не накрутишь и рекламодатели получают показов даже больше чем платят. Правда некоторые накручивают CTR сами что бы в рейтинге быть повыше, но это отдельная история.
Джек, я своё мнение уже сказал в переписке. Если ты учитываешь только уникальные показы, то твой CTR является чем угодно, но не CTR на самом деле :) Ну и плюс накладно это, при больших нагрузках особенно.
Не понимаю в чем надежность данного метода. Если мой бот будет так же постоянно запрашивать страницу, а потом через 5 секунд кликать по этой секретной ссылке. В чем защита то?
Защита несерьезная. Послать 2 запроса:
1. грузим страничку
2. запрос к counter.php с нужными параметрами. SALT известно, time тоже не проблема получить.
Тормоз, ещё никто не жаловался. Нагрузка фигня, сейчас по 50-60к держит и хорошо. Правда это не высокая нагрузка. На высокую нагрузку все равно ни один готовый продукт не рассчитан. Ну вот представь что бы случилось с daos при миллионе просмотров?
По теме ну можно в memcached хранить последние IP за определенное время (ну пару минут скажем) и считать их частоту запросов, после чего если частота слишком высокая просто не учитывать его запросы при проверки. Только что то я сомневаюсь что у многих memcached есть…
Это ж просто намёк, набросок. А если в хэше и количество секунд зашифровано?
Что бы ни было зашифровано – это яваскрипт и все в открытом виде. Эмулировать на пхп большого труда не составит.
Да, но это спасёт от простейших накрутчиков. Учитывая, что особой выгоды вредителю нет, думаю, и такая защита должна спасти от большинства хулиганов.
Сделай капчу на просмотр рекламы :)
che, Будут через антикапчу распознавать.
Тормоз, Естественно все зависит от степени заинтересованности потенциального накрутчика.
Насчет эмуляции javascript на php – чтобы эмулировать, нужно сначала понять что именно эмулировать.
javascript может брать с сервера произвольную строку, как-то ее изменять и отправлять назад, совпало – засчитываем легитимный просмотр.
Если скрипт покрыт обфускацией, то чтобы ее снять надо часа 2-3 часа времени минимум и то, если хорошо тонкости javascript знаешь.
Я сам такой обфускатор писал, работает отлично.
А ведь обфускацию скрипта можно делать на сервере автоматически, скажем 2-3 раза в день. Тогда накрутка становится просто не рентабельной.
kaufman, ты забываешь что даос распространяется в исходниках (это ведь так?). Злоумышленнику ничего не стоит иметь легитимную копию с «неприкрытым» алгоритмом генерации новых обфускаций. Тогда он сможет написать свой скрипт накрутки просмотров пробивающий эти обфускации.
Хотя, конечно, не имеет смысла строить идеальную защиту.
48 Евро не так уж мало для простого хулиганства :) И ещё обфускацию можно делать на основе каких-то уникальных настроек. Однако, это всё же избыточное какое-то решение. Слишком большой налог на хитрость.
ПистоГанза, про исходники я забыл, это да :)
Но фишка в том, что даже имея исходники алгоритма обфускации, это не сильно поможет снять уже существующую. Примерно как с шифрованием или хэш-функцией, да мы знаем, как работает, например, blowfish или SHA-256, но расшифровать закриптованый текст это не сильно поможет.
Так что все упирается в необходимой такой защиты, как и сказал Тормоз.
Ну счётчик можно ещё дёргать с рандомной задержкой, желательно асинхронно. Ну и если не аяксовый запрос – тоже в пень.
Иванов Иван Иванович, salt храниться на сервере, это и гарантирует что нельзя накрутить показы тупо дергая скрипт.
Evgeny Sergeev, salt и на клиенте хранится, кхм, для генерации хеша то. Алсо, у javascript нет нативных методов подсчёта md5-хеша.
Все очень просто,
стартовать сессию,
в нее писать переменную с timestamp,
давать засчитывать показ только раз в 30 сек, без сессии не засчитывать вообще.
AES, а я беру, и не принимаю куки.
js md5 pajhome.org.uk/crypt…
Но он на стороне клиента в схеме Евгения и не нужен. Даже если ты против налогов на хитрость, для рекламного движка неплохо бы использовать Crypt_HMAC, например (двухшаговый хэш).
Ха! Против я или нет — это вообще ничего не меняет. Хитроналоги существовали всегда и будут жить столько же, сколько будет жить человечество.
Rulexec, не понял? Моя идея в том, чтобы отдавая данные клиенту быть уверенным в том, что он вернет эти данные в немодифицированном виде. Кодировать информацию на стороне клиента я не предлогал.
Evgeny Sergeev, извини разобрался. Вечером уже голова совсем того. Замечательный способ, особенно если ещё и каждому даосу свой SALT генерировать.
AES, тоже извини.
Тормоз, сделай пожалуйста защиту: чтобы не засчитывались показы от серверного IP на котором расположен сам блог. Просто есть некоторые кэшировщики серверные (на уровне apache), которые обращаются к скрипту каждую минуту. Если нужен код, то я могу тебе его написать. ;) Такая защита лишним не будет. А с остальным можно подумать.
Сделаю обязательно, но вот когда — пока не знаю. Возможно, придется подождать Daos 2.0, уже почти физически неприятно лезть в старый код и править там что-то.
Вот это круто.
У каждого варианта есть не только преимущества, но и недостатки. С выкупом времени сложнее прогнозировать фактическую отдачу от рекламы. Вдруг одновременно ещё 10 рекламодателей появится? С выкупом показов в таком случае просто кампания растянется на более длительное время.