Csrf токен: Методы защиты от CSRF-атаки / Хабр

Методы защиты от CSRF-атаки / Хабр

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

Ознакомиться с самой идеей атаки CSRF можно на классических ресурсах:

Выдержка из ответа на SO:

Причина CSRF кроется в том, что браузеры не понимают, как различить, было ли действие явно совершено пользователем (как, скажем, нажатие кнопки на форме или переход по ссылке) или пользователь неумышленно выполнил это действие (например, при посещении bad.com, ресурсом был отправлен запрос на good.com/some_action, в то время как пользователь уже был залогинен на good.com).

Как от нее защититься?

Эффективным и общепринятым на сегодня способом защиты от CSRF-Атаки является токен. Под токеном имеется в виду случайный набор байт, который сервер передает клиенту, а клиент возвращает серверу.

Защита сводится к проверке токена, который сгенерировал сервер, и токена, который прислал пользователь.

А что, собственно, защищать?

Если вы пишете свой Web-Сервис в соотвествии со стандартом RFC7231, то методы GET, HEAD, OPTIONS и TRACE являются безопасными: они предназначены только для получения информации и не должны изменять состояние сервера.

Таким образом, защищать необходимо небезопасные методы, к которым относятся: POST, PUT, DELETE, PATCH.

На Habrahabr опубликована статья от Yandex, в которой описано, почему писать свои сервисы нужно, руководствуясь стандартом.

Требования к токену:

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

На первом MeetUp’е PDUG Тимур Юнусов (руководитель отдела безопасности банковских

систем Positive Technologies) рассказывал, почему именно такие требования предъявляются к CSRF-Токену и чем грозит пренебрежение ими.

Требования к Web-Сервису и окружению:

• Отсутствие XSS уязвимостей

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

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

• Отсутствие malware на машине клиента

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

Методы защиты

Существует 3 метода использования токенов для защиты web-сервисов от CSRF атак:

Synchronizer Tokens

Простой подход, использующийся повсеместно. Требует хранения токена на стороне сервера.

Суть:

1. При старте сессии на стороне сервера генерируется токен.

2. Токен кладется в хранилище данных сессии (т.е. сохраняется на стороне сервера для последующей проверки)

3. В ответ на запрос (который стартовал сессию) клиенту возвращается токен.

   Если рендеринг происходит на сервере, то токен может возвращаться внутри HTML, как, например, одно из полей формы, или внутри <meta> тега.

   В случае, если ответ возвращается для JS приложения, токен можно передавать в header (часто для этого используют X-CSRF-Token)

4. При последующих запросах клиент обязан передать токен серверу для проверки.

   При рендере контента сервером токен принято возвращать внутри POST данных формы.

   JS приложения обычно присылают XHR запросы с header (X-CSRF-Token), содержащим токен.

5. При получения запроса небезопасным методом (POST, PUT, DELETE, PATCH) сервер обязан проверить на идентичность токен из данных сессии и токен, который прислал клиент.

   Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.

На выходе имеем:

• Защита от CSRF на хорошем уровне

• Токен обновляется только при пересоздании сессии, а это происходит, когда сессия истекает

  Во время жизни одной сессии все действия будут проверяться по одному токену.

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

• Бесплатная поддержка multi-tab в браузере.

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

Double Submit Cookie

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

Идея в том, чтобы отдать токен клиенту двумя методами: в куках и в одном из параметров ответа (header или внутри HTML).

Суть:

1. При запросе от клиента на стороне сервера генерируется токен. В ответе токен возвращается в cookie (например, X-CSRF-Token) и в одном из параметров ответа (в header или внутри HTML).

2. В последующих запросах клиент обязан предоставлять оба полученных ранее токена. Один как cookie, другой либо как header, либо внутри POST данных формы.

3. При получении запроса небезопасным методом (POST, PUT, DELETE, PATCH) сервер обязан проверить на идентичность токен из cookie и токен, который явно прислал клиент.

   Если оба токена совпадают, то запрос не подвергся CSRF-Атаке, в ином случае — логируем событие и отклоняем запрос.

На выходе имеем:

• Stateless CSRF защиту.

• Необходимо учитывать, что поддомены могут читать cookie основного домена, если явно это не запрещать (т.е. если cookie установлена на .site.ru, то её могут прочитать как a.site.ru, так и b.site.ru).

  Таким образом, если ваш сервис доступен на домене 3-го уровня, а злоумышленник имеет возможность зарегистрировать свой ресурс на вашем домене 2-го уровня, то устанавливайте cookie на свой домен явно.

• Нюансы зависят от реализации

Encrypted Token

Так же как и Double Submit, является Stateless подходом. Основная — если вы зашифруете надежным алгоритмом какие-то данные и передадите их клиенту, то клиент не сможет их подделать, не зная ключа. Этот подход не требует использования cookie. Токен передаётся клиенту только в параметрах ответа.

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

Суть:

