Csrf что это
Перейти к содержимому

Csrf что это

  • автор:

Межсайтовая подделка запроса: защита от CSRF атак

CSRF — это вид атаки, позволяющий злоумышленнику выполнить запрос от лица пользователя. Рассказываем, как защититься от CSRF атак.

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

Обычно для этого пользователь должен перейти по мошеннической ссылке (которая может быть изменена с помощью сокращателя ссылок).

Например Джейн, авторизованная на сайте банка, проверяет свою почту. Она может перейти по фишинговой ссылке, которая включает запрос на перевод денег на аккаунт мошенника.

Благодаря тому, что она авторизована на сайте банка, тот обработает запрос на перевод.

Какие HTTP запросы подвержены CSRF атаке?

Методы GET, HEAD, OPTIONS и TRACE не подвержены CSRF, потому что предназначены только для получения информации и не изменяют состояние сервера.

Методы POST, PUT, DELETE и PATCH должны быть защищены от CSRF.

Cookies сессии

Cookies сессии — это способ, которым протокол HTTP отслеживает состояние. Веб-сайты используют cookies для идентификации пользователей и сохранения их данных.

После сохранения cookies, браузер отправляет их на сервер с каждым запросом, чтобы идентифицировать пользователя.

Злоумышленник может использовать cookies, чтобы выдать себя за пользователя, заставив браузер пользователя выполнить запрос.

Если пользователь уже вошел на сайт, cookies будут отправлены автоматически вместе с запросом.

Как работает межсайтовая подделка запросов?

Для того, чтобы злоумышленник осуществил атаку CSRF, нужны определённые условия:

  • В приложении есть действие, которое злоумышленник хочет предпринять – например, изменить пароль, перевести средства и так далее.
  • Не существует непредсказуемых параметров запроса – злоумышленник может угадать (или знать) все параметры, которые приложение ожидает увидеть из этого типа запроса.
  • Действие может быть выполнено с помощью HTTP-запросов, и оно полагается только на файлы cookie, чтобы убедиться, что запрос исходит от пользователя.

CSRF могут быть подвергнуты веб-приложения использующие cookies, браузерную аутентификацию или клиентские сертификаты авторизации. По сути, CSRF подвержены все веб-приложения, которые автоматически добавляют аутентификационные данные пользователя к запросу.

Либо нужно начать с того, что злоумышленник обманом заставит жертву загрузить или отправить информацию в веб-приложение. Это может произойти несколькими способами – например, через фишинговую ссылку.

Эксплойт может быть замаскирован под обычную ссылку или скрыт в теге изображения.

Вот пример атаки через обычную ссылку:

Или через тэг изображения:

Способы защиты от CSRF атак

Выбор защищённых фреймфорков

Используйте фреймворки, которые имеют встроенную защиту против CSRF, например .NET. Также важно правильно настроить фреймворк. Если ваш фреймворк не имеет защиты от CSRF вы можете использовать Anti-CSRF токены.

Anti-CSRF токены

Токены (или synchronizer token) – это способ защиты со стороны сервера. Сервер генерирует случайный уникальный токен для браузера пользователя и проверяет его для каждого запроса.

Токен находится в скрытом поле, должен быть непредсказуемым случайным числом и иметь небольшое время жизни, без возможности переиспользования.

Токен должен удовлетворять следующим условиям:

  • быть уникальным в пределах каждой операции;
  • использоваться один раз;
  • иметь размер устойчивый к подбору;
  • генерироваться криптографически стойким генератором псевдослучайных чисел;
  • иметь ограниченное время жизни.

Использование двух токенов

Смысл этого метода в том, что используются два токена: первый сохраняется в cookies, а второй — в одном из параметров ответа.

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

Использование флага Same-Site в сookies

Этот флаг помечает куки для определенного домена.

Таким образом проверяется источник запроса, и его не получится выполнить с мошеннического сайта.

Этот флаг поддерживает большинство браузеров. Его стоит использовать как часть общей стратегии защиты от CSRF атак.

Требуйте подтверждения от пользователя

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

CSRF

