Многие владельцы бизнеса вспоминают о безопасности только после инцидента: в админку кто-то вошёл и изменил цены, номера телефонов пользователей массово выгрузили, на главной странице сайта появились странные ссылки. Когда начинаешь разбираться, разработчик говорит: «Все функции протестированы». Проблема именно в этом — успешное прохождение функциональных тестов не означает, что безопасность обеспечена.
Уязвимости безопасности при разработке сайтов в большинстве случаев — это не изощрённые атаки, а несколько базовых этапов, выполненных неправильно. Ниже по пунктам разобраны самые частые ошибки в реальных проектах.
1. Нарушение прав доступа: авторизация не означает доступ ко всему
Это самая распространённая проблема на корпоративных сайтах и в административных панелях. Пользователь A после входа меняет в адресной строке ID заказа с 1001 на 1002 и видит заказ пользователя B. Разработчики часто скрывают кнопку только на фронтенде, а серверный API не проверяет, «принадлежат ли эти данные вам».
Решение простое: каждый API-эндпоинт должен проверять, имеет ли текущий авторизованный пользователь право работать с этими данными, а не только факт авторизации. Ролевые права тоже нужно чётко разделять: меню и доступные API для обычного сотрудника и для финансиста должны различаться.
Подводный камень: не пишите проверку прав на фронтенде. Код фронтенда пользователь может изменить, бэкенд — последняя линия защиты. Перед запуском попросите разработчика составить список всех эндпоинтов, работающих с ID, и по каждому подтвердить проверку принадлежности данных.
2. Инъекционные уязвимости: конкатенация строк рано или поздно приведёт к проблемам
SQL-инъекции — старая проблема, но она случается до сих пор. Типичный сценарий — поле поиска или фильтр, где разработчик напрямую вставляет пользовательский ввод в SQL-запрос; атакующий вводит специальные символы и обходит условия, выгружая целую таблицу.
Правильный подход — везде использовать параметризованные запросы или привязку параметров в ORM, не собирать строки вручную. То же касается выполнения команд и инъекций в шаблоны: везде, где пользовательский ввод исполняется как код, нужна проверка по белому списку.
Подводный камень: если в коде есть конкатенация строк для SQL — это практически гарантированный возврат на доработку. Кроме того, не используйте root для учётной записи базы данных: выдавайте только необходимые права под задачи бизнеса — в случае инцидента потери можно сократить вдвое.
3. Загрузка и скачивание файлов: самый недооценённый вход
Корпоративным сайтам нужно загружать изображения товаров и вложения договоров, в разработке мини-программ — аватары и фотографии документов. Если интерфейс загрузки проверяет только расширение, атакующий переименует скрипт в .jpg, загрузит его и найдёт способ выполнить.
Решение: проверять тип файла по реальному содержимому, а не по расширению; запретить выполнение скриптов в каталоге загрузок; переименовывать файлы при сохранении. Интерфейс скачивания также должен проверять права — не позволяйте менять путь и скачивать конфигурационные файлы с сервера.
Подводный камень: каталог загрузок и каталог программ сайта должны быть разделены. Многие инциденты происходят именно потому, что изображения и код лежат в одном исполняемом каталоге.
4. Аутентификация API и утечка конфиденциальной информации
В разработке App и мини-программ API — основная поверхность атаки. Типичны три проблемы: у API нет ограничения частоты запросов, и капчу можно подбирать бесконечно; в ответе возвращаются лишние поля, например, в списке пользователей отдаются номера удостоверений; сообщения об ошибках слишком подробные — клиенту напрямую отдаётся ошибка базы данных.
Решение: для API входа, SMS и платежей обязательно ограничение частоты и защита от повторной отправки; поля ответа обрезать по необходимости; унифицировать сообщения об ошибках. В логах также не следует хранить пароли и полные номера телефонов в открытом виде.
Подводный камень: не синхронизируйте данные тестовой среды напрямую в продакшен. Многие утечки происходят потому, что в тестовой базе лежат реальные данные пользователей, а защита тестовой среды практически нулевая.
5. Запуск — не финиш: тестирование безопасности должно быть в процессе
Многие команды воспринимают безопасность как разовую проверку и после запуска ей не занимаются. На самом деле новые функции, обновления зависимостей, смена конфигурации сервера — всё это может заново внести проблемы.
Рекомендуется включить тестирование безопасности в процесс релиза: при каждом крупном обновлении проводить проверку API и прав, регулярно сканировать уязвимости зависимостей, для важных систем раз в год делать пентест. В таких проектах, как редизайн корпоративного сайта, после изменения страниц заодно пройдитесь по формам, поиску и входу в админку — затраты невелики, а большинство низкоуровневых проблем это отсекает.
Подводный камень: не смотрите только на количество находок в отчёте сканера. Высокие риски, найденные инструментами, нужно вручную подтвердить на возможность реальной эксплуатации; ложные срабатывания и пропуски встречаются часто, и в итоге логические уязвимости бизнес-логики всё равно определяет человек.
В каких случаях стоит обратиться в MIC Studio
Если в вашей команде нет выделенного специалиста по безопасности, или вы как раз делаете редизайн корпоративного сайта, мини-программу записи, административную панель и не хотите пассивно тушить пожары после запуска — можно передать безопасность нам.
MIC Studio занимается корпоративными сайтами, разработкой мини-программ, разработкой App, а также разработкой скриптов, тестированием безопасности сайтов и обратным тестированием (reverse testing). Мы предпочитаем на этапе разработки пройти по чек-листу права доступа, загрузку файлов и API, а не доделывать после инцидента.
Три практические рекомендации
1. Перед запуском составьте список API-эндпоинтов и по каждому подтвердите три пункта: проверка авторизации, проверка принадлежности данных, ограничение частоты запросов. Если чего-то не хватает — заведите задачу.
2. Рассматривайте загрузку и скачивание отдельно как точку риска: убедитесь, что каталог хранения не исполняемый, тип файла определяется по содержимому, скачивание проходит проверку прав.
3. Заложите бюджет и время на тестирование безопасности: перед релизом важных версий проводите проверку, не считайте безопасность опциональным пунктом после запуска.