1. При запросе от клиента на стороне сервера генерируется токен.

   Генерация токена состоит в зашифровке фактов, необходимых для валидации токена в дальнейшем.

   Минимально необходимые факты — это идентификатор пользователя и timestamp. В ответе токен возвращается в одном из параметров ответа (В header или внутри HTML).

2. В последующих запросах клиент обязан предоставлять полученный ранее токен.

3. При получения запроса небезопасным методом (POST, PUT, DELETE, PATCH) сервер обязан валидировать токен, полученный от клиента.

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

   Если расшифровать не удалось либо факты не совпадают, считается, что запрос подвергся CSRF-Атаке.

На выходе имеем:

О реализации

• Давайте генерировать новый токен на каждый запрос, не важно, каким HTTP-методом и с какой целью этот запрос сделан.

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

  Конечно, возникает вопрос организации multi-tab работы.

  Синхронизация токенов между табами может быть реализована с использованием localStorage и его StorageEvent

• Ограничиваем время жизни cookie, которое содержит токен, разумным значением. Например 30 минут.

• Делаем cookie недоступной из JS (ставим HTTPOnly=true)

• Используем TLS для предотвращения MITM

  При этом отправляем cookie только по HTTPS (ставим Secure=true)

• Размер токена не менее 32 байт.

• Генерируем токен криптографически стойким генератором псевдослучайных чисел.

  Для этого можно использовать системные функции:

  Linux => getrandom(2) если возможно, /dev/urandom иначе
  OpenBSD => getentropy(2)
  На других Unix-like системах => /dev/urandom
  Windows => CryptGenRandom API

Что еще нужно знать?

Токены — обязательная защита от CSRF.

• Проверяйте, но не полагайтесь только на X-Requested-With: XMLHttpRequest

• Проверяйте, но не полагайтесь только на заголовки: Host, Origin, Referer

• Не передавайте токены в URL

• Защищайте все запросы.

Same Site

Сейчас идет работа над спецификацией атрибута «Same-Site» у cookies (последняя версия на момент написания статьи).

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

Браузер Chrome уже сейчас поддерживает эту возможность.

Чуть больше информации о том, как и почему доступно на Stack Exchange.

PHP — Что такое токен CSRF? Каково его значение и как оно работает?

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

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

205

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

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

58

Позволь мне привести пример…

Представьте, что у вас есть веб-сайт, похожий на упрощенный Twitter, размещенный на a.com. Пользователи, вошедшие в систему, могут вводить некоторый текст (твит) в форму, которая отправляется на сервер в виде запроса POST и публикуется при нажатии кнопки отправки. На сервере пользователь идентифицируется cookie-файлом, содержащим его уникальный идентификатор сеанса, поэтому ваш сервер знает, кто опубликовал твит.

Форма может быть такой простой:

 <form action="http://a.com/tweet" method="POST">
<input type="text" name="tweet">
<input type="submit">
</form>

А теперь представьте, что плохой парень копирует и вставляет эту форму на свой вредоносный веб-сайт, скажем, на b.com. Форма все еще будет работать. Пока пользователь входит в ваш Твиттер (т. Е. У него есть действительный файл cookie сеанса для a.com), запрос POST будет отправляться на http://a.com/tweet и обрабатывается как обычно, когда пользователь нажимает кнопку отправки.

Пока что это не большая проблема, если пользователь знает о том, что именно делает форма, но что если наш плохой парень подправит форму следующим образом:

 <form action="https://example.com/tweet" method="POST">
<input type="hidden" name="tweet" value="Buy great products at
http://b.com/#iambad">
<input type="submit" value="Click to win!">
</form>

Теперь, если один из ваших пользователей попадает на сайт злоумышленника и нажимает кнопку «Нажмите, чтобы выиграть!», Форма отправляется на ваш сайт, пользователь правильно идентифицируется по идентификатору сеанса в файле cookie, и скрытый твит получает опубликован.

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

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

Еще хуже, если ваше веб-приложение не различает запросы POST и GET (например, в PHP с использованием $ _REQUEST вместо $ _POST). Не делай этого! Запросы на изменение данных могут быть представлены так же просто, как http://a.com/tweet?tweet=This+is+really+bad, встроенный в вредоносный сайт или даже электронную почту.

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

    <form action="https://example.com/tweet" method="POST">
<input type="hidden" name="csrf-token"value="nc98P987bcpncYhoadjoiydc9ajDlcn">
<input type="text" name="tweet">
<input type="submit">
</form>

Когда пользователь отправляет форму, сервер просто должен сравнить значение отправленного поля csrf-token (имя не имеет значения) с токеном CSRF, запомненным сервером. Если обе строки равны, сервер может продолжить обработку формы. В противном случае сервер должен немедленно прекратить обработку формы и ответить ошибкой.

Почему это работает?
Есть несколько причин, по которым злоумышленник из нашего примера не может получить токен CSRF:

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

Поскольку вредоносная страница злоумышленника загружается браузером вашего пользователя из другого домена (b.com вместо a.com), у злоумышленника нет шансов написать код JavaScript, который загружает контент и, следовательно, текущий токен CSRF нашего пользователя из Ваш сайт. Это связано с тем, что веб-браузеры по умолчанию не разрешают междоменные запросы AJAX.

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