CSRF (cross-site request forgery, подделка межсайтовых запросов) — вид атак на сайт, при которой злоумышленник с помощью мошеннического сайта или скрипта заставляет браузер пользователя выполнять на доверенном сайте действия от его имени: отправлять сообщения, менять пароли, переводить деньги со счета на счет и пр. В атаке используются недостатки протокола HTTP.

Освойте профессию «Белый хакер»

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

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

Профессия / 13 месяцев
«Белый» хакер

Взламывайте ПО безнаказанно и за оплату

cables_2 2-PhotoRoom 1 (2)

Как работает межсайтовая подделка запросов

Разобраться, как работает межсайтовая подделка запросов, поможет понятие сессионных cookies (куки).

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

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

Для выполнения CSRF необходимы несколько условий:

  • на уязвимом сайте есть действие, которое хакер хочет выполнить от имени жертвы, например изменить адрес @mail, осуществить перевод денежных средств, изменить пароль и так далее;
  • злоумышленник заранее знает все параметры запроса, которые ожидает увидеть уязвимый сайт. Даже незначительное отличие в тексте повлияет на работоспособность;
  • действие полагается только на файлы cookies для верификации пользователя и выполняется с помощью HTTP-запросов.

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

Либо злоумышленник может обманом заставить жертву загрузить или отправить информацию. Например, через фишинговую ссылку.

Она может быть скрыта в теге изображения:

Или замаскирована под обычную ссылку:

Станьте специалистом
по кибербезопасности – научитесь отражать кибератаки и поддерживать безопасность любых IT-систем

Как защитить сайт от CSRF-атак

Некоторые фреймворки имеют встроенную защиту от CSRF-атак. Например .NET или Laravel. Если ее нет, можно использовать следующие способы.

SOP

SOP (same-origin policy, политика одинакового источника) определяет то, как именно скрипт или документ, который загружен из оригинального источника (origin), будет взаимодействовать с ресурсом, загруженным из другого источника. Две страницы имеют одинаковый источник, если у них совпадают хост (host), порт (port) и протокол (http или https). Часто можно встретить также запись вида scheme/host/port tuple. Это позволяет изолировать документы, которые могут нанести вред, и снизить количество вероятных векторов атак.

Токены CSRF

CSRF-токены (или anti-CSRF-токены) напоминают cookies. Это такие же данные, которые сервер отправляет браузеру в ожидании получить их обратно, но отличие в следующем: сервер должен отправить браузеру уникальный токен и проверить, присылает ли его браузер в ответ в запросе. Если токены совпадают, запрос действителен, если нет — отклоняется.

Токен должен удовлетворять требованиям:

  • иметь конечное время жизни;
  • генерироваться с использованием криптографии генератором псевдослучайных чисел;
  • иметь такую длину, чтобы быть устойчивым к перебору;
  • использоваться только один раз.

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

Флаг Same-Site Cookies

Метод похож на использование SOP. Отличие в том, что флаг Same-Site помечает куки для одного доменного имени. В результате источник запроса подвергается проверке. Считается, что cookies и источник запроса имеют одинаковое происхождение, если протокол, порт (если применимо) и хост (но не IP-адрес) одинаковы для обоих. Таким образом не получится отправить запрос с мошеннического сайта. Флаг поддерживает подавляющее большинство современных браузеров, и его использование является хорошей практикой в стратегии защиты.

Подтверждение действий от пользователя

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

«Белый» хакер

Научитесь защищать информационные системы: проводить атаки, анализировать программы и искать в них уязвимости. Станьте востребованным специалистом и работайте из любой точки мира.

Безопасность в деталях: исследование cистемы защиты от CSRF

Атаку, при которой хакер пытается выполнить авторизованный запрос на вашем сайте, используя доступ, предоставленный пользователем, называют CSRF-атакой (cross-site request forgery – межсетевая подделка запроса). Это огромная проблема для любой платформы (и особенно финтех) с многотысячной аудиторией.

