Я только что установил простую CSRF-защиту в своем приложении. Он создает уникальную крошку, которая проверяется против значения сеанса при отправке формы.
К сожалению, теперь это означает, что я не могу одновременно открывать несколько экземпляров (вкладки в браузере) моего приложения, когда крохи CSRF сталкиваются друг с другом.
Должен ли я создать индивидуальный токен для каждой фактической формы или использовать взаимную, общую крошку для всех моих форм? Что здесь общего?
Вы можете это сделать. Это зависит от уровня безопасности, который вы хотите.
API OWASP Enterprise Security API (ESAPI) использует единственный токен для каждого сеанса пользователя. Вероятно, это довольно эффективный метод, предполагающий, что у вас нет отверстий XSS, и у вас достаточно короткие тайм-ауты сеанса. Если вы разрешаете сеансам оставаться в живых в течение нескольких дней или недель, то это не очень хороший подход.
Лично мне не сложно использовать другой токен для каждого экземпляра каждой формы. Я храню структуру в сеансе пользователя с парами ключ-значение. Ключом для каждого элемента является идентификатор формы, значение – это другая структура, которая содержит токен и дату истечения срока действия этого токена. Обычно я разрешаю токену жить 10-20 минут, а затем истекает. Для более длинных форм я могу дать ему длительное время истечения срока.
Если вы хотите поддерживать одну и ту же форму на нескольких вкладках браузера в том же сеансе, мой метод становится небольшим обманом, но его можно легко сделать с помощью уникальных идентификаторов формы.
У Cheat Sheet OWASP есть самые окончательные ответы на подобные вещи. В нем обсуждаются различные подходы и балансировка безопасности и удобства использования.
Вкратце они рекомендуют иметь один токен на (браузер) сеанс. Другими словами, в вашем случае один и тот же токен делится между вкладками. В чит-листах также подчеркивается, что очень важно не подвергать сайт уязвимости межсайтового скриптинга, поскольку это подрывает стратегию токена CSRF за сеанс.
Во-первых: я не специалист по безопасности, поэтому вы, вероятно, не должны доверять тому, что я говорю.
Я думаю, что создание другого токена для каждой формы более безопасно. Рассмотрим уязвимость XSS на одной странице, которая позволяет злоумышленнику получить токен CSRF для этой формы. Если все формы используют один и тот же токен, у злоумышленника теперь есть токены CSRF для всех форм. Если все формы имеют разные маркеры, атака может быть намного меньше по охвату.
Как я знаю о CSRF, вы можете использовать
1) Случайное число и сохранить его в сеансе:
Добавьте его в скрытый ввод, называемый скрытым, а затем, когда вы получите информацию, вы можете проверить скрытое поле со значением сеанса
2) Статическая переменная конфигурации (например, предыдущая, но без сеанса)
Скрытое поле будет содержать это значение (переменная из config). Когда вы подтвердите свой выбор, вы проверите скрытое сообщение и значение ключа безопасности конфигурации
3) HTTP Referer
Вы можете использовать http referrer, чтобы узнать, откуда пришел пользователь, и проверить его с помощью реального домена (этот метод может атаковать, если ваш сайт содержит xss).
Как я знаю, вы можете использовать любое решение 🙂