CSRF vs SSRF на собеседовании системного аналитика

Зачем спрашивают на собесе SA

CSRF и SSRF — частые атаки в OWASP Top-10. SA должен закладывать защиту в архитектуру.

CSRF: суть атаки

Cross-Site Request Forgery. Жертва залогинена в bank.com. Атакующий заставляет браузер жертвы сделать запрос к bank.com от имени жертвы.

<!-- На сайте evil.com -->
<form action="https://bank.com/transfer" method="POST">
  <input name="to" value="hacker_account">
  <input name="amount" value="10000">
</form>
<script>document.forms[0].submit()</script>

Жертва открывает evil.com → форма отправляется на bank.com → cookies автоматически идут (потому что cookies для bank.com).

Условия атаки:

• Жертва аутентифицирована на target site.
• Cookie-based auth (или Basic auth).
• Action не требует доп. confirmation.

Защита от CSRF

1. CSRF tokens. При рендеринге формы — secret token (per-session или per-form). Сервер проверяет.

<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="abc123xyz">
  ...
</form>

Атакующий не знает token (same-origin policy не даёт прочитать страницу bank.com).

2. SameSite cookies.

Set-Cookie: session=abc; SameSite=Strict

• Strict — cookie не отправляется на cross-site requests (даже navigation).
• Lax — cookie идёт на top-level navigation, но не на iframe / form post / fetch.
• None — без ограничений (требует Secure).

С 2020 Chrome дефолт — Lax для cookies без явного SameSite.

3. Custom request headers. AJAX делает X-Requested-With: XMLHttpRequest. HTML-форма не может (CORS не пускает custom headers без preflight). API проверяет наличие header.

4. Origin / Referer header. Сервер проверяет, что request пришёл с своего домена.

SSRF: суть атаки

Server-Side Request Forgery. Сервер делает HTTP-запрос по URL, контролируемому пользователем. Атакующий заставляет сервер сходить во внутреннюю сеть.

# уязвимый код
url = request.params['avatar_url']  # user input
response = requests.get(url)
save_image(response.content)

Атакующий передаёт url=http://localhost:8080/admin или url=http://169.254.169.254/latest/meta-data/ (AWS metadata).

Чего может достичь:

• Прочитать internal services (admin panels, БД).
• Cloud metadata leak (AWS / GCP / Azure credentials).
• Port scan internal сети.
• Bypass firewalls (запрос идёт изнутри).
• Read local files (file:///etc/passwd).

Жертвы: Capital One breach 2019 — SSRF через WAF выдал AWS credentials.

Защита от SSRF

1. Allowlist URLs. Не позволять любой URL — только разрешённые домены.

allowed_domains = {'images.example.com', 'cdn.example.com'}
parsed = urlparse(url)
if parsed.hostname not in allowed_domains:
    raise SecurityError

2. DNS resolution check. Резолвить domain → проверить IP не в private range.

import ipaddress, socket

ip = socket.gethostbyname(parsed.hostname)
if ipaddress.ip_address(ip).is_private:
    raise SecurityError

Внимание: TOCTOU race — между resolution и реальным запросом IP может смениться (DNS rebinding). Лечение — проверять final IP.

3. Disable redirects. HTTP 30x может увести в blacklist.

requests.get(url, allow_redirects=False)

4. Disable file:// и другие протоколы.

5. Block cloud metadata endpoints. 169.254.169.254, metadata.google.internal.

6. Network segmentation. Application server не имеет доступа к internal admin endpoints.

IDOR — связанная атака

Insecure Direct Object Reference. Пользователь меняет ID в URL и получает чужие данные.

GET /api/orders/123  → мой заказ
GET /api/orders/124  → чужой заказ (без проверки ownership)

Защита:

• Authorization check на каждом endpoint: WHERE order.user_id = current_user.id.
• UUID вместо incrementing IDs (помогает enumeration, но не отменяет authorization).
• Indirect references (отображение 1, 2, 3 в abc, xyz, qwe per user).

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

CSRF tokens только на login form. На любых state-changing requests (POST, PUT, DELETE).

SameSite=None без Secure. Современные браузеры отвергают.

SSRF whitelist только по домену. Открыто на DNS rebinding, redirect.

Blacklist private ranges пропуская metadata. 169.254.0.0/16 — отдельный allowlist deny.

Авторизация только в UI. API endpoints должны проверять отдельно.

Игнорировать Referer. Хоть и spoofable, дополнительный сигнал.

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

• SQL injection и XSS на собесе SA
• OWASP top-10 на собесе SA
• JWT на собесе SA
• OAuth 2.1 flows для SA
• Подготовка к собесу системного аналитика

FAQ

CSRF на JSON API?

Если API использует cookies для auth — да, уязвим. Защита: SameSite, Origin header check, или Bearer tokens вместо cookies.

SSRF в Python с urllib?

Те же риски. Любой HTTP-клиент с user-controlled URL.

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

Нет. Статья основана на OWASP Top-10 и cheatsheets.

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