В предыдущей статье я писал об общении по поводу кибербезопасности. В этой статье мы вернемся к техническим деталям и поговорим о подделке межсайтовых запросов или CSRF.

Часть 10. Подделка межсайтовых запросов

Подделка межсайтовых запросов (CSRF) — это один из векторов атаки, о котором веб-разработчики, как правило, знают больше всего. Частично это, конечно, связано с тем, что разработчику приходится прилагать особые усилия для предотвращения CSRF-атак. Помимо защиты от CSRF, включенной в библиотеки и фреймворки, во многих сценариях разработчики должны сами выбирать и реализовывать метод защиты от CSRF. Вот почему я хотел бы обсудить с вами основы этой уязвимости.

Политика того же происхождения

Я уже много писал о SOP в своей статье о XSS. Как оказалось, эта политика также играет роль в понимании атак с подделкой межсайтовых запросов. Посетите эту статью для обзора, если вы не уверены, как работает политика того же происхождения.

основы CSRF

Как следует из названия, подделка межсайтовых запросов — это атака, при которой злоумышленник заставляет пользователя отправлять нежелательные запросы. Межсайтовая часть относится к наиболее распространенному способу осуществления этой атаки. Пользователь посещает вредоносный сайт, что дает злоумышленнику, подготовившему сайт, возможность отправлять запросы на целевой сайт с помощью браузера жертвы. Но, конечно, есть и другие способы заставить пользователей отправлять нежелательные запросы, например, с помощью фишинговых атак. В зависимости от вашего определения, эти атаки могут быть включены в CSRF или могут считаться близкими родственниками атак CSRF.

Смысл CSRF, конечно, в том, что злоумышленники не могут сами отправлять соответствующие запросы. Вместо этого им нужно, чтобы пользователь выполнил это действие за них. В наиболее типичном сценарии пользователь входит в систему на каком-то внешнем веб-сайте, который не реализует методы смягчения CSRF. Если злоумышленник может обманом заставить пользователя отправить нежелательный запрос, браузер автоматически включит учетные данные, связанные с сайтом  — чаще всего сеансовые файлы cookie, хотя, возможно, для идентификации пользователя может использоваться и другая информация, например IP-адрес из белого списка. В любом случае это приводит к тому, что запрос связывается с учетной записью целевой жертвы, что может иметь последствия для этой жертвы.

Поскольку ответ атаки CSRF обычно не доходит до злоумышленника, мотивация злоумышленника должна быть связана с выполнением самого запроса. Обычно это означает, что запрос приводит к изменению некоторого состояния по запросу, например к публикации нежелательного сообщения в учетной записи жертвы в социальной сети.

Исключением из этого правила являются формы входа. Если злоумышленник может заставить пользователя выполнить запрос на вход на уязвимый веб-сайт, он может войти в систему этого пользователя с учетной записью, контролируемой злоумышленником. Мы называем этот вариант атаки логином CSRF. Если у жертвы создается впечатление, что они вошли в свою учетную запись, они могут ввести личную информацию в учетную запись, контролируемую злоумышленником, и передать эту информацию злоумышленнику.

По этой причине важно также включить защиту CSRF в формы входа. К сожалению, защита CSRF в формах входа часто упускается из виду, поскольку последствия для безопасности не так очевидны, а также потому, что многие веб-сайты полагаются на токены CSRF для смягчения атак. Такие токены должны быть связаны с сеансом пользователя, чтобы они работали, но у пользователей, которые еще не вошли в систему, нет сеанса входа в систему, с которым можно связать токены. Это сбивает с толку разработчиков, заставляя их думать, что формы входа не могут быть защищены.

Следует помнить, что все формы, включая формы входа, являются вектором атаки для CSRF, и что токены CSRF могут быть связаны с любыми сессиями, а не только с сессиями входа. Если вы предоставляете файл cookie сеанса всем новым пользовательским агентам, посещающим ваш сайт, у которых его еще нет, вы можете связать токены CSRF с этим сеансом и включить их в формы входа до входа пользователя в систему. В качестве альтернативы вы можете использовать один из механизмы защиты без сохранения состояния, если ваш сайт предназначен для сохранения состояния.