Меня зовут Алексей, я разработчик команды Платформа Банки.ру Я занимаюсь, в частности, разработкой новой платформы на node.js, на которую у нас сейчас переезжают многие сервисы. Ниже я подробно расскажу о том, как мы искали самый надежный способ защиты от CSRF-атак, чем руководствовались при выборе решения и как его реализовали.

Что такое CSRF атака

Итак, при csrf-атаке хакер пытается выполнить авторизованный запрос через доступ пользователя. Например, пользователь переходит по ссылке из письма, а злоумышленник в это время отправляет запрос на наш сервер, применяя пользовательские куки. Это запрос интерпретируется как действие пользователя.

Способы защиты от CSRF

Есть несколько способов защиты от CSRF. Вот что рекомендует OWASP (The Open Web Application Security Project) – организация, специализирующаяся на исследованиях веб-безопасности:

  1. Инициализация CSRF-токенов. Этот метод считается наиболее рекомендуемым. CSRF-токен — это ключ, выдаваемый пользователю для определенных действий.
  2. Ограничение кук. Это означает использование специальных атрибутов кук, чтобы браузер мог отправлять их только на наш домен и поддомены.
  3. Использование нестандартных заголовков. Этот подход предполагает ограничение использования доменов, с которых могут быть отправлены запросы.
  4. Валидация заголовков origin. Здесь проверяется совпадение между источником (source) и целью (target) нашего заголовка origin.

У каждого из перечисленных методов есть свои ограничения.

Поэтому наиболее универсальным и эффективным способом защиты все-таки является первый — инициализация CSRF-токена — то есть подписание пользователя и предоставление прав на действия только подписанному пользователю.

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

Мы подписываем этим токеном действия, которые могут изменить сервер (например, POST, PUT, DELETE), и рассматриваем их как доверенные.

Если злоумышленник попытается сделать запрос на сервер без этого токена, его действия будут заблокированы, и он не сможет выполнить нежелательные операции.

Стоит учитывать, что методы GET/HEAD/OPTIONS не должны изменять серверную часть. В противном случае мы сами закладываем уязвимости, от которых одним наличием CSRF-токена не защититься.

О csurf-библиотеке

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

Согласно результатам поиска, наиболее популярным вариантом реализации защиты от CSRF-атак является использование пакета csurf. Практически каждая статья на эту тему рекомендует этот пакет.

Что такое csurf? Это библиотека, разработанная Express.js для защиты от CSRF-атак.

В тот день, когда мы приступили к поиску решения, выяснилось, что 5 дней назад библиотека csurf была заархивирована.

А случилось это по той причине, что сама библиотека csurf содержит уязвимости к CSRF-атакам. Это создает абсурдную ситуацию, когда инструмент, разработанный для защиты от CSRF, оказывается несостоятельным и не может соответствовать требованиям безопасности, которые он предполагает обеспечивать пользователям.

В статье по ссылке можно почитать об этом подробнее.

Мы вынуждены были искать какие-то другие решения.

На картинке ниже видно, что сам пакет csurf нам предлагал попробовать поискать реализации для express.js CSRF — защиты самостоятельно в менеджере пакетов npm.

На этом этапе мы поняли, что помимо архивированной библиотеки csurf по сути не существует ни одного адекватного решения. Самый популярный пакет в этой выборке отмечен максимум 10-20 звёздами на гитхабе.

Альтернатив по сути не оказалось.

Как мы выходили из замкнутого круга

Итак, мы убедились, что готового решения для нашей задачи нет. Значит, нам надо будет самостоятельно придумывать эту защиту на уровне нашего сервера.

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

Токен должен быть:

  • Уникальным
  • Единоразовым
  • Обладать устойчивым к подбору размером.
  • Сгенерированным криптостойким генератором чисел.
  • Ограниченным по времени жизни.

Это базовые принципы для нашего CSRF-токена, по которым мы стали его создавать.

Дальше расскажу, каким образом у нас действует CSRF-защита.

Инициализация CSRF-токена

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

Следующий шаг после инициализации токена и передачи его пользователю — это валидация.

Валидация токена