Когда следует защищать от подделки межсайтовых запросов?
Если вы можете быть уверены, что не смешиваете GET, POST и другие методы запросов, как описано выше, хорошим началом будет защита всех запросов POST по умолчанию.

Вам не нужно защищать запросы PUT и DELETE, потому что, как описано выше, стандартная HTML-форма не может быть отправлена ​​браузером с использованием этих методов.

С другой стороны, JavaScript действительно может делать другие типы запросов, например, используя функцию jQuery $ .ajax (), но помните, что для работы запросов AJAX домены должны совпадать (если в противном случае вы явно не настроили свой веб-сервер).

Это означает, что часто вам даже не нужно добавлять токен CSRF в запросы AJAX, даже если они являются запросами POST, но вам нужно будет убедиться, что вы обходите проверку CSRF только в своем веб-приложении, если запрос POST на самом деле AJAX запрос. Вы можете сделать это, посмотрев на наличие заголовка, такого как X-Requested-With, который обычно включают в себя запросы AJAX. Вы также можете установить другой пользовательский заголовок и проверить его наличие на стороне сервера. Это безопасно, потому что браузер не будет добавлять пользовательские заголовки к обычной отправке формы HTML (см. Выше), поэтому у мистера Бад Гая нет шансов смоделировать это поведение с помощью формы.

Если у вас есть сомнения по поводу запросов AJAX, поскольку по какой-то причине вы не можете проверить заголовок, такой как X-Requested-With, просто передайте сгенерированный токен CSRF в свой JavaScript и добавьте токен в запрос AJAX. Есть несколько способов сделать это; либо добавьте его в полезную нагрузку, как обычная форма HTML, либо добавьте пользовательский заголовок в запрос AJAX. Пока ваш сервер знает, где искать его во входящем запросе и может сравнить его с исходным значением, которое он запоминает из сеанса или файла cookie, вы будете отсортированы.

9

CSRF / Блог компании Акрибия / Хабр

Не смотря на то, что в последнем публиковавшемся перечне уязвимостей OWASP Top 10 2017 CSRF атаки отнесены к разряду “Удалены, но не забыты”, мы решили, что не будет лишним еще раз напомнить о том, как защититься от CSRF атак, опираясь на те же правила, предоставляемые OWASP.

Использование CSRF токена

Использование токена (как stateless, так и statefull методов) является первичным и самым популярным способом защиты. Токен должен быть уникален для каждой пользовательской сессии, сгенерирован криптографически стойким генератором псевдослучайных чисел. OWASP при этом рекомендует для шифрования использовать алгоритм AES256-GCM и SHA256/512 при использовании HMAC.

Существует несколько подходов к работе с токенами: Synchronizer Token, Encryption based Token Pattern, HMAC Based Token

Synchronizer Token

При использовании подхода Synchronizer Token (statefull метод) подразумевается отправка токена при каждом запросе, подразумевающем какие-то изменения на стороне сервера. Если токен не является валидным, то сервер отклоняет запрос.

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

<form action="/post.php" method="post">

<input type="hidden" name="CSRFToken" value="l5824xNMAYFesBxing975yR8HPJlHZ">
...
</form>

в заголовках:

POST /page HTTP/1.1
Accept: application/json, application/xml, text/json, text/x-json, text/javascript,
text/xml
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
Content-Type: application/json
Host: example.com
X-CSRF-TOKEN: l5824xNMAYFesBxing975yR8HPJlHZ

или в куках

POST /page HTTP/1.1
Host: example.com
Set-Cookie: CSRFToken=l5824xNMAYFesBxing975yR8HPJlHZ;
Content-Type: application/x-www-form-urlencoded

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

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

Отправка токена, используя GET запрос, не рекомендуется, так как при таком подходе токен может быть раскрыт: в истории браузера, лог файлах, referrer заголовках.

Encryption based Token

Данный подход является stateless, так как использует шифрование/дешифрование для валидации токена, а значит не требует хранения токена на стороне сервера.

Сервер генерирует токен, состоящий из идентификатора сессии и timestamp (для предотвращения атаки повторного воспроизведения). Для шифрования рекомендуется использовать алгоритм шифрования AES256 в режиме блочного шифрования GSM/GSM-SIV. Использование режима ECB строго не рекомендуется. Зашифрованный сервером токен возвращается клиенту так же, как и в случае с «Synchronizer Token» в скрытом поле формы или же в заголовке/параметре ответа. При получении токена сервер должен расшифровать его, после чего сверить идентификатор сессии, а также сверить timestamp с текущим временем и убедиться, что оно не превышает установленного времени жизни токена.

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

HMAC Based Token


Также не требует хранения токена, принцип работы похож на Encryption based Token, за исключением того, что вместо шифрования токена используется HMAC (hash-based message authentication code) функция для генерации токена (рекомендуется использовать SHA256 или более сильный алгоритм). При этом токен представляет из себя результат HMAC функции от идентификатора сессии пользователя+ timestamp.

