Security exercise
Практикум: найди 10 опасных ошибок в CRM-доработке
Представим типовую доработку: AJAX обновляет сделки, компонент принимает ID и файлы, cron делает массовые действия, а разработчику нужно быстро “докинуть пару кнопок”. Ниже — ошибки, которые часто превращают такую задачу в риск для данных.
01 AJAX-action без проверки прав
Риск
Любой авторизованный пользователь может вызвать действие и изменить чужие данные.
Безопаснее
Проверять роль, доступ к сущности и конкретное действие до изменения данных. Отдельно логировать отказ без лишних деталей.
02 POST без CSRF/sessid
Риск
Действие можно попытаться вызвать из чужой страницы от имени пользователя.
Безопаснее
Для изменяющих действий использовать POST + CSRF/sessid и отклонять запросы без валидного токена.
03 ID сделки берётся из запроса без проверки доступа
Риск
Пользователь может подставить другой ID и увидеть или изменить чужую сделку.
Безопаснее
Нормализовать ID, проверять существование сущности и доступ текущего пользователя именно к этому ID.
04 Сортировка и поля приходят напрямую из GET
Риск
Можно получить SQL/ORM-ошибки, тяжелые запросы или раскрыть поле, которое не должно участвовать в выдаче.
Безопаснее
Использовать whitelist разрешённых полей, направлений сортировки и фильтров. Всё неизвестное игнорировать.
05 Загрузка файла без whitelist
Риск
В storage может попасть опасный или слишком большой файл, а путь может использоваться небезопасно.
Безопаснее
Ограничить размер, MIME/расширения, имя файла и директорию. Отдачу файлов делать через контролируемый сценарий.
06 В лог попадают токены и персональные данные
Риск
Диагностика превращается в утечку: контакты, токены, payload внешнего API и внутренние ID лежат в логах.
Безопаснее
Маскировать секреты, писать только нужный технический контекст и не хранить полный payload без причины.
07 Массовая операция без dry-run
Риск
Ошибка в фильтре сразу меняет сотни или тысячи записей без предварительной проверки.
Безопаснее
Сначала показывать план: сколько записей затронет операция, какие первые ID, какие поля изменятся. Боевой запуск — отдельным подтверждением.
08 Cron создаёт дубли при повторном запуске
Риск
После сбоя или повторного запуска появляются повторные задачи, комментарии, сделки или события.
Безопаснее
Добавить idempotency key, state и проверку уже обработанных элементов. Повторный запуск должен быть безопасным.
09 Бизнес-логика спрятана в шаблоне компонента
Риск
Правку сложно тестировать, переиспользовать и безопасно менять. UI начинает решать задачи сервиса.
Безопаснее
Оставить компоненту роль интерфейса, а расчёты, проверки и запись данных вынести в сервис/репозиторий текущей архитектуры.
10 Нет журнала действий и пути отката
Риск
Когда что-то пошло не так, непонятно кто запустил действие, что изменилось и как восстановить состояние.
Безопаснее
Писать event log: кто, когда, какой контур, сколько записей, результат и correlation id. Для массовых операций предусмотреть repair/rollback-план.
Takeaway
Главная мысль: опасность обычно не в одной строке кода
Риск появляется на стыке прав, входных данных, повторного запуска, логов и отсутствия диагностики. Поэтому даже небольшую CRM-доработку лучше делать как контролируемый контур: проверка доступа, whitelist, dry-run для массовых действий, idempotency и понятный event log.