Когда пользователь отправляет запросы, наш сервер проверяет переданный токен. Схема такова: клиент передает токен, сервер проверяет его, хэширует и сравнивает с сохраненным. Если токены совпадают, действие разрешено. В противном случае запрос отклоняется как невалидный.

Где хранить токен

Теперь возникает вопрос: где можно сохранить токен? Существует два варианта реализации защиты от CSRF на сервере:

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

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

Второй подход, популярный в мире JavaScript, — это Stateless решение, известное как паттерн Double Submit Cookie. Здесь пользователь сохраняет хешированный и соленый токен в куки после его генерации. Пользователь, обладая как куками, так и самим токеном, может выполнять действия на сервере. При проверке мы извлекаем куку, берем токен, хешируем и солим, а затем сравниваем его с переданным кукой. Этот метод удобен для хранения.

Реализация

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

Начнем с инициализации токена. Наш сервер создает токен, затем мы его хешируем, солим и сохраняем в cookie.

На сервере контроллер генерирует страницу и инициализирует сессию. Эта инициализация, по сути, равна размещению хэшированного соленого токена в куки.

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

Когда клиент отправляет запрос, наша утилита извлекает токен из мета-тега страницы, который клиент получил. Затем мы отправляем запрос через proxy-сервер, выполняя валидацию этого токена.

Отправляем запрос с CSRF-токеном из meta-тега в HTTP-заголовке.

На последнем этапе валидации, прокси-сервер (нода) выполняет блок валидации, о котором мы говорили ранее.

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

Критика решения

Ну и в заключение расскажу о возможных проблемах или узких местах.

1. Работа с WebView и . Если мы вставляем наш сайт в мобильное приложение или на страницу другого сайта, одной из проблем может быть ограничение передачи куков нашего сайта к другому сайту. Для решения этой проблемы, нам может потребоваться разрешить проброс куков не только на нашем домене. Куки должны быть установлены с флагом http-only и передаваться только через безопасное соединение. Если мы инжектируем контент только в доверенные клиенты, мы можем ожидать, что это уровень безопасности будет удовлетворительным.

2. Защита от XSS атак. XSS (Cross Site Scripting) — это атаки, при которых злоумышленники внедряют на наш сайт вредоносные скрипты, выполняющие действия от имени пользователя. Эта атака считается одной из самых опасных, но практически все современные фреймворки по умолчанию предоставляют защиту от нее. Наличие React на фронтенде вашего приложения в значительной степени обеспечивает эту защиту. Однако, хотя React и другие фреймворки и предоставляют базовую защиту, важно помнить о возможных узких местах в безопасности и следить за обновлениями для обеспечения надежной защиты.

Итоги

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

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

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

  • csrf
  • информационная безопасность

Атака CSRF

Материал на этой странице устарел, поэтому скрыт из оглавления сайта.

Нельзя говорить про AJAX и не упомянуть про важнейшую деталь его реализации – защиту от CSRF-атак.

CSRF (Cross-Site Request Forgery, также XSRF) – опаснейшая атака, которая приводит к тому, что хакер может выполнить на неподготовленном сайте массу различных действий от имени других, зарегистрированных посетителей.

Какие это действия – отправка ли сообщений, перевод денег со счёта на счёт или смена паролей – зависят от сайта, но в любом случае эта атака входит в образовательный минимум веб-разработчика.

Злая форма

«Классический» сценарий атаки таков:

  • Вася является залогиненным на сайт, допустим, mail.com . У него есть сессия в куках.
  • Вася попал на «злую страницу», например хакер пригласил его сделать это письмом или как-то иначе.
  • На злой странице находится форма такого вида:

Итог атаки – Вася, зайдя на злую страницу, ненароком отправил письмо от своего имени. Содержимое письма сформировано хакером.

Защита

В примере выше атака использовала слабое звено авторизации.

Куки позволяют сайту mail.com проверить, что пришёл именно Вася, но ничего не говорят про данные, которые он отправляет.

Иначе говоря, куки не гарантируют, что форму создал именно Вася. Они только удостоверяют личность, но не данные.

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

Разумеется, для разных посетителей secret будет разным.

