Security

Шпаргалка по JWT, OAuth 2.0/OIDC, CORS/CSP, TLS/SSL, OWASP Top 10

🔐 JWT

Структура

header.payload.signature

Header: { "alg": "HS256", "typ": "JWT" }
Payload: { "sub": "123", "exp": 1234567890 }
Signature: HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Claims

Claim	Описание
`exp`	Expiration time (Unix timestamp)
`nbf`	Not before (недействителен до)
`iat`	Issued at (время выдачи)
`sub`	Subject (ID пользователя)
`iss`	Issuer (кто выдал)

Pitfalls

Не хранить секреты в JWT (они не зашифрованы)
Всегда проверять exp и nbf
Использовать HTTPS для передачи
Не использовать слабые алгоритмы (HS256 минимум)
Ограничивать размер payload

🔑 OAuth 2.0 / OIDC

Flows

Flow	Когда использовать
`Authorization Code`	Web приложения (серверная часть)
`PKCE`	SPA и мобильные приложения
`Client Credentials`	Machine-to-machine
`Implicit`	Устарел, не использовать

PKCE

// 1. Генерируем code_verifier (случайная строка)
code_verifier = random_string(43-128)

// 2. Создаем code_challenge
code_challenge = base64url(sha256(code_verifier))

// 3. В запросе авторизации
GET /authorize?code_challenge=...&code_challenge_method=S256

// 4. При обмене кода на токен
POST /token
{
  "code": "...",
  "code_verifier": code_verifier
}

Refresh Tokens

POST /token
{
  "grant_type": "refresh_token",
  "refresh_token": "...",
  "client_id": "..."
}

Response:
{
  "access_token": "...",
  "refresh_token": "...", // новый
  "expires_in": 3600
}

Scopes

GET /authorize?scope=read write admin

Примеры:
- read: только чтение
- write: чтение и запись
- admin: полный доступ
- openid profile email: для OIDC

🛡️ CORS / CSP

CORS типовые политики

// Разрешить все
Access-Control-Allow-Origin: *

// Разрешить конкретный домен
Access-Control-Allow-Origin: https://example.com

// С credentials
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
// Важно: нельзя использовать * с credentials

CSP типовые политики

// Строгая политика
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'

// С внешними ресурсами
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' data: https:

// Report-only режим
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report

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

Использование * с credentials: true
Не указан Access-Control-Allow-Methods для OPTIONS
Слишком мягкая CSP (использование 'unsafe-inline')
Отсутствие nonce или hash для inline скриптов

🔒 TLS/SSL

Цепочка сертификатов

Root CA
  └── Intermediate CA
      └── Server Certificate

Проверка:
1. Сертификат подписан Intermediate CA
2. Intermediate CA подписан Root CA
3. Root CA в trust store браузера

SAN (Subject Alternative Names)

Сертификат может содержать несколько доменов:
- example.com
- www.example.com
- api.example.com
- *.example.com (wildcard)

Все должны быть указаны в SAN

SNI (Server Name Indication)

Позволяет использовать несколько сертификатов на одном IP:
- Клиент указывает домен в TLS handshake
- Сервер выбирает правильный сертификат

Важно для виртуальных хостов

Типовые проблемы

Истек срок действия сертификата
Несовпадение домена (CN или SAN)
Неполная цепочка сертификатов
Слабые алгоритмы шифрования
Смешанный контент (HTTP на HTTPS странице)

⚠️ OWASP Top 10

#	Уязвимость	Защита
1	Broken Access Control	Проверка прав доступа, принцип наименьших привилегий
2	Cryptographic Failures	HTTPS, шифрование данных, безопасное хранение паролей
3	Injection	Параметризованные запросы, валидация входных данных
4	Insecure Design	Threat modeling, безопасная архитектура
5	Security Misconfiguration	Минимальная конфигурация, регулярные обновления
6	Vulnerable Components	Обновление зависимостей, сканирование уязвимостей
7	Authentication Failures	MFA, защита от брутфорса, безопасное хранение сессий
8	Software and Data Integrity	Проверка целостности, цифровые подписи
9	Security Logging Failures	Логирование событий безопасности, мониторинг
10	SSRF	Валидация URL, whitelist разрешенных доменов