Безопасность
OWASP Top 10: аудит и hardening уязвимого сервиса
Читать Top 10 — не то же самое, что находить и закрывать дыры, которые он называет. Возьми маленький намеренно уязвимый сервис, проведи аудит по категориям, докажи каждую уязвимость рабочим запросом, затем устрани в корне и докажи фикс — цикл, который сеньор гоняет в реальном security-ревью.
Преврати ментальную модель юнита в повторяемый аудит: отображай находки на категории OWASP, эксплуатируй их для подтверждения импакта, чини в корне (deny-by-default авторизация, allowlists, hardened конфиг, пропатченные зависимости) и верифицируй каждый фикс before/after-тестом.
Провести аудит маленького веб-сервиса (своего, OWASP Juice Shop или стартера ниже) против OWASP Top 10 (2021): найти не менее пяти находок в разных категориях, проэксплуатировать каждую для подтверждения, устранить в корне и доказать каждый фикс повторяемым before/after-тестом.
- Таблица находок: каждая строка называет категорию OWASP 2021, запрос эксплойта, доказавший её, фикс корневой причины и тест, который теперь её блокирует.
- Пять с лишним находок охватывают разные категории (не пять вариантов одного бага), причём A01 покрыт и примером IDOR, и примером отсутствия function-level authz.
- У каждого фикса есть повторяемый тест: тот самый запрос эксплойта, что работал раньше, теперь возвращает 403/404 (authz), отклоняется allowlist'ом (SSRF/CORS) или закрыт обновлением зависимости — прогнан вживую, а не заявлен.
- Абзац-объяснение хотя бы для одной находки, почему ты чинил корневую причину на сервере, а не добавлял правило WAF, неугадываемый id или скрытый элемент UI.
- Сделай threat-modeling одной фичи на Insecure Design (A04): напиши abuse cases (напр. подмена цены, обход rate-limit) рядом с user story и встрой серверный контроль, показав, что abuse case теперь падает.
- Добавь CI security-гейт: сканирование зависимостей/CVE плюс небольшой набор before/after-тестов эксплойтов, чтобы сборка падала при регрессии устранённой дыры или появлении новой критической CVE.
- Добавь детекцию A09 Security Logging & Monitoring Failures: структурированные логи auth-неудач, rate-limit на повторные неудачи и правило алерта на credential-stuffing — проверенное проигрыванием brute-force всплеска.
- Повтори защиту от SSRF против DNS-rebinding и обходов через редиректы, доказав, что перепроверка IP после редиректа блокирует хост атакующего, резолвящийся в приватный диапазон на втором запросе.
Это цикл, который ты будешь гонять в каждом реальном security-ревью: аудит против Top 10 как карты приоритизации, доказательство каждой находки рабочим эксплойтом, фикс в корне — deny-by-default авторизация, allowlists с отклонением приватных диапазонов, hardened CORS и конфиги, пропатченные зависимости — и закрепление каждого фикса before/after-тестом, чтобы он не регрессировал. Сделав это раз на маленьком уязвимом сервисе, доводишь production-версию до мышечной памяти, причём access control заслуживает наибольшей строгости, ведь он самый распространённый и среди самых вредоносных.