Многие руководители впервые серьёзно задумываются о безопасности после того, как сайт был заражён, панель администратора взломана или пользовательские данные были скачаны целиком. В этот момент разбирать логи и латать дыры обходится гораздо дороже, чем изначально выстроить защиту.
Честно говоря, подавляющее большинство распространённых уязвимостей в веб-разработке — это не какие-то сложные технологии, а базовая работа, которая не была выполнена. Ниже разберём по порядку самые частые ошибки из практики.
I. Инъекционные уязвимости: SQL-инъекции и командные инъекции
SQL-инъекция — самая классическая уязвимость. Причина проста: программа подставляет пользовательский ввод напрямую в SQL-запрос. Например, введя специально сконструированную строку в поле логина, можно обойти проверку пароля и даже выгрузить всю таблицу пользователей.
Типичные подходы и как избежать ошибок:
- Используйте параметризованные запросы или ORM, не пишите конкатенацию строк вручную
- Назначайте права учётной записи базы данных по принципу минимальных привилегий: если бизнесу нужно только чтение, не давайте права на запись
- Отключите подробные сообщения об ошибках в продакшене — сами сообщения об ошибках являются разведданными
- Проверяйте типы входных данных, например, ID должен допускать только цифры
С командными инъекциями та же история. В некоторых сценариях разработки скриптов требуется вызывать системные команды для обработки изображений или генерации файлов. Если имя файла подставляется напрямую в команду, злоумышленник сможет заодно выполнить другие инструкции. Такие проблемы особенно часто встречаются в системах администрирования.
II. Права доступа и обход авторизации: авторизация ≠ наличие прав
Это одна из самых недооценённых категорий в корпоративных сайтах и системах администрирования. Пользователь действительно авторизован, но получает доступ к данным, к которым не должен иметь доступа.
Разделяют два вида:
- Горизонтальный обход авторизации: обычный пользователь A, изменив номер заказа в URL, видит заказ пользователя B
- Вертикальный обход авторизации: обычный пользователь напрямую обращается к административному интерфейсу, например, для удаления пользователей или экспорта данных
Конкретный сценарий: в проекте разработки мини-программы для бронирования интерфейс имеет вид `/api/order/detail?id=1001`. Фронтенд показывает только собственные заказы, но бэкенд не проверяет, принадлежит ли этот заказ текущему пользователю. Достаточно изменить id на 1002, чтобы увидеть чужой номер телефона и адрес.
Что делать:
- Для каждого интерфейса, работающего с данными, серверная сторона должна проверять «имеет ли текущий пользователь право доступа к этой записи»
- Не полагайтесь на скрытие кнопок на фронтенде для контроля прав доступа
- Разделяйте интерфейсы админ-панели и пользовательской части, логика аутентификации должна быть независимой
III. Загрузка файлов и включение файлов
Сама по себе загрузка файлов не проблема — проблема в том, «можно ли выполнить загруженный файл».
Типичные ошибки:
- Проверяется только расширение на фронтенде — достаточно перехватить запрос и изменить его, чтобы загрузить PHP или JSP
- Каталог загрузки имеет права на выполнение — загрузив скрипт, можно сразу получить доступ к серверу
- Имена файлов предсказуемы — злоумышленник может перебрать и скачать их
Рекомендуемые меры:
- Проверяйте тип файла на сервере, используя белый список, а не чёрный
- Запретите выполнение скриптов в каталоге загрузки, разрешите только статический доступ
- Переименовывайте файлы, используя случайные строки, не сохраняйте исходный путь
- Обрабатывайте изображения повторно, попутно удаляя возможное вредоносное содержимое
IV. Уязвимости интерфейсов и бизнес-логики
Многие уязвимости находятся не на уровне кода, а в бизнес-процессах. Например:
- SMS-код подтверждения не имеет ограничения по количеству попыток и может быть подобран перебором
- Обратный вызов платежа не проверяет подпись — можно подделать статус «оплачено»
- Купоны можно получать параллельно — один человек получает сто штук
- Процесс восстановления пароля можно обойти и напрямую сбросить чужой пароль
Такие проблемы особенно заслуживают внимания в App-разработке и разработке мини-программ, поскольку поверхность атаки через интерфейсы шире, чем у традиционных сайтов. Многие думают: «Если в App не видно интерфейсов, значит, всё безопасно», — но стоит открыть инструмент перехвата трафика, и запросы видны как на ладони.
Рекомендации по избежанию ошибок:
- Добавьте ограничение частоты и риск-контроль для критичных интерфейсов
- Для чувствительных операций, таких как оплата и возврат, обязательна серверная проверка подписи и повторное подтверждение
- Переходы состояний бизнес-логики должны определяться на сервере, нельзя доверять состоянию, переданному с фронтенда
V. Проблемы зависимостей и конфигурации
Многие корпоративные сайты страдают не из-за дыр в собственном коде, а из-за слишком старых версий используемых открытых фреймворков и плагинов.
- Сторонние CMS и системы конструкторов сайтов долго не обновляются
- Конфигурация промежуточного ПО по умолчанию не изменена: слабые пароли админ-панели, стандартные порты открыты наружу
- Группы безопасности облачного сервера настроены слишком широко, база данных напрямую доступна из интернета
- Тестовые окружения, резервные копии и каталог .git синхронизированы в продакшен
Меры просты: регулярно обновляйте зависимости, перед релизом проводите проверку конфигурации, закрывайте порты, которые не должны быть открыты наружу, удаляйте лишние отладочные файлы из продакшена.
В каких случаях стоит обратиться в MIC Studio
Если ваш проект относится к одной из следующих ситуаций, а у собственной команды нет ресурсов на системную проверку, выгоднее привлечь профессиональную команду для проведения цикла тестирования безопасности:
- Корпоративный сайт только что прошёл редизайн и запущен, включает членство, формы, оплату
- Разработка мини-программы или App переходит в стадию тестирования, интерфейсов много, логика сложная
- Система администрирования включает множество ролей с разными правами, высок риск обхода авторизации
- Требуется реверс-тестирование для оценки рисков массовых вызовов интерфейсов и кражи данных
- Уже произошёл инцидент безопасности, необходимо определить причину и провести усиление защиты
Подход MIC Studio: сначала инвентаризация активов и интерфейсов, затем тестирование по направлениям — инъекции, права доступа, загрузка, логика, конфигурация — с выдачей воспроизводимого списка проблем и рекомендаций по исправлению, а не просто непонятного отчёта сканера.
Заключение: три вещи, которые можно сделать прямо сейчас
1. Проведите самопроверку прав доступа перед релизом: выпишите все интерфейсы и по каждому задайте вопрос: «Можно ли получить доступ без авторизации?» и «Увижу ли я чужие данные, если подменю ID пользователя?»
2. Контролируйте ввод и вывод: весь пользовательский ввод проверяется, все операции с базой данных параметризованы, все сообщения об ошибках не раскрывают лишнего.
3. Относитесь к безопасности как к постоянному процессу: регулярно обновляйте зависимости, периодически проверяйте конфигурацию, перед релизом важных версий проводите цикл тестирования безопасности — не ждите инцидента, чтобы начать исправлять.
Безопасность — это не разовый проект, а часть процесса разработки. Чем раньше об этом задуматься, тем меньше проблем будет в будущем.