Ошибки настройки CORS (CWE-942): как отражение Origin раскрывает данные и как это исправить

Ключевые понятия и термины

Политика одного источника

Браузеры позволяют скрипту читать ответы только своего источника (схема, хост и порт). Заголовки ответа CORS — способ, которым сервер намеренно ослабляет это правило для названных источников.

Access-Control-Allow-Origin с учётными данными

Если ответ называет источник вызывающего в Access-Control-Allow-Origin и отправляет Access-Control-Allow-Credentials: true, скрипт этого источника может читать ответы на запросы, отправленные с cookie пользователя. Браузеры отвергают * вместе с учётными данными, поэтому неверно настроенные серверы возвращают источник эхом.

Отражение Origin и проверка по суффиксу

Копирование заголовка Origin в ответ доверяет всем сайтам. Проверки вроде endsWith('example.com'), поиск подстроки или регулярные выражения без якорей и с неэкранированными точками тоже принимают https://attacker-example.com.

Источник null

Изолированные iframe, URL data: и некоторые перенаправления отправляют Origin: null. Его может получить любой атакующий, поэтому разрешить null — всё равно что разрешить всех.

Vary: Origin

Когда Access-Control-Allow-Origin зависит от запроса, ответ должен содержать Vary: Origin, чтобы общие кеши не отдавали CORS-заголовки одного источника другому. Пакет cors добавляет его для динамических источников.

Пошаговый сценарий атаки

Исходный код: Уязвимый vs Защищённый вариант

// server.js: любой источник на example.com и null могут читать с cookie
import express from 'express';
import cors from 'cors';
import { accountFor, requireSession } from './account.js';

const app = express();

// true заставляет cors отражать Origin вызывающего вместе с учётными данными
app.use(cors({
  origin: (origin, callback) => callback(null, !origin || origin === 'null' || origin.endsWith('example.com')),
  credentials: true,
}));

// личные данные аккаунта доступны одобренным источникам
app.get('/api/account', requireSession, (req, res) => {
  res.json(accountFor(req.session.userId));
});

// server.js: два точных источника и больше ничего
import express from 'express';
import cors from 'cors';
import { accountFor, requireSession } from './account.js';

const app = express();

// полные источники со схемой и хостом, сравнение один в один
const ALLOWED_ORIGINS = new Set(['https://app.example.com', 'https://admin.example.com']);

// неизвестный или отсутствующий Origin не получает CORS-заголовков; cors добавляет Vary: Origin
app.use(cors({
  origin: (origin, callback) => callback(null, origin !== undefined && ALLOWED_ORIGINS.has(origin)),
  credentials: true,
  methods: ['GET', 'POST'],
  maxAge: 600,
}));

// персональные данные никогда не попадают в общие кеши
app.get('/api/account', requireSession, (req, res) => {
  res.set('Cache-Control', 'no-store');
  res.json(accountFor(req.session.userId));
});

Чек-лист по защите системы для инженеров

• Ведите список разрешённых полных источников (схема, хост и порт) с точным совпадением и сверяйте через поиск в Set; никогда не отражайте Origin и не используйте проверки по суффиксу, подстроке или регулярные выражения без якорей.
• Никогда не разрешайте источник null и не разрешайте учётные данные для источника, который вы не контролируете.
• Отправляйте Vary: Origin, когда Access-Control-Allow-Origin выбирается для каждого запроса, и Cache-Control: no-store в ответах с персональными данными.
• Задайте cookie сессии SameSite=Lax или Strict, чтобы межсайтовые запросы их не несли.
• Добавьте в CI тест, который отправляет Origin: https://attacker.example и Origin: null на маршруты с аутентификацией и падает, если возвращается Access-Control-Allow-Origin.

Источники

• CWE-942: Permissive Cross-domain Policy with Untrusted Domains
• MDN — Cross-Origin Resource Sharing (CORS)
• expressjs/cors — configuration options
• PortSwigger Research — Exploiting CORS misconfigurations for Bitcoins and bounties (2016)