Автоматизация работы с токенами

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

• напишите обертку, автоматически добавляющую токен к запросам через тег form или при использовании ajax. Например, Spring Security использует подобный подход каждый раз, когда используется тег <form:form>

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

• автоматически добавлять токен при рендере страницы. Данный подход используется CSRF Guard: токены добавляются ко всем href и src атрибутам, скрытым полям и во все формы

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

Login CSRF

Воспользовавшись CSRF в форме входа, злоумышленник может войти в систему,

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

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

Samesite Cookie

SameSite Cookie – атрибут, описанный в RFC6265bis, цель которого – противодействие CSRF атакам. Работает это следующим образом. Один из способов защиты – проверка заголовков origin и referer, по которым можно понять откуда пришел запрос, но такой подход требует внедрения механизма проверки. Используя атрибут SameSite, мы ограничиваем отправку куки с запросом с посторонних ресурсов. У данного атрибута есть несколько возможных значений: Strict, Lax и None.

Использование значения strict подразумевает, что браузер не будет отправлять куки с любых источников, не совпадающих с доменным именем текущего ресурса.

Значение lax дает возможность не блокировать куки с внешних ресурсов, переход с которых был осуществлен безопасным способом – по протоколу HTTPS. Lax обеспечивает баланс между удобством использования ресурса для пользователей и безопасностью.

Выставить атрибут довольно просто:

Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict
Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax

На момент написания статьи поддержка атрибута браузерами выглядит вот так:

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

Проверка заголовков

Как уже упоминалось выше, один методов защиты – проверка значений referrer и origin заголовка запроса.

Суть данной проверки сводится к проверке значений заголовков на стороне сервера. Если они совпадают с ресурсом, то запрос считается корректным, в противном случае отклоняется. Если заголовок Origin отсутствует, то нужно убедиться, что значение Referrer соответствует текущему ресурсу. OWASP рекомендует отклонять запросы, которые не содержат Origin или Referrer заголовки. Также можно логгировать все подобные запросы, чтобы после проанализировать их и принять решение о том как с ними поступать.

Однако все усложняется, если ваше приложение находится за прокси-сервером, поскольку URL в заголовке при этом будет отличаться. В таком случае есть несколько вариантов:

• сконфигурируйте ваше приложение таким образом, чтобы всегда знать происхождение запроса. Проблема подобного подхода заключается в установке правильного значения, если ваше приложение развернуто на нескольких окружениях (например, dev, QA, production), что приводит проблеме поддержки

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

• используйте заголовок X-Forwarded-Host, цель которого — хранение исходных заголовков, полученных прокси-сервером

Все описанные методы работают только тогда, когда присутствуют заголовки origin и referer. Но встречаются случаи, когда данные заголовки отсутствуют. Вот ряд случаев, когда эти заголовки не включаются в запрос:

• IE 11 не включается заголовок Origin для доверенных сайтов. Остается полагаться только на заголовок Referer

• в случае перенаправления Origin не включен в запрос, так как считается, что он может содержать конфиденциальную информацию, которую не следует отправлять другому источнику

• заголовок Origin включен для всех межсайтовых запросов, но большинство браузеров добавляют его только для POST/DELETE/PUT запросов

Как правило, незначительное количество трафика попадает под описанные категории, но часто не хочется терять даже эту малую часть пользователей, поэтому принято считать валидным запрос со значением null для origin/referrer или со значением, соответствующим списку доверительных доменов.

Double Submit Cookie


Данный подход довольно прост в реализации и не требует хранения токена на стороне сервера (stateless). Суть метода заключается в отправке пользователем токена в параметре запроса и в куках. Каждый запрос, требующий изменения состояния, сверяем значение токена в куках и в запросе. Если сверка идентификатора сессии проходит успешно, а timesmap – нет, то запрос может считаться валидным

По какому принципу работает CSRF Token защита и чем она отличается от Api Token? — Хабр Q&A

Здравствуйте, подскажите пожалуйста, в чем смысл защиты от CFRF в виде токена (насколько я понимаю — это позволяет даже от капчи отказаться), если это по сути уникальный код, который существует только на сервере для данного sessid?

Клиент спрашивает у сервера страницу
Сервер стартует сессию, отправляет юзеру sessid, создает токен, у себя сохраняет токен
Клиент спрашивает у сервера другую страницу
Сервер по его sessid вытаскивает из сессии его токен и запихивает в header ??? так это же пользователь токен в открытом виде заголовок получит, и толку тогда с такого токена? (в этом как бы месте википедия оставляет дыру, путая понятия «отправить заголовок» и «получить заголовок») — если мы при отдаче результата выставим заголовок, то это клиент получит Токен, сервер уже получил sessid и ему токен не впал три раза.

