РКН Аудит
CSRF — это подделка межсайтового запроса: чужая страница заставляет браузер вошедшего пользователя выполнить действие на вашем сайте, а браузер сам прикладывает к запросу сессионные cookie. Для персональных данных это опасно не «утечкой базы», а тихой сменой контактов в личном кабинете: подменив адрес почты или телефон, атакующий перехватывает восстановление пароля и получает доступ к профилю с заказами, адресами и историей. Слова «CSRF» в 152-ФЗ нет, но обязанность предотвращать несанкционированный доступ есть — в статье 19 152-ФЗ и в приказе ФСТЭК №21.
Проверить бесплатно, какие нарушения 152-ФЗ видны на вашем сайте и в его формах ←
Как работает CSRF и почему сервер ему верит?
Механика короткая. Пользователь вошёл в личный кабинет, у него в браузере живёт сессионная cookie. В соседней вкладке он открывает постороннюю страницу — из письма, из рекламы, из поиска. На той странице лежит форма или скрипт, который отправляет запрос на ваш сайт: например, «сменить электронную почту».
Браузер по умолчанию прикладывает cookie вашего домена к запросам на этот домен и исторически делал это независимо от того, с какой страницы запрос отправлен. Современные браузеры это сузили: атрибут SameSite со значением Lax применяется по умолчанию и отсекает кросс-сайтовые POST-запросы. Остаются изменяющие GET-переходы, поддомены и приложения с ослабленной настройкой cookie — и в этих случаях сервер получает корректную сессию, видит валидного пользователя и выполняет действие.
Ключевое отличие от других атак: сервер не взломан и данные не украдены напрямую. Использована не уязвимость в коде авторизации, а доверие сервера к сессии. Именно поэтому CSRF долго живёт незамеченным: в журналах это выглядит как обычное действие обычного пользователя.
Как CSRF превращается в доступ к персональным данным?
Сам по себе поддельный запрос данных не выгружает. Опасны сценарии, в которых он меняет то, что управляет доступом.
- Смена адреса электронной почты в профиле. Дальше атакующий запускает восстановление пароля, письмо приходит ему, и личный кабинет со всей историей заказов, адресами доставки и телефоном переходит под его контроль.
- Привязка другого номера телефона — тот же сценарий, но через СМС-код.
- Смена пароля, если форма не требует ввести текущий.
- Добавление второго администратора в панели управления сайтом: после этого доступ есть ко всем данным всех пользователей сразу.
- Изменение адреса доставки в оформленном заказе — данные не утекают, но товар уходит не туда, а сам факт подмены обнаруживается поздно.
- Запуск выгрузки в интерфейсах, где экспорт выполняется по ссылке: если ссылка на выгрузку в 10 000 записей открывается обычным GET-запросом, её можно инициировать со стороны.
- Отписка или отзыв согласия от имени человека — редкий, но неприятный сценарий: оператор теряет основание обработки и не понимает почему.
Первые три пункта — это перехват учётной записи пользователя, четвёртый — несанкционированное получение административного доступа. И то и другое по смыслу части 3.1 статьи 21 152-ФЗ вполне может оказаться неправомерным предоставлением доступа к персональным данным: норма говорит о «неправомерной или случайной передаче (предоставлении, распространении, доступе)» персональных данных. Если такое событие повлекло нарушение прав субъектов, запускаются сроки уведомления Роскомнадзора: первое уведомление — в течение 24 часов с момента выявления инцидента. Обратите внимание, что «обнаружение фактов несанкционированного доступа» из пункта 6 части 2 статьи 19 152-ФЗ — это требование к мерам защиты, а не самостоятельное основание для 24-часового уведомления. Порядок действий разобран в статье «Как обнаружить утечку персональных данных».
Что требуют от оператора нормы, если про CSRF в них ничего нет?
Нормативные акты по персональным данным не перечисляют техники атак — они формулируют классы мер. Это регулярно даёт повод сказать «в законе про CSRF ничего нет, значит, не обязаны», и это неверное чтение.
Статья 19 152-ФЗ обязывает оператора принимать меры, необходимые для защиты данных от неправомерного доступа, и называет среди них обнаружение фактов несанкционированного доступа, установление правил доступа к данным в информационной системе и регистрацию действий с ними, а также восстановление данных, модифицированных или уничтоженных вследствие несанкционированного доступа.
Постановление Правительства №1119 определяет уровень защищённости информационной системы — от 4 до 1, в зависимости от категории данных, типа актуальных угроз и числа субъектов. Уровень задаёт, какой набор мер обязателен.
Приказ ФСТЭК №21 раскрывает состав мер по группам: идентификация и аутентификация, управление доступом, регистрация событий безопасности, защита информационной системы и её компонентов. Защита от подделки запроса живёт внутри этих групп — оператор сам выбирает конкретные механизмы под актуальные угрозы. Что из приказа реально применимо к сайту, разобрано в статье «Приказ ФСТЭК №21: что касается владельца сайта».
Практический смысл этой конструкции: инспектор не спросит «есть ли у вас CSRF-токен». Он спросит, определён ли уровень защищённости, какие угрозы признаны актуальными и какими мерами они закрыты. Действия от имени вошедшего пользователя без его ведома — угроза, которую тяжело объявить неактуальной для сайта с личным кабинетом.
Какие защиты от CSRF действительно работают?
Ни одна мера не закрывает вопрос в одиночку. Рабочая конфигурация — несколько слоёв.
| Мера | Что делает | Ограничения |
|---|---|---|
| CSRF-токен в форме | Сервер кладёт в форму случайное значение, привязанное к сессии, и принимает запрос только с ним | Бесполезен при наличии XSS: чужой скрипт прочитает токен со страницы |
| Атрибут SameSite у сессионной cookie | При значении Lax браузер не отправляет cookie при кросс-сайтовых POST-запросах, при Strict — при любых переходах со стороннего сайта | Lax пропускает cookie при обычном переходе по ссылке, поэтому изменяющие GET-запросы и доверенные поддомены не закрывает |
| Только POST для изменяющих действий | Действие нельзя запустить переходом по ссылке или загрузкой картинки | Требует переделки старых интерфейсов с «ссылками-действиями» |
| Проверка заголовков Origin и Referer | Сервер отклоняет запрос с чужого источника | Заголовки могут отсутствовать; нужна аккуратная обработка пустого значения |
| Повторная аутентификация | Смена почты, телефона и пароля требует ввести текущий пароль или код | Заметна пользователю, поэтому применяется точечно |
| Корректный CORS | Сервер не разрешает кросс-доменные запросы с произвольных источников | Настройка «разрешить всё» превращает меру в её отсутствие |
| Короткая жизнь сессии | Уменьшает окно, в котором атака возможна | Не устраняет саму уязвимость |
Отдельная строка — флаги сессионной cookie: HttpOnly не даёт прочитать её скриптом, Secure запрещает передачу по незащищённому соединению. К CSRF они относятся косвенно, но без них любая другая мера обесценивается.
Как проверить свой сайт без пентеста?
Полноценная проверка — работа специалиста, но несколько вещей владелец сайта видит сам.
- Откройте форму в личном кабинете и посмотрите исходный код страницы. Скрытое поле с длинным случайным значением — признак, что токен есть. Полное отсутствие такого поля во всех формах — плохой знак.
- Проверьте свойства сессионной cookie в инструментах разработчика: должны быть HttpOnly, Secure и SameSite.
- Найдите действия, выполняющиеся по ссылке. Если удаление адреса или отписка срабатывают простым переходом по URL, это готовая точка для подделки запроса.
- Проверьте, требует ли смена почты и пароля ввода текущего пароля. Если нет — это первое, что нужно исправить, безотносительно CSRF.
- Спросите разработчика, какой механизм защиты используется. У современных фреймворков он встроен, но у самописных кабинетов и старых шаблонов CMS часто отключён «чтобы не мешал».
- Проверьте, включена ли в CMS регистрация действий пользователей — без журнала вы не установите, когда и откуда менялись контакты в профиле.
Пункты 1–4 занимают около получаса, если доступ к сайту у вас есть; пункты 5 и 6 зависят от разработчика и от того, как настроена CMS.
Чем CSRF отличается от XSS и что тут делает CSP?
Эти три аббревиатуры постоянно смешивают, а меры у них разные.
| CSRF | XSS | |
|---|---|---|
| Суть | Действие от имени пользователя | Выполнение чужого кода на вашей странице |
| Что использует | Доверие сервера к сессии | Доверие браузера к вашему домену |
| Читает ли данные | Нет, действует вслепую | Да, включая содержимое форм |
| Основная защита | Токен, SameSite, проверка источника | Экранирование вывода, Content Security Policy |
Content Security Policy — инструмент против XSS и против утечки данных из форм на сторонние домены; на подделку межсайтового запроса он почти не влияет. Как этот заголовок настраивается и что именно он закрывает, разобрано в статье «Content Security Policy: как заголовок защищает персональные данные».
Отсюда практический вывод о порядке работ: закрывать сначала XSS, затем CSRF, а не наоборот — пока на странице может выполниться чужой скрипт, токен ему не помеха.
Какие ошибки встречаются чаще всего?
- Токен есть, но сервер его не проверяет. Поле выводится в форму, а обработчик принимает запрос и без него — частый результат быстрой правки «чтобы заработало».
- Один токен на всех пользователей или токен, не привязанный к сессии: формально мера есть, практически её нет.
- Изменяющие действия через GET — наследие старых админок.
- CORS, настроенный «разрешить любой источник» ради интеграции, которую давно отключили.
- Защита есть в основном приложении, но не в API, к которому ходит мобильное приложение или личный кабинет на JavaScript.
- Нет журнала действий, поэтому подмену контактов невозможно ни заметить, ни расследовать. Что минимально нужно логировать, собрано в статье «Расследование утечки персональных данных».
С чего начать
Безопасность личного кабинета — внутренняя работа, и снаружи её не видно. Зато снаружи прекрасно видно другое: какие формы собирает сайт, какие сторонние скрипты работают на страницах с этими формами, открывается ли политика обработки и совпадает ли она с реальным составом данных. Это те же нарушения, которые первыми находит автоматизированный мониторинг Роскомнадзора, и начинать разумно с них — они дешевле и закрываются быстрее.
Бесплатный скан на rkn-ok.ru проверит внешний контур за 30 секунд, а защиту от подделки запроса поставьте в задачу разработчику вместе со списком из раздела выше.
→ Проверить сайт на нарушения 152-ФЗ (бесплатно, 30 секунд)
Что читать дальше
- Content Security Policy: как заголовок защищает персональные данные — соседняя мера против другой атаки
- Приказ ФСТЭК №21 для владельца сайта — откуда берутся группы мер
- Резервное копирование персональных данных — восстановление данных как требование статьи 19 152-ФЗ
- Как обнаружить утечку персональных данных — что делать в первые 24 часа
- Подзаконные акты к 152-ФЗ — полный список действующих требований
Источники: Федеральный закон №152-ФЗ «О персональных данных» — статьи 19, 21; постановление Правительства №1119 от 01.11.2012; приказ ФСТЭК №21 от 18.02.2013.