OWASP Top 10 на собеседовании системного аналитика

Зачем SA знать OWASP

OWASP Top 10 — рейтинг самых частых веб-уязвимостей. SA не пишет код, но в ТЗ должны быть требования по безопасности — иначе разработка их не включит, security-ревью развернёт проект на месяц.

Главная боль без понимания OWASP — аналитик в ТЗ пишет «должна быть авторизация». Команда реализует JWT-авторизацию, но не проверяет, что пользователь A не может прочитать данные пользователя B. IDOR в проде — утечка данных.

В РФ на банковском SA-собесе OWASP спрашивают почти всегда. Junior — назвать категории, middle — расписать, senior — дать примеры в ТЗ.

Broken Access Control / IDOR

A01 в OWASP Top 10 (2021). Самая частая уязвимость.

IDOR (Insecure Direct Object Reference) — пользователь меняет ID в URL/payload и получает доступ к чужим данным.

GET /api/orders/123    → свой заказ, OK
GET /api/orders/456    → чужой заказ, тоже отдаём — БАГ

Защита:

• Проверка авторизации на каждый запрос: «принадлежит ли объект текущему пользователю»
• Использование UUID вместо инкрементальных ID (не защита, но усложняет атаку)
• Use ABAC/RBAC с явной проверкой ownership

В ТЗ: «при запросе данных пользователя по ID API проверяет, что текущая сессия имеет право на этот объект (ownership или explicit grant)».

Injection

A03. Внедрение кода через input.

SQL Injection:

# плохо: конкатенация
cursor.execute("SELECT * FROM users WHERE id = " + user_input)
# атака: user_input = "1; DROP TABLE users--"

Защита: parameterized queries.

cursor.execute("SELECT * FROM users WHERE id = %s", (user_input,))

ORM в большинстве случаев защищает по умолчанию. Уязвимость возникает в raw SQL или dynamic table/column names.

Other injections: OS command (shell injection), LDAP, NoSQL, XPath, Server-Side Template Injection.

В ТЗ: «все параметры запросов передаются параметризованно; user input не используется для построения identifier'ов или SQL-фрагментов».

Cryptographic failures

A02. Неправильное использование криптографии.

Типичные проблемы:

• Хранение паролей в открытом виде или MD5/SHA-1
• Использование симметричного шифрования с захардкоженным ключом
• TLS 1.0/1.1, weak ciphers
• Sensitive data в URL (попадает в логи, history)
• Чувствительные данные в headers без шифрования

В ТЗ:

• Пароли — bcrypt/argon2 с salt
• TLS 1.2+
• Чувствительные данные — только в body, шифрованный канал
• PII — шифрование at-rest и in-transit

Identification & Auth failures

A07. Слабые механизмы аутентификации.

Проблемы:

• Brute force без rate limiting
• Default/weak credentials
• Слабая password policy
• Session fixation, predictable session ID
• Persistent sessions без revocation

Защита:

• Rate limiting (5 попыток / 15 минут на email)
• Минимум 12 символов с энтропией
• 2FA для критичных операций
• Session ID — random 128+ bit, регенерация при login
• Logout = revocation

В ТЗ: явно описать password policy, rate limit, 2FA для каких операций, lifecycle сессии.

SSRF и XSS

A10. SSRF (Server-Side Request Forgery). Сервер делает запрос по URL от user input → атакующий заставляет сервер ходить во внутреннюю сеть.

# плохо: пользователь даёт URL, сервер делает GET
fetch_url(user_provided_url)
# атака: http://localhost:8500/admin (доступ к Consul)

Защита: allowlist URLs/доменов, блок internal IP (10.x, 172.16.x, 192.168.x, 127.x), отдельный network для outbound.

A03 — XSS (через injection). Атакующий внедряет JS в HTML-страницу, которая исполняется у других пользователей.

<!-- сайт показывает user input как HTML -->
<div>Привет, {{username}}</div>
<!-- атака: username = <script>fetch('/api/cookies').then(...)</script> -->

Защита: escaping output, Content Security Policy (CSP), httpOnly cookies (защита от чтения JS).

В ТЗ для бэка эти угрозы менее частые (это фронт-уязвимости), но SA должен помнить про них при проектировании user input flows.

Что описывать в ТЗ

Минимальный security-чеклист в ТЗ:

• Authn: способ (OAuth/JWT/SAML), 2FA, password policy, session lifecycle
• Authz: RBAC/ABAC, ownership-проверки на каждый объект
• Input validation: все user input валидируются на API, white-list где возможно
• PII: какие поля чувствительные, где маскировать в логах, шифрование at-rest
• Audit log: какие действия логируем (login, password change, sensitive ops), кто видит логи
• Rate limiting: на login и критичные API
• TLS: версия, отсутствие weak ciphers
• Secrets: хранение (Vault, KMS), rotation
• Сroption: dependency scanning, security headers

Это база. Отдельный security-review должен пройти каждое крупное ТЗ.

Частые ошибки

«Безопасность не моя ответственность». SA должен описать угрозы и контрмеры в ТЗ. Иначе команда не реализует.

SQLi через ORM «нельзя». Можно: raw queries, dynamic table names, поиск с LIKE без escape.

Хешировать пароли через MD5/SHA1. Слишком быстрые, ломаются GPU за минуты. bcrypt/argon2 с work factor.

Отдавать stack traces в проде. 500 с trace = info disclosure. В проде — generic error_id, детали в логах.

HTTP в проде. Любой sniffer перехватывает credentials/sessions. HTTPS обязателен.

Не логировать критические события. Failed logins, привилегированные действия — обязательно в audit log.

X-Powered-By и version-disclosure headers. Атакующий узнаёт стек, ищет CVE. Убирать.

Связанные темы

• JWT на собесе SA
• OAuth на собесе SA
• HTTP методы и коды на собесе SA
• Подготовка к собесу системного аналитика
• REST API на собесе SA

FAQ

Должен ли SA проводить penetration testing?

Нет, это работа security-инженера. SA должен описать требования в ТЗ, чтобы команда реализовала. Тестирование — отдельная команда или внешний аудит.

OWASP API Top 10 — это другое?

Да. OWASP Top 10 (2021) — про веб-приложения. OWASP API Top 10 (2023) — фокус на API: BOLA (broken object level authz), broken authentication, excessive data exposure. Для SA с API-фокусом — особенно полезен.

Что важнее для SA — код-уязвимости или дизайн-уязвимости?

Дизайн-уязвимости (broken access control, business logic flaws) — больше касаются SA. Код-уязвимости (SQLi, XSS) — ответственность разработчиков, но SA должен включить требования в ТЗ.

Кто отвечает за compliance (152-ФЗ)?

Юридическая команда + security. SA включает требования (классификация ПДн, локализация, согласия) в ТЗ. На собесе в банке/госкомпании — обязательны минимальные знания.

Как SA проверить, что команда реализовала security-требования?

Чек-лист в DoD, явная security-приёмка перед релизом, периодический pen-test, dependency scanning в CI.

Это официальная информация?

Нет. Статья основана на OWASP Top 10 (2021), OWASP API Top 10 (2023) и общей практике безопасной разработки.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.