А по задумке этой защиты клиент свой токен получать не должен, все должно работать без него, поскольку:
а) заставить бабушку Нину вводить 64 значный буквенно цифровой токен — это продажи сразу в ноль
б) передача любых конфиденциальных данных пользователю без шифрования означает что любой человек, посмотрев ролик на ютубе и взяв ноутбук с линуксом получает пакет с токеном и становится юзером на раз-два
в) хранить токен в куках? зачем? там и так лежит sessid уникальность которого поддерживается на уровне сервера и его подменить нельзя оказалось можно

Я бы понял токеном защищать от запроса от имени калькулятора, но каким образом к форме токен привязать, если клиент в этом процессе участвует только своей сессией, а сервер дальше сам себе что-то там фантазирует?

Вот при защите API, к которому будут обращаться коробки разные с железяками, тут один запрос тебе по имени-паролю выдает Токен, который ты сознательно копируешь и вставляешь в код в заголовок, который ты отправляешь серверу, при SSL/TLS его не расшифровать в обозримых по времени пределах, и потому это является доказательством, что твой компьютер это твой компьютер.

Но создание токена для пользователя при отправке форм? Каким образом это защитит от CFRF я не понимаю

Типичные ошибки при защите сайтов от CSRF-атак / Хабр

В настоящее время в сфере обеспечения безопасности веб-сайтов и приложений возникла очень интересная ситуация: с одной стороны, некоторые разработчики уделяют особое внимание безопасности, с другой, они напрочь забывают о некоторых видах атак и не считают ошибки, позволяющие выполнить данные атаки, уязвимостями. Например, к такой категории можно отнести CSRF (Сross Site Request Forgery). Эта атака позволяет производить различные действия на уязвимом сайте от имени авторизованного пользователя. Если вы не слышали о таком, то я рекомендую прочитать соответствующую статью в Википедии, чтобы иметь общее представление об этом виде атак. Основная часть статьи предназначена тем, кто обеспокоен правильной защитой своих сайтов от CSRF.

Замечание 1: если подходить формально, то CSRF является атакой, а не уязвимостью, как и XSS. Уязвимостью является неправильная обработка входных данных, а CSRF это использует.

Замечание 2: если какие-то ошибки показались вам очевидными и не заслуживающими упоминания, то я рад за вас. Однако данный материал основан на реальных уязвимостях крупных сайтов, а каждый пункт показывает ошибку какой-либо команды разработчиков, обернувшуюся дырой в безопасности.

Список ошибок:

1) Полностью отсутствует защита от CSRF.

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

2) Защищены не все запросы.

Я бы поставил эту ошибку на второе место по распространенности. На многих сайтах, где реализована какая-либо защита от CSRF, можно найти уязвимые запросы. Например, если вы воспользуетесь поиском Хабра habrahabr.ru/search/?q=CSRF, то увидите значительное количество статей, повествующих о найденных уязвимостях на тех сервисах, где есть защита.
Вы должны защищать абсолютно все запросы, которые изменяют что-либо на сайте. Вы добавили токен в форму смены адреса электронной почты, и злоумышленник не сможет завладеть аккаунтом вашего пользователя, изменив от его имени почту, а затем и пароль? Здорово. Вот только такая мера бесполезна, если можно просто отправить запрос на перевод денег с аккаунта жертвы на кошелек атакующего, минуя вашу защиту.
Удобство обеспечения безопасности — одна из причин использовать только метод POST для запросов, изменяющих данные пользователя. Если вы следуете этому совету, то необходимо просто убедиться, что все POST-запросы содержат надежный и правильный токен. Об этом речь пойдет ниже.

3) Использование для защиты от CSRF чего-либо, кроме токенов.

Казалось бы, очень удобно использовать HTTP referer (https://ru.wikipedia.org/wiki/HTTP_referer) для защиты от атак. Если в этом заголовке не страницы с вашего домена, то запрос был подделан. Но не все так радужно. У небольшой части пользователей HTTP referer может быть пуст по разным причинам. Кроме того, он может быть подделан с использованием старых версий Flash, что подставляет под удар тех, кто очень долго ничего не обновлял на своем компьютере.

Как насчет использования капчи? Я слышал достаточно большое количество вопросов от разработчиков о возможности их использования для защиты от атаки. Мой однозначный ответ — нет. Во-первых, вы явно не будете заставлять пользователя вводить капчу на каждый чих: это приведет к ошибке № 2. Во-вторых, далеко не все способы реализации капч обеспечат вас должной защитой, которую злоумышленник не сможет обойти. Поскольку эта тема является весьма спорной и актуальной, в дальнейшем я посвящу ей отдельную статью.

Для защиты от CSRF вы должны использовать анти-CSRF токены и только их. Лишь они обеспечивают должную защиту ваших сайтов. В общих чертах о механизме токенов рассказано в Википедии:

Другим распространённым способом защиты является механизм, при котором с каждой сессией пользователя ассоциируется дополнительный секретный ключ, предназначенный для выполнения запросов. Пользователь посылает этот ключ среди параметров каждого запроса, и перед выполнением каких-либо действий сервер проверяет этот ключ. Преимуществом данного механизма, по сравнению с проверкой Referer, является гарантированная защита от атак данного типа. Недостатками же являются: требования возможности организации пользовательских сессий и динамической генерации HTML-кода активных страниц сайта.

4) Отсутствие проверки анти-CSRF токена при обработке запроса.

