Спам-заявки заполнили 1С: как аудит защиты сайта поймал бота за форму

Аудит защиты от спама на сайте, интегрированном с 1С, проверяет не капчу саму по себе, а весь путь заявки — от формы до документа в базе. Бот, который прошёл фильтр, резервирует товар и отправляет менеджера звонить несуществующему клиенту. Решение — honeypot и серверная проверка, а не только визуальная капча.

менеджер решил, что клиенты просто не отвечают

В компании, которая продаёт оборудование через сайт с формой заявки, за неделю накопилось двадцать с лишним «холодных» контактов: телефон не отвечает, почта возвращает письмо с ошибкой доставки. Менеджер списал это на невнимательных посетителей и продолжил обзванивать список. Но через месяц счёт пошёл не на единицы, а на десятки заявок в день — форма стала приходить сериями, по три-четыре штуки подряд, с одинаковым текстом в поле «комментарий» и телефонами, начинающимися на один и тот же код.

Заявки при этом исправно долетали до 1С — интеграция была настроена так, что каждая форма создавала документ «Заказ покупателя» без проверки. Отдел продаж резервировал товар под контакт, который никогда не перезвонит.

что аудит нашёл в форме на сайте

Проверка формы обратной связи входит в общий аудит сайта по 9 направлениям — ukved.ru/audit-sayta, но в этом случае клиент заказал именно проверку защиты от спама отдельно, потому что проблема была уже заметна на глаз. Капча на странице выглядела рабочей: галочка, всплывающая проверка, привычный интерфейс. Но сервер, который принимал форму, вообще не спрашивал у капчи результат — токен нигде не сверялся. Поэтому бот просто отправлял POST-запрос напрямую, минуя браузер и саму капчу.

• ✓honeypot-поле отсутствовало — форма не отличала бота от человека ничем, кроме галочки в капче;
• ✓сервер принимал любой запрос и сразу создавал документ в 1С через API, без очереди модерации;
• ✓частота запросов с одного IP никак не ограничивалась, поэтому серии заявок проходили без задержки.

во что обходится спам-заявка, если она долетает до 1С

Одна фейковая заявка — это не пять минут потерянного времени. Менеджер видит новый заказ, звонит, слушает три гудка и автоответчик, отмечает контакт как «не дозвонились», возвращается к нему через день — ещё один звонок. Товар при этом стоит зарезервированным на складе и не попадает в реальную продажу, пока кто-то вручную не снимет резерв в 1С.

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

три уровня защиты — и почему капча в лоб не спасает

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

Третий вариант закрывал именно тот сценарий, который был в этом случае: боты слали заявки сериями с одинаковых адресов, и лимит частоты остановил именно это поведение, а не абстрактную защиту вообще.

как форма стала пропускать только реальных клиентов

Итоговая доработка не потребовала смены капчи или дизайна формы — только серверную часть. Программист добавил honeypot-поле, проверку токена капчи на бэкенде, лимит по IP и промежуточный статус «на модерации» для заявок с подозрительными признаками: пустым именем, телефоном без кода города, ссылкой в комментарии. Такие заявки больше не создают документ в 1С автоматически — их видит менеджер и решает, звонить или удалить.

Работа заняла время программиста по тарифу сопровождения 1С и администрирования — 3800 ₽/час, актуальные условия указаны на странице ukved.ru/tariffs. Для сайта с одной формой заявки это разовая доработка, а не подписка на отдельный сервис.

Заявки с подозрительными признаками, которые попадают в очередь модерации, стоит хранить отдельно от боевой базы 1С и не дольше срока, нужного для проверки, — это требование 152-ФЗ (consultant.ru) к персональным данным, которые оставляют посетители сайта.

что проверить в своей форме прямо сейчас

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

• ✓капча стоит на странице, но проверяет ли её сервер при получении формы, а не только браузер пользователя;
• ✓есть ли скрытое honeypot-поле, невидимое человеку, но заметное скрипту;
• ✓ограничена ли частота отправки с одного IP или сессии;
• ✓создаётся ли документ в 1С сразу или заявка сначала проходит проверку по формальным признакам;
• ✓хранятся ли отклонённые заявки отдельно от боевой базы и не бессрочно.

Такую проверку логично делать вместе с общим аудитом сайта — она входит в раздел безопасности при аудите по 9 направлениям (ukved.ru/audit-sayta) и обычно занимает меньше времени, чем разбор с бухгалтерией, откуда в отчёте взялись лишние отменённые заказы.

❓ Частые вопросы

Как понять, что заявки с сайта — это спам, а не просто нецелевые обращения?

Смотрите на паттерн: заявки приходят сериями с одинаковым текстом в поле «комментарий», телефоны начинаются с одного кода, а номера не отвечают при звонке. Живые нецелевые обращения обычно единичны и разного содержания.

Разве капча на сайте не решает проблему спама?

Только если сервер проверяет её результат при получении формы. Часто капча стоит на странице для вида, а бэкенд принимает любой запрос без сверки токена — бот отправляет данные напрямую, минуя капчу.

Что такое honeypot-поле и зачем оно в форме заявки?

Это скрытое от человека поле формы, которое видят только автоматические скрипты и заполняют его. Если поле заполнено, заявку отклоняют ещё на сервере, до создания документа в 1С.

Сколько стоит доработать форму на сайте, чтобы она не пропускала ботов в 1С?

Обычно это разовая доработка серверной части по тарифу сопровождения 1С и администрирования — 3800 ₽/час, без подписки на отдельный сервис защиты от спама.

Проверка защиты от спама — это отдельная услуга или часть общего аудита сайта?

Можно заказать отдельно, если проблема уже заметна, либо включить в общий аудит сайта по 9 направлениям, где раздел безопасности проверяет форму заявки вместе с остальными узлами сайта.