Это самые основы CSRF. Далее давайте рассмотрим роль, которую политика одного и того же происхождения играет в CSRF.

Политика того же происхождения

В предыдущей статье я объяснял, как политика одного и того же источника защищает пользователей от утечки информации между сайтами, разрешая отправку запросов из разных источников, но предотвращая чтение ответов на эти запросы из разных источников. Поскольку запросы CSRF обычно полагаются на обрабатываемый запрос, а не на полученный ответ, политика единого источника не защищает приложения, которые полагаются на так называемые простые запросы. Кроме того, поскольку политика одинакового происхождения применяется только к JavaScript, она не защищает пользователей от вредоносных HTML-тегов, которые инициируют запросы, таких как тег ‹img› или теги привязки.

Если приложению требуется отправить непростой запрос для выполнения действий по изменению состояния, то запрос будет предварительно проверен, и целевому серверу будет предоставлена ​​возможность отклонить запрос до того, как он будет отправлен, если он исходит из другого сервера. источник. (Если простой запрос и предварительная проверка кажутся вам незнакомыми, я представил эти термины в одной из своих статей о XSS.) Таким образом, политика одного и того же происхождения может применяться в качестве метода защиты от CSRF.

Это может быть эффективным средством для смягчения атак CSRF. Хотя существует вариант CSRF, называемый хранимым CSRF, в котором вредоносный код, запускающий запрос CSRF, хранится на самом целевом веб-сайте (во многом аналогично хранимому XSS), этот вариант способен инициировать только простые запросы и, следовательно, также не будет работать на сайте, который полагается на предварительные запросы на изменение состояния. Потребуется полномасштабная сохраненная XSS-атака, чтобы обойти такую ​​защиту CSRF на основе CORS, выполняя запросы из того же источника, что и целевой веб-сайт. Но если злоумышленник может выполнить хранимую XSS-атаку, он сможет обойти и другие средства защиты CSRF, например, прочитав токены CSRF из DOM перед отправкой запросов формы.

Методы смягчения последствий

Для краткости я собираюсь перечислить наиболее распространенные методы смягчения последствий поименно и оставлю читателю в качестве упражнения изучить их особенности. Как всегда, OWASP является хорошей отправной точкой для изучения этих методов смягчения последствий.

  • Возможно, наиболее популярным методом смягчения последствий является шаблон маркера синхронизации, также известный как маркеры CSRF. Обратите внимание, что для этого требуется приложение с отслеживанием состояния, поскольку токены должны сохраняться таким образом, который связан с сеансами пользователя.
  • Метод двойной отправки файла cookie в последнее время набирает популярность и, по сути, предоставляет тот же метод, что и шаблон токена синхронизатора. Разница в том, что он хранит токен на клиенте в виде файла cookie, а не на сервере, а это означает, что приложения без сохранения состояния могут использовать этот метод.
  • Вышеупомянутый метод требования предварительных запросов является еще одной альтернативой. Один из распространенных способов инициировать предварительную проверку запросов — требовать запросы с заголовками, не включенными в список надежных отправителей. Обычно для этой цели используется настраиваемый заголовок. Этот метод может использоваться приложениями без сохранения состояния.
  • Атрибут файла cookie SameSite может помочь, но его следует рассматривать как дополнительный уровень безопасности. По сути, это предотвращает межсайтовое включение файлов cookie при настраиваемых обстоятельствах, ограничивая ущерб, который могут нанести межсайтовые запросы.
  • И последнее, но не менее важное: попробуйте использовать уже существующие библиотеки, если они вам доступны. Реализация собственной безопасности сложна и подвержена ошибкам.

Ежедневный совет:

CSRF и CORS могут быть довольно техническими и запутанными для менее опытных веб-разработчиков, но они очень присутствуют, и вам, несомненно, придется рассуждать о них на протяжении всей вашей карьеры. Если вы еще не привыкли рассуждать об этих методах, подумайте, не можете ли вы поставить их на первое место в своем списке дел, чтобы изучить их.

В следующей статье мы сосредоточимся более конкретно на политике одного и того же источника, поскольку она играет роль как в XSS, так и в CSRF.