Подобную ошибку я встречал на сайтах весьма серьезных компаний, чья безопасность должна быть на высоте.
В самом запросе токен есть, а при его обработке он не проверяется. Можно вставить в это поле любую строку, запрос все равно будет корректно обработан. Комментировать тут особенно нечего, надо только указать, что применение функции isset() php.net/manual/ru/function.isset.php для проверки токена совершенно недопустимо.

5) Частичная проверка анти-CSRF токена.

Данную ошибку я встретил сразу на нескольких крупных сайтах рунета в разных вариациях. Например, один из сайтов использовал токены вида «Имя_пользователя.Текущее_время.Длинное_случайное_число». При этом проверялось только соответствие имени пользователя в токене и логина того, от чьего имени был отправлен запрос. Это немного усложняет атаку, но не делает ее невозможной.

6) Возможность использовать один токен для разных пользователей.

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

7) Недостаточная длина токена.

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

8) Предсказумые токены.

При разработке алгоритма генерации токена обязательно используйте случайные данные в токене (совет актуален, если вы разрабатываете всю систему с нуля. В случае использования фреймворка или CMS вы должны полагаться на их разработчиков). Поверьте, токен вида «md5(user_id)» — очень плохая идея.

9) Отсутствие токенов в админ-панели или системе для сотрудников техподдержки.

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

10) Передача токенов в открытом виде, особенно в GET-запросах.

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

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

Защищаем Revel от CSRF атак / Хабр

После того как наигрались с Revel и поняли что это за чудик, пора учиться готовить его к production в части безопасности. Данная заметка вполне может использоваться в любом веб-приложении, но рассказывать буду на примере простого приложения на Revel.

Вообщем суть проблемы заключается в том, что существует класс атак в Интернете именуемые Cross-Site Request Forgery (сокр. CSRF). Если вы не знакомы с ними, то просьба обратить свое внимание. Приведу небольшую выдержку из Вики:

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

рис. Пример CSRF-атаки на сайт банка

Рекомендую также прочитать типичные ошибки при защите сайтов от CSRF-атак.

На свежем приложении Revel CSRF-атаки успешно проходят, т.к. защиты изначально нет.

Итак, начнем кутить с сусликом — установка защиты

Товарищи из Revel предлагают нам уже готовый модуль для защиты github.com/revel/modules/tree/master/csrf/app с инструкцией по установке:

CsrfFilter enables CSRF request token creation and verification.

Usage:

1) Add `csrf.CsrfFilter` to the app’s filters (it must come after the revel.SessionFilter).

2) Add CSRF fields to a form with the template tag `{{ csrftoken. }}`. The filter adds a function closure to the `RenderArgs` that can pull out the secret and make the token as-needed, caching the value in the request. Ajax support provided through the `X-CSRFToken` header.

Собственно все ок! Добавил фильтр в init.go приложения по этой инструкции… И оно не заработает, если твой браузер не посылает в заголовке Referer. Поэтому пропустим всю установку этого фильтра в этой заметке и перейдем к альтернативному варианту.

Один из вариантов, предложенный в баг-трекере Revel на тему CSRF был проект: github.com/cbonello/revel-csrf. Принцип установки прост:

Сначала выкачиваем все к себе в GOPATH

go get github.com/cbonello/revel-csrf

Дальше в /app/init.go добавляем строчку в import секцию:

import (
	"github.com/cbonello/revel-csrf"
	"github.com/revel/revel"
)

А в функции init() в том же файле /app/init.go добавляем этот фильтр:

func init() {
	// Filters is the default set of global filters.
	revel.Filters = []revel.Filter{
		...
		revel.SessionFilter,           // Restore and write the session cookie.
		revel.FlashFilter,             // Restore and write the flash cookie.
		HeaderFilter,                  // Add some security based headers
		csrf.CSRFFilter,               // CSRF prevention. <----------------------------
		revel.ValidationFilter,        // Restore kept validation errors and save new ones from cookie.
		...
	}
        ...
}

Установка почти готова! Теперь все методы кроме GET, HEAD, OPTIONS, TRACE, WS считаются «небезопасными» и при отсутствии сгенерированного токена в запросе будет 403 ошибка.

Как передавать токен

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

<form action="{{url "App.ConfirmLogin"}}" method="post">
  <input type="hidden" name="csrf_token" value="{{.csrf_token }}">
  ...
</form>

Для упрощения можно взять функцию для шаблонизатора из модуля от команды Revel.

Большая часть действий так и решается — встраиванием скрытого поля в веб-формы. Но есть категория действий, которые не требуют отправки веб-формы, но являются небезопасными с точки зрения бизнес-логики. Например: выход пользователя по ссылке /logout. Провести атаку по такому действию очень просто, поэтому обработку такого действия необходимо перевести с безопасного GET метода на POST метод, который для нас является небезопасным. Для этого в файле /conf/routes добавим наше действие только для метода POST:

POST    /logout                                 App.Logout

Теперь необходимо сделать ссылки пригодными для работы с POST методами. Для таких случаев, можно использовать хорошую обертку для работы с ajax в RoR: github.com/rails/jquery-ujs

Устанавливаем к себе в проект через Bower:

$ bower install jquery-ujs --save

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

После подключения необходимо добавить еще пару строк в шапку, чтобы библиотека поняла какой токен отправлять:

<!DOCTYPE html>
<html lang="ru">
<head>
  ...
  <meta name="csrf-token" content="{{.csrf_token}}">
  <meta name="csrf-param" content="csrf_token">
  ...
</head>
...

После этого стоит включить еще поддержку Ajax у фильтра (по умолчанию выключена), для этого в файл /conf/app.conf нужно добавить следующее:

csrf.ajax = true
csrf.token.length = 64

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

Если все подключено верно, то теперь можно делать такие безопасные ссылки, которые будут делать запрос POST методом:

<a href="{{url "App.Logout"}}" data-method="post">Выход</a>

На этом у меня всё. Спасибо за внимание!

Как решить проблему с csrf_token? — Хабр Q&A

Есть страница А на которой пользователь указывает свою почту для смены пароля. На почту приходить сообщение со ссилкой на страницу В. На странице В обновляет свой пароль и его переводит на страницу пользователя с помощью redirect.
Когда пользователь переходит на вкладку со страницой А, с которой было отравлено сообщение на почту и обновляет ее, отправляя форму повторно, происходит ошибка «Forbidden (403)
CSRF verification failed. Request aborted.»
Как можно обновить csrf? или как можно обновить саму страницу А после авторизации? или есть другой способ исправить эту проблему?

Settings.py

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [os.path.join(BASE_DIR, 'templates')],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                # 'django.template.context_processors',
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
                'Performer.context_processors.context_processor',
            ],
        },
    },
]

View.py — страница А с которой пользователь отравляет сообщение на свою почту.

class ForgotPassword(View):
    def get(self, request):

        form = EmailForm()

        return render(request, 'Performer/Forgot_password.html', context={'form': form})

    def post(self, request):

        form = EmailForm(request.POST)

        if request.method == 'POST' and form.is_valid():
            email = request.POST.get('email')
            try:
                user = User.objects.get(email=email)
            except ObjectDoesNotExist:
                message = 'Неверный Email'
                return render(request, 'Performer/Forgot_password.html', context={'form': form, 'message': message})

            signer = Signer()

            global script_email

            script_email = signer.sign(email)

            link = 'http://127.0.0.1:8000/change_password/' + script_email.split(':')[1] + '/'

            subject = 'Изменение пароля'

            html_message = render_to_string(
                'Performer/Password_message.html', {'link': link}
            )

            send_mail(subject, 'message', settings.EMAIL_HOST_USER, [email], html_message=html_message, fail_silently=False)

            message = 'Сообщение отправлено'

            return render(request, 'Performer/Forgot_password.html', context={'form': form, 'message': message})

Forgot_pass.html — Страница А с которой пользователь отравляет сообщение на свою почту.

{% extends 'base.html' %}

{% block content %}
    <div>
        <div>
            {% if message %}
                <div>{{ message }}</div>
            {% else %}
                <form method="POST">{% csrf_token %}
                    
                    {{ form.as_p }}

                    <button>Изменить пароль</button>
                </form>
            {% endif %}
        </div>
    </div>
{% endblock %}

View.py — Страница В на которой пользователь меняет свой пароль.

class ChangePassword(View):
    def get(self, request, link):

        signer = Signer()

        global email

        email = signer.unsign(script_email)

        audit = signer.sign(email).split(':')[1]

        if link != audit:
            message = 'Паге нот фаунд'

            form = EmailForm()

            return render(request, 'Performer/Forgot_password.html', context={'form': form, 'message': message})

        form = ChangePasswordForm()

        return render(request, 'Performer/Change_password.html', context={'form': form})

    def post(self, request, link):

        form = ChangePasswordForm(request.POST)

        if request.method == 'POST' and form.is_valid():

            user = User.objects.get(email=email)

            new_password = form.cleaned_data['password_2']

            user.set_password(new_password)

            user.save()

            user = authenticate(request, username=user.username, password=new_password)

            login(request, user)

            return redirect('/user_profile/')

Change_password.html — Страница В

{% extends 'base.html' %}

{% block content %}
    <div>
        <div>
            <form method="POST">{% csrf_token %}

                {{ form.as_p }}

                <button>Изменить пароль</button>
            </form>
        </div>
        
    </div>
{% endblock %}

токенов CSRF | Академия веб-безопасности

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

Что такое токены CSRF?

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

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

Как следует генерировать токены CSRF?

Токены CSRF должны содержать значительную энтропию и быть сильно непредсказуемыми, с теми же свойствами, что и токены сеанса в целом.

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

