Главная › Backend vulnerabilities

Backend vulnerabilities

Уязвимости бэкенда на примере маркетплейса: инъекции, SSRF, IDOR, mass assignment, обход пути, XXE, подбор паролей, CSRF и CORS, гонки, ошибки с JWT. Атака, код на четырёх языках, починка и тест.

← назад к разделу

Раздел про дыры, которые бэкенд-разработчик сам пишет в обычном коде: склеил SQL из строки, сходил по ссылке из запроса, вернул заказ по номеру без проверки владельца, принял JSON целиком в сущность. Ни одна из них не требует хитрой инфраструктуры, все находятся на ревью, если знать, куда смотреть.

Здесь нет теории ради теории. Каждая статья показывает атаку на одном и том же маркетплейсе, уязвимый код на Java, Go, Node и Python, починку и тест, который ловит регрессию. В каждой статье есть живые примеры: их можно запустить прямо на странице и увидеть, как атака проходит, а после починки перестаёт.

Зачем отдельный раздел

Паттерны авторизации отвечают на вопрос «кто ты и что тебе можно»: токены, роли, владение ресурсом, вызовы между сервисами. Но сервис с идеальной авторизацией всё равно отдаёт чужие данные через ' OR 1=1 --, ходит во внутреннюю сеть по ссылке на картинку и пишет файл за пределы каталога. Это другой класс ошибок: не «кому можно», а «что сервер делает с недоверенным вводом».

Правила для автоматического ревью собраны в стандарте безопасности бэкенда: SAST, уязвимые зависимости, секреты, образы, криптография. Этот раздел объясняет, откуда эти правила взялись и как выглядит дыра, которую они закрывают.

Карта статей и OWASP

Рамка раздела - два списка OWASP: OWASP Top 10:2025 для веб-приложений и OWASP API Security Top 10:2023 для API. Категории ниже сверены со списками CWE на страницах категорий Top 10:2025. Прочерк значит, что отдельной категории под тему в списке нет.

СтатьяTop 10:2025API Top 10:2023Главные CWE
Инъекции: SQL, NoSQL, команды ОС и шаблоныA05 Injection-CWE-89, CWE-78, CWE-943
SSRFA01 Broken Access ControlAPI7 SSRFCWE-918
IDOR и BOLAA01 Broken Access ControlAPI1 BOLA, API5 BFLACWE-639
Mass assignment и лишние поля в ответеA08 Software or Data Integrity FailuresAPI3 BOPLACWE-915, CWE-213
Обход пути и загрузка файловA01, A06 Insecure Design-CWE-22, CWE-434
XXE и небезопасная десериализацияA02 Security Misconfiguration, A08-CWE-611, CWE-502
Подбор паролей и лимиты запросовA07 Authentication FailuresAPI2, API4CWE-307, CWE-770
Открытый редирект, CSRF и CORSA01, A02API8 Security MisconfigurationCWE-601, CWE-352, CWE-942
Гонки и двойное списаниеA06 Insecure Design-CWE-362, CWE-367
Ошибки с JWTA04 Cryptographic Failures, A07API2 Broken AuthenticationCWE-347
Как искать уязвимостивсевсе-

Если времени мало, начни с четырёх: инъекции, IDOR, SSRF и JWT. Это ядро раздела, остальные статьи опираются на те же приёмы.

Как читать статью

Все статьи построены одинаково, чтобы по ним было удобно возвращаться к нужному месту:

  1. Атака. Что делает атакующий и что получает: чужие заказы, доступ к метаданным облака, списанные дважды деньги.
  2. Код. Как дыра выглядит в обычном обработчике на четырёх языках. Язык переключается над блоком кода.
  3. Починка. Не «экранируй ввод», а конкретный приём: параметр вместо склейки, список разрешённых значений, проверка владельца в самом запросе.
  4. Проверка. Тест, который воспроизводит атаку, и что смотреть на ревью. Тест остаётся в проекте и ловит регрессию.

Дальше идут типичные ошибки, разделы «Глубже» для тех, кому нужны детали, и «Коротко» для повторения перед собеседованием.

Сквозной пример: маркетплейс

Все атаки показаны на одном маркетплейсе. У него есть покупатели и продавцы, заказы и платежи, поддержка с доступом к чужим заказам, вебхуки для продавцов, загрузка картинок товаров, экспорт заказов в PDF и выплаты продавцам. Этого хватает, чтобы каждая уязвимость выглядела как задача из реального проекта:

  • покупатель меняет номер в /orders/1001 и видит чужой заказ;
  • продавец указывает вебхук на http://169.254.169.254/ и получает ключи облака;
  • поиск по товарам склеивает сортировку из параметра запроса;
  • два одновременных запроса применяют промокод «один на покупателя» дважды.

Тот же маркетплейс используется в паттернах авторизации и в кейсе Use Case Pattern, поэтому сущности и роли знакомы.

Что дальше