Три уязвимости, которые регулярно встречаются в веб-приложениях и могут привести к утечке данных, компрометации аккаунтов и доступу к внутренней инфраструктуре: SQL injection, CSRF и SSRF. Кратко разберём, что это, чем опасно и как защищаться.
SQL injection
Возникает, когда пользовательский ввод напрямую попадает в SQL-запрос. Атакующий может изменить логику запроса: обойти авторизацию, прочитать, удалить или изменить данные.
Пример риска:
SELECT * FROM users WHERE login = 'input' AND password = 'input'Если строка собирается вручную, злоумышленник может подставить SQL-код.
Как защититься:
- использовать prepared statements / параметризованные запросы
- не собирать SQL через конкатенацию строк
- ограничивать права у БД-пользователя
- валидировать входные данные
- логировать подозрительные запросы и включать WAF при необходимости
CSRF (Cross-Site Request Forgery)
Это атака, при которой пользователь, уже авторизованный в системе, незаметно отправляет вредоносный запрос от своего имени. Например, смена пароля, email или перевод средств.
Когда это возможно:
- приложение полагается только на cookie-сессию
- сервер не проверяет источник запроса
- нет CSRF-защиты на state-changing операциях
Как защититься:
- использовать CSRF-токены
- включать SameSite для cookie (Lax или Strict)
- проверять Origin и Referer
- не выполнять критичные действия через GET
- для чувствительных операций добавлять повторный ввод пароля или 2FA
SSRF (Server-Side Request Forgery)
Сервер делает запрос по URL, который задаёт пользователь, а атакующий подсовывает адрес внутреннего сервиса: localhost, metadata endpoints, внутренние API, admin-панели.
Чем опасно:
- доступ к закрытым сервисам
- чтение метаданных облака и кража credentials
- сканирование внутренней сети
- обход сетевых ограничений
Как защититься:
- не доверять URL от пользователя
- использовать allowlist доменов и схем
- запрещать обращения к приватным IP, 127.0.0.1, 169.254.169.254, internal DNS
- отключать лишние редиректы
- разделять исходящий трафик через proxy/egress filtering
- ограничивать сетевые права приложения
⚠️ Главная мысль: большинство критичных уязвимостей появляются не из-за “хакерской магии”, а из-за отсутствия базовых защитных практик в коде и инфраструктуре.
Минимальный чек-лист для бэкенда:
- параметризованные запросы
- валидация и нормализация входных данных
- защита сессий и cookie
- CSRF-контроль
- ограничения на исходящие запросы
- принцип наименьших привилегий
- аудит логов и security-тесты
Хороший бэкенд — это не только производительность и бизнес-логика, но и безопасные значения по умолчанию 🛡️
Заодно загляните в подборку каналов про IT — там много полезного по бэкенду, архитектуре, безопасности и разработке.