Если вам нужна дополнительная гарантия, выходящая за рамки возможностей ГПСЧ, вы можете сгенерировать отдельные токены, объединив их вывод с некоторой пользовательской энтропией и взяв сильный хэш всей структуры.Это представляет собой дополнительный барьер для злоумышленника, который пытается проанализировать токены на основе выданного им образца.

Как следует передавать токены CSRF?

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

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

Альтернативный подход, заключающийся в помещении токена в строку запроса URL, несколько менее безопасен, поскольку строка запроса:

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

Некоторые приложения передают токены CSRF в настраиваемом заголовке запроса. Это представляет собой дополнительную защиту от злоумышленника, которому удается спрогнозировать или захватить токен другого пользователя, поскольку браузеры обычно не разрешают пересылку настраиваемых заголовков через домен. Однако такой подход ограничивает приложение выполнением CSRF-защищенных запросов с использованием XHR (в отличие от HTML-форм) и во многих ситуациях может считаться слишком сложным.

Токены CSRF не должны передаваться в файлах cookie.

Как следует проверять токены CSRF?

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

.

php — в чем разница между X-XSRF-TOKEN и X-CSRF-TOKEN?

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

новейших вопросов ‘csrf-token’ — qaru

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

.

Проблемы с токеном CSRF и способы их решения

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

Что такое CSRF, почему мы используем токен CSRF и как долго он действителен

CSRF (подделка межсайтовых запросов) — это тип атаки, когда злоумышленник пытается отправить злонамеренные запросы с веб-сайта, который пользователь посещает, на другой сайт, где жертва аутентифицирована.Предотвращение этой атаки основано на хранении токена безопасности во время сеанса пользователя и предоставлении его при каждой операции изменения (PUT, POST, DELETE). Если предоставленный токен неверен, шлюз отвечает кодом возврата HTTP 403 («Запрещено»). [1, 2]

Срок действия зависит от ваших настроек и версии SAP_BASIS. В моем случае я обнаружил, что срок действия токена установлен на 30 минут.

“ Срок действия токена CSRF зависит от выпуска компонента ABAP SAP_BASIS и от активации управления сеансом безопасности (которое контролируется с помощью транзакции SICF_SESSIONS на гранулярности клиентов SAP):

1.Выпуск <7.03 / 7.31 или управление сеансом безопасности неактивно: создается собственный файл cookie CSRF (sap-XSRF_ _ ), и этот токен CSRF остается действительным в течение 24 часов (86400 секунд).

2. Выпуск> = 7.03 / 7.31, срок действия привязан к сеансу безопасности, который зависит от значения системного параметра http / security_session_timeout (подробности об этом параметре см. В транзакции RZ11). По умолчанию в этих выпусках активно управление сеансом безопасности. ”[3]

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

1-я проблема — вы используете ODataModel для операций изменения и не вызываете метод refreshSecurityToken () перед ними

Вы в любом случае должны быть в безопасности. ODataModel имеет параметр bTokenHandling, который заботится об обработке токенов.Я не нашел информации, когда openui5 начал поддерживать эту функцию, но вы можете проверить это в отладчике, что после создания экземпляра ODataModel для bTokenHandling по умолчанию установлено значение true.

Таким образом, результат этого открытия состоит в том, что вам не нужно использовать метод refreshSecurityToken (), если вы не отключите bTokenHandling или не хотите реализовать какую-то особую функциональность при сбое обновления.

2-я проблема — вы используете библиотеку datajs и OData.request для операций изменения

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

3-я проблема — вы используете внешний клиент REST для тестирования операции изменения

Если вы не предоставите токен, вы получите ответ 403 HTTP Forbidden со следующим сообщением «Ошибка проверки токена CSRF».

В этом случае вам нужно сначала получить токен CSRF, добавив параметр заголовка X-CSRF-Token: Fetch , прочитать его содержимое из параметра ответа x-csrf-token и добавить его вручную в заголовок вашего запроса на изменение тестирования.

4-я проблема — вы отправляете файлы на шлюз SAP с помощью sap.ui.commons.FileUploader и получаете ответ HTTP 403 — ошибка проверки токена CSRF

К сожалению, между загрузчиком файлов и ODataModel нет связи, поэтому загрузчик файлов должен самостоятельно выполнять проверку токена. Здесь применима та же логика, что и в предыдущем выпуске. К сожалению (опять же), нет способа установить параметр заголовка http для загрузчика файлов, поэтому вам нужно переопределить его самостоятельно и изменить логику, как это описано в этом сообщении Re: FileUploader и X-CSRF-Token ?.

Ждем ваших отзывов, дайте мне знать, если некоторые из моих предположений неверны.

Список литературы

[1] Подделка межсайтовых запросов — Википедия, бесплатная энциклопедия

[2] https://help.sap.com/saphelp_nw74/helpdata/en/b3/5c22518bc72214e10000000a44176d/content.htm

[3] Защита CSRF — Связь — Библиотека SAP

.

No related posts.