znaeff Apr 27 2016 at 16:18

Невизуальные методы защиты сайта от спама. Часть 1. Статистика

3 min

8.6K

CleanTalk Anti-Spam corporate blogInformation Security*Website development*

Comments 17

maxru Apr 27 2016 at 16:56

Неплохой набор идей для раздумья, спасибо.

savostin Apr 28 2016 at 21:31

А Вы с какой стороны баррикад? ;)

teecat Apr 28 2016 at 10:24

Статистика конечно вещь интересная, но помоему посыл «спамеры будут строить свои сообщения так, что по нескольким критериям они будут явно отличаться от обычных сообщений» неверен. Качественные фишинговые сообщения не должны вызывать никаких подозрений.

Вот что чисто визуально видно по массиву спама — очень часто вместо текста тела письма — одна картинка (для обхода фильтров Байеса) и постоянные повторы. Письмо в разных вариациях имени отправителя приходит не менее 3х раз

shagimuratov Apr 28 2016 at 17:31

Статья о спаме в комментариях, контактных формах и регистрациях. Применительно к почтовому спаму статистикой не располагаем.

teecat Apr 28 2016 at 17:40

Мда. Профессиональная деформация. Увидел слова про адреса электронной почты…

andkln Apr 29 2016 at 18:31

Спасибо, интересно.

Уточните, пожалуйста, по статистике «Отношение длины сообщения ко времени заполнения, символы/с». Для нормальных пользователей дан показатель 23.81. Это значит, что обычный пользователь печатает со скоростью в почти 24 символа в секунду? За счёт чего получается такое значение?

Gvozdb8 Apr 29 2016 at 22:06

Полагаю, это средняя цифра, которая так велика, за счёт использования ctrl+c ctrl+v пользователями.

znaeff May 2 2016 at 12:24

Да, цифра действительно средняя, и скорее всего связана именно с копипастом.Тем не менее, спам-боты показывают значительно лучшие результаты по скорости набора ;)

andkln May 3 2016 at 00:30

Неожиданно. А что именно пользователи могут копипастить в комментарий? Мне на ум приходят только ссылки.

shagimuratov May 4 2016 at 05:02

Пользователи цитируют, приводят примеры кода, плюс сервисом пользуются Wiki движки, а там много спама на правках существующего текста, что и дает существенное увеличение отношения объема текста к времени набора.

andkln May 4 2016 at 13:27

Спасибо :)

yomayo May 11 2016 at 17:06

Я, как правило, набираю текст сначала в Word, чтобы выявить глупые описки и ошибки. Это вопрос элементарного уважения к тем, кто будет читать твой текст. Естественно, вставляемый в форму ввода текст будет формально считаться слишком быстро набранным.

andkln May 11 2016 at 17:14

Если честно, я даже не предполагал, что кто-то так может делать. Ваш подход заслуживает уважения :)

shagimuratov May 11 2016 at 20:46

С таким подходом вы точно выпадаете из «мейнстрима», но как пользователь/читатель комментариев, хочу сказать спасибо :)

XAHOK May 11 2016 at 17:38

Время заполнения формы, c
Отношение длины сообщения ко времени заполнения, символы/с

Еще полезно посмотреть на самых тормозных заполнителей. Там тоже высока вероятность спама.

2. Ник посетителя

3. Имя в электронной почте

А это хороший показатель лени разработчика. Особенно если счет идет не на тысячи email/день. Порядка 400-500 мыл в день с качественными именами и никами под них очень легко создавать в автоматическом режиме даже у яндекса (сомневаюсь, что их детектор ботов сильно изменился).

4. HTTP-заголовки

Опять таки лень. Не самый тупой воспользуется постоянно обновляемым списком из интернета.

5. JavaScript-тест

Вы привели проверку на выполнение JS скриптов вообще, но это позволит защитить только от любителей коврового спамометания.

Могу порекомендовать обратить внимание так же на следующие характеристики, для вылавливания спамеров на формах:
1. Подключение дополнительных скриптов/Модификация Head секции. Самая лучшая проверка — это проверка на подключение jQuery, если сайт может работать без нее (самый убийственный вариант);
2. Определение скриптами координат элементов (лучше переопределить эти методы, т.к. это отсеет хитрожопых, но тупых);
3. Несколько UserAgent-ов с одного IP;
4. IP адреса мобильных операторов(При наличии других факторов это верная примета!!!!!);
5. Ссылки на один домен с разных IP;
6. Периодичность похожих сообщений (обрабатывать только мат статистикой, т.к. разброс +-[0-0.25] от интервала это не редкость);
7. Несовпадение падежей/«битые» слова (обычная проблема криво отработанного синонимайзера).

А так же более раритетные случаи:
1. «Телепортация» курсора мыши внутри страницы;
2. Движение курсора мышки по идеально ровным прямолинейным/простым криволинейным траекториям (полиномы N порядка, гладкие кривые);
3. «Мгновенный» скрол;
4. «Отсекание» метрик/логеров активности.

А вообще идеальным вариантом будет случайная генерация блоков страницы с большим количеством фэйковых полей. Пожалуй это единственный условно надежный вариант, но требует больших, затрат как на разработку, так и на поддержание в актуальном состоянии. А условно потому, что «умный в гору не пойдет», он и скриншоты может анализировать.

К сожалению хорошего бота написать не сложно, но к счастью мало разработчиков ботов приличного уровня (что и не удивительно, но ради фана/рабочих нужд могут развлекаться).

PS. Бывший ботовод, правда не спамер, а парсер.

shagimuratov May 14 2016 at 11:17

Над применением сложных JavaScript анти-спам тестов (трекинг курсора мыши, наличие определенных плагинов в броузере и т.д.) думали не раз, но считаем что это без перспективное направление, т.к. код такого анти-спам теста публичен, т.е. не надежен с точки зрения «взлома» разработчиками ботов.

Все остальные пункты так или иначе применяем/применяли, но одного 100% надежного варианта («серебрянной пули») с точки зрения защиты и уровня ложных сработок нет.

Относительно сложной структуры фронтенда, то да, это хороший вариант, особенно для самостоятельной защиты сайта от ботов.

Спасибо за интересный опыт и развернутый комментарий.

XAHOK May 14 2016 at 16:16

> Над применением сложных JavaScript анти-спам тестов (трекинг курсора мыши, наличие определенных плагинов в броузере и т.д.) думали не раз, но считаем что это без перспективное направление, т.к. код такого анти-спам теста публичен, т.е. не надежен с точки зрения «взлома» разработчиками ботов.

Оно хитрых, но глупых и исключительно для ручной премодерации. Ложных срабатываний будет много.

> Все остальные пункты так или иначе применяем/применяли, но одного 100% надежного варианта («серебрянной пули») с точки зрения защиты и уровня ложных сработок нет.

Сам пришел к тому же выводу: нет защиты, которую нельзя сломать и бота, которого нельзя поймать. Это вечная гонка вооружений, но хотя бы порог вхождения повышается с каждым днем, что уже огромный плюс по отсеканию шушеры.

> Относительно сложной структуры фронтенда, то да, это хороший вариант, особенно для самостоятельной защиты сайта от ботов.

Сложной мало. Она должна динамически изменяться. А в данном случае фронтенд превращается в лапшу, что как серпом по яйцам, а изменение страницы будет подобно хождению по кругам ада.