Как ломают CRM: SQL-инъекции, IDOR и почему в 2026 это касается каждого проката

В 2026 году собрать CRM стало легко: ИИ напишет интерфейс за вечер, ещё за вечер — базу и API. Рынок наполнился сервисами, которые выглядят как продукт, а внутри собраны без единой мысли о безопасности. Мы видели системы учёта, где список финансовых транзакций открывался вообще без входа — по прямой ссылке. И системы, где любой зарегистрировавшийся пользователь получал права администратора: регистрируешься — и видишь чужие брони, чужих клиентов, чужую выручку.

Это не экзотика, а прямое следствие того, как такие сервисы делаются: скопировать чужой интерфейс ИИ может, скопировать архитектуру безопасности — нет, потому что её не видно снаружи.

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

SQL-инъекция: вся база одним запросом

Классика, которой двадцать пять лет и которая до сих пор входит в OWASP Top 10 — общепризнанный список самых опасных уязвимостей веб-приложений.

Суть простая. Приложение подставляет то, что ввёл пользователь, прямо в запрос к базе данных. Если поле поиска склеивает текст запроса со введённой строкой, то вместо имени клиента злоумышленник вводит кусок SQL-кода — и база выполняет его как команду. Дальше дело техники: одним запросом вытягивается вся таблица клиентов с паспортами, вся финансовая история, все пароли. Именно так происходили многие громкие утечки: не гений в капюшоне, а поле ввода, которому доверяли.

Защита известна так же давно: запросы к базе должны быть параметризованными — ввод пользователя передаётся отдельно от текста запроса и физически не может стать командой. В RentalX весь доступ к данным идёт через ORM: сырой SQL со склейкой строк в кодовой базе отсутствует как класс. Это не «мы проверяем ввод и надеемся» — это архитектура, в которой инъекции не существует.

IDOR: поменял цифру в адресе — увидел чужое

Менее известная, но в наспех собранных CRM — самая частая дыра. Название расшифровывается как Insecure Direct Object Reference, а суть умещается в одну строку: открываешь свою бронь по адресу `/bookings/17`, меняешь цифру на `/bookings/18` — и видишь бронь чужого проката. С паспортом чужого клиента.

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

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

Открытые файловые хранилища

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

У нас этой двери нет вообще. Файлы RentalX не лежат в сторонних облачных бакетах — они хранятся на нашей инфраструктуре, и каждый чувствительный файл отдаётся только по подписанной ссылке после проверки: авторизован ли пользователь и имеет ли право видеть именно этот документ. Скопированная и пересланная ссылка на чужой скан не откроется.

Что ещё входит в «скучную» часть

Безопасность — это в основном рутина, и она у нас автоматизирована:

• Мониторинг аномалий. Каждый час система анализирует трафик: перебор адресов, всплески ошибок, входы с датацентровых IP, подозрительные объёмы запросов. Сработки прилетают команде в Telegram — о странной активности мы узнаём раньше, чем она становится проблемой.

• Обновление зависимостей. Компоненты, из которых собран сервис, еженедельно проверяются на известные уязвимости — большинство реальных взломов происходит через устаревшие библиотеки.

• Роли и мгновенная блокировка. Сотрудник видит только своё: механик — транспорт, менеджер — брони, финансы — владелец. Заблокированный аккаунт теряет доступ сразу, а не когда истечёт сессия.

• Минимум лишних данных. Журнал запросов ведётся без содержимого (иначе он сам стал бы копией персональных данных) и автоматически очищается через 90 дней.

• Плюс база: HTTPS с HSTS, ограничение частоты запросов, проверка сложности паролей.

По OWASP Top 10 мы проходимся не для галочки: инъекции, нарушение контроля доступа, небезопасная конфигурация, уязвимые компоненты — каждый пункт списка закрыт конкретным архитектурным решением из перечисленных выше, а не строчкой в маркетинге.

Бэкапы: что будет, если сервер умрёт

Отдельный страх 2026 года — не хакеры, а «что если всё сгорит». Отвечаем буднично: база данных и документы автоматически копируются каждую ночь, копии хранятся отдельно от рабочего сервера, а дампы проверяются на восстановимость — бэкап, из которого нельзя восстановиться, это не бэкап, а самообман. Сервер — железо, оно смертно. Данные проката — нет.

Как отличить нормальный сервис от вайб-кода

ИИ — прекрасный инструмент, мы сами им пользуемся. Но безопасность не появляется из промпта «сделай как у конкурента». Если выбираете, куда загружать паспорта своих клиентов, задайте сервису три вопроса:

1. Что будет, если поменять цифру в адресе чужой брони?

2. Открывается ли скан документа по прямой ссылке без входа?

3. Когда был последний бэкап и куда он складывается?

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

Чего мы не обещаем

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

Главное

Данные клиентов — чужие данные, которые вам доверили. В эпоху, когда CRM генерируются за вечер, вопрос «какие у сервиса функции» стал вторым. Первый — «что увидит посторонний, если поменяет цифру в адресе». Мы разобрали, как хранить данные аккуратно, и в статьях про чёрный список и Excel против CRM.

Посмотреть, как устроены роли и доступ в RentalX, можно на странице тарифов — первый месяц бесплатно.