Затем на основе ключа генерируется «токен» ( token ). Токен делается так, чтобы с одной стороны он был отличен от ключа secret , в частности, может быть много токенов для одного ключа, с другой – чтобы было легко проверить по токену, сгенерирован ли он на основе данного ключа или нет.

Для этого для каждого токена используется дополнительное случайное значение, которое называют «соль» salt .

Формула вычисления токена:

token = salt + ":" + MD5(salt + ":" + secret)
  1. В сессии хранится secret=»abcdef» , это значение создаётся один раз.
  2. Для нового токена сгенерируем salt , например пусть salt=»1234″ .
  3. token = «1234» + «:» + MD5(«1234» + «:» + «abcdef») = «1234:5ad02792a3285252e524ccadeeda3401» .

Это значение – с одной стороны, случайное, с другой – получив такой token от пользователя, мы можем его проверить: разбить по символу двоеточия, взять его левую часть 1234 в качестве salt и, зная secret , запустить вычисление по формуле выше. Если мы получили то же самое, то token правильный, это не хакер.

Обратим внимание: не зная secret , невозможно сгенерировать token , который сервер воспримет как правильный.

Далее, токен добавляется в качестве скрытого поля к каждой форме, генерируемой на сервере.

То есть, «честная» форма для отсылки сообщений, созданная на http://mail.com , будет выглядеть так:

При её отправке сервер проверит поле csrf , удостоверится в правильности токена, и лишь после этого отошлёт сообщение.

«Злая страница» при всём желании не сможет сгенерировать подобную форму, так как не владеет secret , и токен будет неверным.

Такой токен также называют «подписью» формы, которая удостоверяет, что форма сгенерирована именно на сервере.

Подпись с полями формы

Эта подпись говорит о том, что автор формы – сервер, но ничего не гарантирует относительно её содержания.

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

token = salt + ":" + MD5(salt + ":" + secret + ":" + fields.money)

При отправке формы сервер проверит подпись, подставив в неё известный ему secret и присланное значение fields.money . При несовпадении либо secret не тот (хакер), либо fields.money изменено.

Токен и AJAX

Теперь перейдём к AJAX-запросам.

Что если посылка сообщений в нашем интерфейсе реализуется через XMLHttpRequest?

Как и в случае с формой, мы должны «подписать» запрос токеном, чтобы гарантировать, что его содержимое прислано на сервер именно интерфейсом сайта, а не «злой страницей».

Здесь возможны варианты, самый простой – это дополнительная кука.

  1. При авторизации сервер устанавливает куку с именем CSRF-TOKEN , и пишет в неё токен.
  2. Код, осуществляющий XMLHttpRequest, получает куку и ставит заголовок X-CSRF-TOKEN с ней:

var request = new XMLHttpRequest(); var csrfCookie = document.cookie.match(/CSRF-TOKEN=([\w-]+)/); if (csrfCookie)

Защита действует потому, что прочитать куку может только JavaScript с того же домена. «Злая страница» не сможет «переложить» куку в заголовок.

Если нужно сделать не XMLHttpRequest, а, к примеру, динамически сгенерировать форму из JavaScript – она также подписывается аналогичным образом, скрытое поле или дополнительный URL-параметр генерируется по куке.

Итого

  • CSRF-атака – это когда «злая страница» отправляет форму или запрос на сайт, где посетитель, предположительно, залогинен. Если сайт проверяет только куки, то он такую форму принимает. А делать это не следует, так как её сгенерировал злой хакер.
  • Для защиты от атаки формы, которые генерирует mail.com , подписываются специальным токеном. Можно подписывать не все формы, а только те, которые осуществляют действия от имени посетителя, то есть могут служить объектом атаки.
  • Для подписи XMLHttpRequest токен дополнительно записывается в куку. Тогда JavaScript с домена mail.com сможет прочитать её и добавить в заголовок, а сервер – проверить, что заголовок есть и содержит корректный токен.
  • Динамически сгенерированные формы подписываются аналогично: токен из куки добавляется как URL-параметр или дополнительное поле.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *