Веб-безопасность и OWASP Top 10

01OWASP Top 10 простыми словами

OWASP (Open Worldwide Application Security Project) публикует Top 10 на основе реальных данных об уязвимостях и опросов сообщества. Редакция 2025 года выглядит так: A01 Broken Access Control (пользователи получают доступ к данным или действиям, к которым не должны; SSRF теперь входит в эту категорию); A02 Security Misconfiguration; A03 Software Supply Chain Failures (уязвимые или скомпрометированные зависимости, инструменты сборки и пайплайны); A04 Cryptographic Failures; A05 Injection (SQL, команды, а также XSS); A06 Insecure Design; A07 Authentication Failures; A08 Software or Data Integrity Failures; A09 Security Logging and Alerting Failures; A10 Mishandling of Exceptional Conditions (ошибки, при которых система «открывается» или раскрывает детали). Используйте его для повышения осведомлённости и как чек-лист для ревью, а не как полный стандарт; за детальными требованиями обращайтесь к OWASP Application Security Verification Standard (ASVS) и API Security Top 10 — они идут глубже.

02Broken access control, SSRF и CSRF

Broken access control — самый распространённый серьёзный дефект. Классический пример: GET /api/orders/1043 возвращает любой заказ, потому что код проверяет, что пользователь вошёл в систему, но не что заказ принадлежит ему. Это называется IDOR (insecure direct object reference). Решение — проверять владение или права на каждый запрос на сервере, в идеале через централизованные политики, запрещать по умолчанию и возвращать 404 для объектов, которые пользователю видеть нельзя. Server-side request forgery (SSRF) случается, когда ваш сервер загружает URL, переданный пользователем, например при импорте изображения, а атакующий направляет его на внутренние адреса или эндпоинты облачных метаданных. Разрешайте хосты и схемы по allow-list, резолвьте адреса и блокируйте приватные диапазоны IP, отключайте редиректы. Cross-site request forgery (CSRF) заставляет браузер залогиненного пользователя отправить запрос, меняющий состояние; защищайтесь cookie с SameSite, CSRF-токенами и проверкой заголовка Origin.

• Авторизуйте каждый доступ к объекту на сервере, а не в UI.
• Запрещайте по умолчанию; тестируйте со вторым пользовательским аккаунтом.
• Для загрузки по URL: allow-list, блокировка приватных диапазонов, никаких редиректов.

03Инъекции и XSS

Инъекция происходит, когда пользовательский ввод воспринимается как код. При SQL-инъекции поле поиска, содержащее ' OR 1=1 --, меняет смысл запроса, собранного конкатенацией строк, что приводит к утечке или удалению данных. Решение — параметризованные запросы, где данные передаются отдельно от SQL; их поддерживает любой современный драйвер и ORM. Будьте осторожны с хелперами для сырых запросов и динамическими именами колонок — им нужны allow-list'ы. Тот же принцип применим к командам оболочки, LDAP и шаблонизаторам. Cross-site scripting (XSS) — это инъекция в HTML: атакующий сохраняет скрипт в отзыве или имени профиля, и он выполняется в браузерах других пользователей, крадя сессии или совершая действия. Фреймворки вроде React по умолчанию экранируют вывод; опасные зоны — dangerouslySetInnerHTML, v-html, неэкранированный вывод в Blade и URL в атрибутах href. Санитизируйте rich HTML проверенной библиотекой и добавьте Content Security Policy как второй слой.

1import { Pool } from "pg";
2const db = new Pool();
3 
4// Vulnerable: input becomes part of the SQL text
5// db.query("SELECT * FROM users WHERE email = '" + email + "'");
6 
7// Safe: input is sent as a parameter, never parsed as SQL
8export async function findUser(email: string) {
9  const { rows } = await db.query(
10    "SELECT id, email FROM users WHERE email = $1",
11    [email],
12  );
13  return rows[0] ?? null;
14}

04Ошибки конфигурации и безопасные заголовки

Многим взломам не нужен хитрый эксплойт: оставленный в продакшене режим отладки, публичный бакет хранилища, пароли администратора по умолчанию, подробные страницы ошибок со стектрейсами, листинг директорий, открытые .env или папка .git, порт базы, открытый в интернет. Предотвращайте это конфигурацией в виде кода, настройками для каждого окружения и проверками в пайплайне деплоя. Заголовки безопасности добавляют защиту на стороне браузера. HTTP Strict Transport Security принудительно включает HTTPS. Content Security Policy (CSP) говорит браузеру, из каких источников разрешены скрипты, стили и изображения, и это блокирует большинство внедрённых скриптов; начните в режиме report-only, затем включите принудительно и предпочитайте nonce или хэши вместо 'unsafe-inline'. X-Content-Type-Options останавливает MIME sniffing, frame-ancestors в CSP предотвращает clickjacking, а Referrer-Policy и Permissions-Policy ограничивают, что утекает и что разрешено. Помечайте cookie как Secure, HttpOnly и SameSite.

1# nginx: baseline security headers (adapt CSP sources to your app)
2add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
3add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https://cdn.example.com; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;
4add_header X-Content-Type-Options "nosniff" always;
5add_header Referrer-Policy "strict-origin-when-cross-origin" always;
6add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
7server_tokens off;

05Секреты, зависимости и цепочка поставок

Секретам (API-ключам, паролям к базе, ключам подписи) место в переменных окружения или менеджере секретов, но никогда — в репозитории, клиентских бандлах, логах или сообщениях об ошибках. Давайте каждому секрету минимально необходимые права, разделяйте их по окружениям и ротируйте по расписанию и сразу же после любой подозрительной утечки; утёкший ключ, который нельзя быстро ротировать, — это дефект дизайна. Добавьте сканирование секретов в репозиторий и CI, чтобы ошибки ловились до push'а. Современные приложения в основном состоят из стороннего кода, поэтому сбои цепочки поставок теперь в первой тройке. Коммитьте lockfile'ы, проводите аудит зависимостей (npm audit, composer audit, Dependabot или Renovate), фиксируйте и ревьюйте CI action'ы, удаляйте неиспользуемые пакеты и с подозрением относитесь к новым пакетам с крошечным числом загрузок или install-скриптами. Держите фреймворки и рантаймы на поддерживаемых версиях.

06Rate limiting, боты, ревью и пентесты

Каждому эндпоинту, которым можно злоупотребить, нужны лимиты: вход, запросы OTP и сброса пароля, поиск, контактные формы, загрузка файлов и публичные API. Ограничивайте частоту по пользователю, IP и API-ключу, со строгими лимитами на аутентификацию; блокируйте или замедляйте аккаунты после повторных неудач и добавляйте CAPTCHA или proof-of-work только там, где злоупотребления реальны. CDN или WAF впереди поглощает объёмные атаки и блокирует известные вредоносные шаблоны. Загрузки требуют отдельного внимания: проверяйте тип по содержимому, а не по расширению, ограничивайте размер, защищайтесь от decompression bomb'ов и отдавайте файлы с отдельного домена или через подписанные ссылки. А затем сделайте безопасность процессом. Проводите threat modeling новых фич («что здесь мог бы сделать злонамеренный tenant?»), включайте пункты о безопасности в код-ревью, запускайте SAST и сканирование зависимостей в CI и заказывайте внешний пентест перед крупными запусками и периодически, исправляя находки по степени серьёзности.

• Строгие лимиты на вход, OTP и сброс пароля.
• Логируйте события безопасности (неудачные входы, отказы в доступе) и алертите на всплески.
• Пентесты находят то, что вы пропустили, но не заменяют безопасных привычек.

07Пароли, сессии и токены — как положено

Храните пароли с медленным memory-hard хэшем. Password Storage Cheat Sheet от OWASP рекомендует Argon2id минимум с 19 MiB памяти, 2 итерациями и parallelism 1; scrypt — если Argon2id недоступен; bcrypt — только для legacy-систем, с work factor 10 или выше и с учётом ограничения входа в 72 байта. Проверяйте новые пароли по спискам известных утечек, а не навязывайте странные правила состава. Для сессий непрозрачные случайные ID, хранящиеся на сервере, просты и мгновенно отзываемы. Если используете JWT, фиксируйте допустимый алгоритм на сервере (никогда не доверяйте заголовку alg из токена), проверяйте issuer, audience и срок действия, делайте access-токены короткоживущими и ротируйте refresh-токены при каждом использовании, считая повторное использование старого refresh-токена кражей и отзывая всё «семейство». Перевыпускайте ID сессии после логина и смены привилегий, чтобы предотвратить session fixation.

