Симптом у старой админки обычно выглядит безобидно: форма меняет профиль, сессия работает, а после релиза никто не может показать, какие условия действительно защищают это изменение. В настройке лежат несколько headers, в коде есть проверка пользователя, но связь между активом, угрозой и проверкой не записана. Цена такой неопределённости конкретна: команда может добавить ещё один заголовок, оставить state-changing маршрут без server-side permission или принять успешный ответ за доказательство, что посторонний запрос не изменит данные.
В ноябре 2020 года я бы начал не с большого аудита и не с обещания «закрыть web security». Ниже — учебный маршрут POST /admin/profile на вымышленном origin https://admin.example.test. Его предполагаемый эффект — изменение synthetic display name; fixture останавливается раньше, на решении до эффекта. Цель — собрать маленький baseline: известная сессия, токен и origin для state change, permission на сервере, cookie contract и ограничивающий CSP header. Это не pentest, не security scan и не подтверждение production-защиты.
Сначала называем актив и цену ошибки
Актив здесь не «сайт вообще», а возможность изменить профиль из административной формы. Угроза — запрос приходит не в ожидаемом пользовательском сценарии или пользователь с действующей сессией вызывает действие без нужного права. Контроль — не одно условие, а несколько независимых: сервер узнаёт сессию, для формы сравнивает CSRF token и ожидаемый origin, затем проверяет permission перед побочным эффектом. Доказательство — фиксированный отрицательный сценарий, который получает 403, и явный положительный сценарий, который получает 204.
Такое сужение важно. Cookie с HttpOnly полезен для ограничения доступа скрипта к значению cookie, но сам по себе не отвечает на вопрос, можно ли отправить нежелательное действие из браузера. Аналогично CSP ограничивает источники контента на стороне user agent, но не заменяет validation input, encoding output и authorisation в приложении. OWASP ASVS 4.0.2 уже был доступен в октябре 2020 года; я использую его как список проверяемых областей, а не как наклейку «соответствует стандарту».
Матрица не даёт потерять границу контроля
| Актив | Угроза в узком маршруте | Контроль | Что считаем доказательством |
|---|---|---|---|
| Изменение display name | запрос проходит без ожидаемого контекста формы | сравнить Origin и CSRF token до update | fixture отклоняет foreign origin и пустой token с 403 |
| Сессия администратора | значение cookie доступно скрипту или посылается без HTTPS-контракта | Secure, HttpOnly, узкий Path=/admin | учебная карта response headers содержит три атрибута |
| Право на изменение | аутентифицированный пользователь пишет без роли | server-side profile:write перед эффектом | fixture отклоняет profile:read с 403 |
| Разметка admin page | инъекция загружает неожиданный script или объект | validation/encoding в приложении плюс CSP2 policy | в карте headers есть default-src, object-src и frame-ancestors |
В строке про сессию Path — ограничение области отправки cookie, а не граница авторизации. RFC 6265 прямо описывает механизмы Cookie и Set-Cookie; из этого не следует, что cookie attribute заменяет серверную проверку права. В строке про CSP также нет обещания «остановить XSS». W3C CSP Level 2 называет policy дополнительной защитой: сначала приложение корректно работает с input и output, затем browser получает более узкий список допустимых источников.
Один state change должен пройти через все gates
Симптом «форма сработала» ничего не говорит о порядке проверок. Причина ошибки часто в том, что разработчик смешивает наличие сессии с правом на конкретное действие. Проверка должна быть простой: до вызова функции обновления собрать method, path, session, origin, token и permission; затем явно остановить маршрут на первом неподходящем условии. Действие — оставить этот порядок рядом с кодом и не переносить его в неочевидный клиентский обработчик.
// Учебный псевдокод одного HTML-маршрута. Не middleware и не framework API.
const decision = evaluateTrainingStateChange({
method: 'POST',
path: '/admin/profile',
sessionId: request.cookie.sid,
origin: request.header.origin,
csrfToken: request.form.csrf,
permission: request.user.permission,
});
if (!decision.allowed) return response.status(decision.status).end();
return updateTrainingProfile(request.form.displayName).status(204).end();Это намеренно не готовое middleware и не код какого-либо framework. В учебной форме token передаётся в body, а origin сравнивается только для одного HTML state-changing маршрута. В реальном приложении надо отдельно решить, какие клиенты существуют, когда browser посылает Origin, как выдаётся token, где хранится сессия и как API отличается от формы. Но permission всё равно остаётся серверной границей: клиентский скрытый элемент, URL и кнопка не являются доказательством права.
Headers описывают контракт ответа, а не магическую броню
Симптом у конфигурации другой: header записан в wiki, но никто не знает, на каком route и в каких ответах его ждут. Причина — security policy живёт отдельно от маршрута. Проверка — сделать маленькую карту response headers и привязать её к /admin/, а не включать случайный набор директив глобально. Действие — перед применением сверить syntax с версией веб-сервера, инвентаризировать фактические scripts, styles и frames, а затем проверить ответ разрешённого стенда.
# Учебный фрагмент, не готовая конфигурация production-сервера.
# admin.example.test — учебный origin; внешний адрес или секрет здесь не нужны.
location /admin/ {
add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;
add_header Referrer-Policy "same-origin" always;
proxy_pass http://training_admin_upstream;
}
# Атрибуты cookie выставляет приложение после успешной аутентификации:
# Set-Cookie: sid=...; Path=/admin; Secure; HttpOnlyВ примере policy запрещает plugin content, ограничивает base URL и запрещает встраивание страницы в frame. Она также разрешает scripts только с того же origin. Это может сломать старую страницу с inline script, внешним widget или другим asset host. Поэтому фрагмент не надо копировать в production «как есть»: сначала составляют список необходимых ресурсов, фиксируют допустимый риск и проверяют выбранную версию nginx. В статье нет реального proxy, upstream или HTTP-запроса; конфигурация показывает форму контракта, а не выполненную настройку.
Короткий HTTP-след лучше общего заявления
Для маршрута полезно хранить не только код, но и один ожидаемый обмен. Симптом неопределённости — спор о том, должен ли route требовать origin, token или permission. Причина — контроль не выражен наблюдаемыми полями. Проверка — описать разрешённый учебный request и expected response headers. Действие — превратить пару в тест или безопасную ручную проверку на разрешённом стенде, когда такой стенд появится.
POST /admin/profile HTTP/1.1
Host: admin.example.test
Origin: https://admin.example.test
Cookie: sid=training-session-42
Content-Type: application/x-www-form-urlencoded
displayName=Alex&csrf=training-csrf-6fd2
HTTP/1.1 204 No Content
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Set-Cookie: sid=training-session-42; Path=/admin; Secure; HttpOnly
Referrer-Policy: same-originЗдесь нет реального session ID, адреса, пользователя или данных профиля. admin.example.test — учебный origin, а token намеренно короткий и не предназначен для защиты чего-либо вне fixture. Статус 204 означает лишь успешный исход синтетического маршрута. Нельзя из него сделать вывод, что TLS настроен, cookie реально доставляется браузером, CSP принят каждым user agent или сервер выдал headers на ошибке. Эти вопросы относятся к следующей, уже разрешённой проверке окружения.
Fixture удерживает отрицательные сценарии рядом с маршрутом
Симптом регрессии проявится, если после следующей правки один из gates перестанет участвовать в решении. Причина может быть в перестановке middleware, другом имени поля или слишком широком условии. Проверка не требует подключаться к серверу: fixture меняет по одному training input и сравнивает решение. Действие — запускать её вместе с revision и не называть результатом этой команды проверку реального browser, proxy или security perimeter.
# В памяти: сеть, browser, proxy и scanner не запускаются.
node web/scripts/upgrade-2020-11.mjs --verify-fixture
# Ищем не уязвимость, а сохранение учебного контракта:
# expectedRequestAccepted=true
# foreignOriginRejected=true
# missingTokenRejected=true
# insufficientPermissionRejected=true
# cspContractPresent=true
# sessionCookieContractPresent=trueВ этой fixture foreign origin, пустой token и роль profile:read должны завершиться 403. Успешный synthetic request получает 204. Отдельно проверяется только наличие заданных полей CSP и Set-Cookie в объекте response contract. Если ответ на реальном стенде будет отличаться, это не повод менять fixture под сервер: сначала нужно назвать, какая граница модели отличается, и решить, расширяем ли contract либо обнаружили ошибку rollout.
Нумерованный маршрут для первой правки
- Выбрать один state-changing маршрут и назвать актив: какое именно состояние он меняет и кому принадлежит право на это действие.
- Записать одну угрозу, которую можно проверить без атаки: foreign origin, пустой token, отсутствующая сессия или недостаточное permission.
- Поставить server-side gates до побочного эффекта: session, context формы, token и permission. Не переносить permission в шаблон или JavaScript.
- Собрать response contract: cookie attributes для HTTPS-сценария и CSP policy с ограниченной областью. До rollout сверить каждый directive с реальными assets и версией сервера.
- Добавить положительный и отрицательные учебные сценарии. Положительный маршрут доказывает только доступность функции; отрицательные доказывают, что конкретные gates действительно останавливают запрос.
- Записать verdict и исключения: нет ли API-клиентов, внешних origins, upload, персональных данных, rate limiting или другого актива, который требует отдельной модели угроз.
Граница этой практики
Этот baseline не делает приложение «безопасным». Он не проверяет TLS, password storage, account recovery, file upload, SQL injection, logging, dependency vulnerabilities, rate limit, CORS, реальные браузеры или внешний сетевой периметр. Он также не запускает nginx и не утверждает, что header дошёл до production. Его результат скромнее и полезнее: для одного учебного изменения известны актив, угроза, control и evidence. Следующий инженер сможет расширить матрицу, не выдавая эту первую точку за полный AppSec-процесс.
Все origin, cookies, токены, заголовки, имена маршрутов и результаты ниже учебные. Модуль не открывает сеть, не сканирует цели, не проверяет реальный сервер и не хранит секреты.
Проверяемые источники
- OWASP ASVS 4.0.2 — релиз 28 октября 2020 года — историческая версия, доступная в ноябре 2020 года; задаёт проверяемые требования, но не заменяет модель угроз конкретного приложения
- OWASP Top 10:2017 — версия 2017 года; используется как язык для разговора о рисках, а не как готовый список настроек для любого сервера
- RFC 6265 — HTTP State Management Mechanism, апрель 2011 — описывает поля Cookie и Set-Cookie, включая атрибуты Secure, HttpOnly и Path; не превращает один cookie-атрибут в защиту от всех угроз
- W3C Content Security Policy Level 2 — Recommendation, 15 декабря 2016 года — историческая спецификация CSP2: политика передаётся HTTP-заголовком и является дополнительным барьером, а не заменой validation и encoding
- nginx: ngx_http_headers_module — add_header — официальная документация синтаксиса; фрагмент конфигурации применим только после сверки с версией и маршрутизацией конкретного сервера