Проведение аудита безопасности веб-приложения (OWASP Top 10)
Аудит безопасности по методологии OWASP — систематическая проверка приложения на наличие уязвимостей из списка наиболее критичных рисков. Включает автоматизированное сканирование, ручной анализ кода и бизнес-логики, тестирование аутентификации и авторизации.
OWASP Top 10 (2021): что проверяем
| ID | Категория | Примеры |
|---|---|---|
| A01 | Broken Access Control | IDOR, privilege escalation |
| A02 | Cryptographic Failures | слабые алгоритмы, открытые данные |
| A03 | Injection | SQL, NoSQL, OS, LDAP |
| A04 | Insecure Design | отсутствие rate limit, предсказуемые токены |
| A05 | Security Misconfiguration | дефолтные пароли, verbose errors |
| A06 | Vulnerable Components | устаревшие зависимости с CVE |
| A07 | Auth Failures | слабые пароли, небезопасные сессии |
| A08 | Software & Data Integrity | insecure deserialization, CI/CD атаки |
| A09 | Logging Failures | недостаточное логирование |
| A10 | SSRF | запросы к внутренним ресурсам |
Этап 1: Разведка и картирование (3–5 дней)
Инвентаризация всех входных точек приложения:
# Сканирование поверхности атаки
nmap -sV -sC -p- target.example.com
# Обнаружение директорий и файлов
ffuf -w /usr/share/wordlists/dirb/big.txt \
-u https://target.example.com/FUZZ \
-mc 200,301,302,403
# Сбор JS-эндпоинтов
katana -u https://target.example.com -jc -d 3
# Анализ технологий
whatweb https://target.example.com
wappalyzer https://target.example.com
Результат: полная карта эндпоинтов, используемые технологии, версии компонентов.
Этап 2: Автоматизированное сканирование (1–2 дня)
# OWASP ZAP — полное активное сканирование
zap-cli quick-scan --self-contained \
--start-options '-config api.disablekey=true' \
https://target.example.com
# Nikto — сканер веб-сервера
nikto -h https://target.example.com -ssl -output report.html
# Nuclei — шаблонные проверки CVE и мисконфигураций
nuclei -u https://target.example.com \
-t cves/ -t misconfigurations/ \
-severity critical,high,medium
# Semgrep — статический анализ кода
semgrep --config=p/owasp-top-ten ./src
Этап 3: Тестирование аутентификации и авторизации (3–5 дней)
Broken Access Control (A01):
# IDOR — замена ID в запросе
GET /api/users/1337/profile → 200 OK (чужой профиль)
GET /api/orders/9999/details → должен вернуть 403, не 200
# Privilege escalation
POST /api/admin/users
Authorization: Bearer {regular_user_token}
→ должен вернуть 403
# Автоматизация проверки IDOR
import requests
user_token = "eyJ..."
headers = {"Authorization": f"Bearer {user_token}"}
for uid in range(1, 100):
r = requests.get(f"https://target.com/api/users/{uid}/profile", headers=headers)
if r.status_code == 200 and uid != current_user_id:
print(f"IDOR found: user {uid} accessible")
JWT-уязвимости:
- Алгоритм
none— принять без подписи - RS256 → HS256 — подделка с публичным ключом
- Слабый secret — перебор через
hashcat
# Перебор JWT secret
hashcat -a 0 -m 16500 jwt.txt wordlist.txt
Этап 4: Инъекции и клиентские атаки (3–4 дня)
# SQLmap — проверка всех параметров
sqlmap -u "https://target.com/search?q=test" \
--level=5 --risk=3 --dbs --batch
# XSS сканирование
dalfox url "https://target.com/search?q=test" \
--output xss_report.txt
# Template Injection
# Payloads: {{7*7}}, <%= 7*7 %>, ${7*7}
SSRF-проверки:
# В параметрах URL/redirect/webhook
url=http://169.254.169.254/latest/meta-data/ # AWS metadata
url=http://localhost:6379/ # Redis
url=file:///etc/passwd
Этап 5: Анализ конфигурации (1–2 дня)
# Проверка TLS/SSL
testssl.sh --full https://target.example.com
sslyze --regular target.example.com
# Анализ HTTP-заголовков безопасности
securityheaders.com/target.example.com
# Проверка зависимостей на CVE
npm audit --audit-level=moderate
composer audit
pip-audit
# Поиск секретов в коде
gitleaks detect --source . --report-format json
truffleHog git file://. --only-verified
Этап 6: Анализ бизнес-логики (2–3 дня)
Автоматизация не заменяет ручной анализ бизнес-логики:
- Обход платёжных ограничений (negative amounts, race conditions)
- Манипуляция с промокодами и скидками
- Обход email-верификации
- Небезопасные прямые ссылки на файлы (LFI через download?)
- Password reset без инвалидации старых токенов
Формат отчёта
Каждая находка документируется:
## VULN-001: SQL Injection в поиске
**Severity:** Critical (CVSS 9.8)
**Affected:** GET /api/search?q=
**CWE:** CWE-89
### Описание
Параметр `q` подставляется в SQL-запрос без параметризации.
### Proof of Concept
GET /api/search?q=' OR '1'='1
→ Возвращает все записи из таблицы
### Влияние
Полный доступ к базе данных, включая пользователей и платёжные данные.
### Рекомендация
Использовать подготовленные запросы. Пример:
$stmt = $pdo->prepare('SELECT * FROM products WHERE name LIKE ?');
$stmt->execute(["%{$q}%"]);
### Статус
Не исправлено
Итоговый отчёт
Содержит:
- Executive Summary для руководства (без технических деталей)
- Техническую часть с PoC для каждой уязвимости
- Матрицу рисков (Severity × Likelihood)
- Дорожную карту исправлений с приоритетами
- Контрольный список OWASP Top 10 (что проверено, статус каждого пункта)
Срок проведения аудита
| Тип приложения | Срок |
|---|---|
| Лендинг / корпоративный сайт | 3–5 дней |
| SaaS с авторизацией | 7–14 дней |
| Финансовое приложение / маркетплейс | 14–21 день |
| После исправлений — retesting | 2–3 дня |