1import argon2 from "argon2";
2 
3// OWASP minimum: Argon2id, 19 MiB memory, 2 iterations, parallelism 1
4export function hashPassword(password: string) {
5  return argon2.hash(password, {
6    type: argon2.argon2id,
7    memoryCost: 19456, // KiB
8    timeCost: 2,
9    parallelism: 1,
10  });
11}
12 
13export function verifyPassword(hash: string, password: string) {
14  return argon2.verify(hash, password); // parameters are read from the hash
15}

08Строгая Content Security Policy и Trusted Types

Политики на allow-list (script-src с множеством CDN-хостов) часто обходятся, потому что один из разрешённых хостов может отдавать JSONP-эндпоинт или старую библиотеку, которой злоумышленник может злоупотребить. Строгая политика опирается на nonce или хэши: сервер генерирует новый случайный nonce для каждого ответа и ставит его на каждый легитимный тег script и в заголовок. Добавление 'strict-dynamic' позволяет выполняться и скриптам, загруженным доверенным скриптом, так что tag manager и бандлеры продолжают работать, а внедрённая разметка без nonce блокируется. Сочетайте это с object-src 'none' и base-uri 'none' или 'self'. Против DOM-based XSS Trusted Types (require-trusted-types-for 'script') заставляет браузер отклонять сырые строки в опасных sink вроде innerHTML и пропускать код через проверенную политику санитизации. Сначала выкатывайте в режиме report-only и исправляйте нарушения.

1Content-Security-Policy:
2  script-src 'nonce-r4nd0mBase64Value' 'strict-dynamic';
3  object-src 'none';
4  base-uri 'none';
5  frame-ancestors 'none';
6  require-trusted-types-for 'script';
7  report-to csp-endpoint

09SSRF в деталях: DNS rebinding и облачные метаданные

Блокировать приватные IP в строке URL недостаточно. Злоумышленники используют альтернативные записи (десятичные или IPv6-mapped адреса), редиректы на внутренние хосты и DNS rebinding, когда hostname во время вашей проверки резолвится в публичный IP, а мгновением позже при подключении — в 127.0.0.1 или 169.254.169.254. Надёжная защита резолвит hostname один раз, проверяет каждый полученный адрес по запрещённым диапазонам (loopback, private, link-local, unique local IPv6), затем подключается именно к этому IP, отправляя исходный заголовок Host, и перепроверяет при каждом редиректе либо отключает редиректы. Ещё лучше — пропускать все запросы, инициированные пользователем, через egress-прокси, который централизованно применяет политику и не имеет доступа к внутренним сетям. В AWS требуйте IMDSv2: его session token нужно получать PUT-запросом, что блокирует большинство простых попыток SSRF против учётных данных инстанса.

• Проверяйте резолвленные IP, а не текст URL; привязывайте подключение к ним.
• Блокируйте loopback, RFC 1918, link-local и IPv6 unique-local диапазоны.
• Пропускайте пользовательские запросы через изолированный egress-прокси.

10Cookie, CORS и изоляция в браузере

Атрибуты cookie — дешёвый и сильный слой. Secure и HttpOnly держат сессионные cookie подальше от обычного HTTP и от JavaScript. SameSite=Lax, который в современных браузерах используется по умолчанию, если не указан, блокирует большинство межсайтовых POST; используйте Strict для особо чувствительных cookie, а None; Secure — только когда межсайтовое использование действительно нужно. Префикс __Host- требует Secure, Path=/ и отсутствия атрибута Domain, поэтому скомпрометированный поддомен не сможет перезаписать cookie. CORS часто понимают неправильно: он ослабляет same-origin policy, а не защищает ваш API. Никогда не отражайте произвольные значения Origin вместе с Access-Control-Allow-Credentials: true; держите явный allow-list. Для более сильной изоляции Cross-Origin-Opener-Policy: same-origin отделяет ваше окно от cross-origin попапов, а Cross-Origin-Resource-Policy ограничивает, какие сайты могут встраивать ваши ресурсы.

1Set-Cookie: __Host-session=9f1c...; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600
2 
3Access-Control-Allow-Origin: https://app.example.com
4Access-Control-Allow-Credentials: true
5Vary: Origin
6 
7Cross-Origin-Opener-Policy: same-origin
8Cross-Origin-Resource-Policy: same-site