Я узнаю, как предотвратить использование CSRF с помощью токенов анти-CSRF. По существу, идея заключается в следующем: –
1) сгенерируйте токен, например Md5 или Sha1, затем сохраните это значение в переменной сеанса:
$token = md5(uniqid(rand(), TRUE)); $_SESSION['token'] = $token; 2) Все формы включают это значение маркера в скрытом поле POST
<input type='hidden' name='token' value='$nonce_token' />
Например, как это будет выглядеть для пользователя в исходном коде:
<input type='hidden' name='token' value='9ee66e4e63a06ee4b83a3edde4ecd587' />
3) После того, как отправленная форма проверяет значение токена POST скрытого поля, совпадает с токеном, хранящимся в значении сеанса
if($_POST['token']==$_SESSION['token']){...ok...}
Тем не менее, этот процесс кажется немного ошибочным, поскольку, включив значение токена в скрытое поле POST, атака может просто просто посмотреть исходный код веб-сайта, чтобы увидеть токен, а затем просто включить это во вредоносную сформированную форму POST, которую мое приложение будет таким образом после того, как полученное значение переданного знака будет соответствовать значению токена в моей переменной сеанса, поскольку я по существу показываю злоумышленнику значение маркера в моем скрытом поле.
Таким образом, мой вопрос заключается в том, что это лучший способ обойти это, поскольку несколько идей, которые я по-прежнему кажутся немного испорченными:
1) Использование _GET вместо этого, но у этого все еще есть недостатки, такие как _POST
2) Изменение значения токена после x минут или каждого запроса, но вызывает проблемы с удобством использования при возврате в браузере или сбое, когда пользователь, заполняющий форму и значение токена, устареет по сравнению с обновленным значением токена сеанса, поскольку значение скрытого токена не будет обновляться, пока пользователь заполняя форму.
3) Попробуйте зашифровать скрытое значение токена POST-формы, а затем дешифровать при отправке POST, но шифрование / дешифрование уже хэшированного значения кажется сложным, особенно один способ шифрования имеет такие значения, как MD5 и т. Д.?
Любые идеи будут высоко оценены.
Однако этот процесс кажется немного ошибочным, поскольку, включив значение токена в скрытое поле POST, атака может просто просто посмотреть исходный код веб-сайта
Нет, они не могут.
Алиса управляет сайтом. Боб посещает веб-сайт. Мэллори атакует счет Боба.
Когда он посещает сайт Алисы, Боб получает знак nonce.
Если бы Мэллори посетил сайт, Мэллори получал бы другое nonce (потому что у Мэллори была бы другая сессия).
Если Мэллори создал форму с вредоносными данными в ней (на ее веб-сайте) и обманул Боба, чтобы отправить его, то неэлл Мэллори, поставленный в форме, не будет соответствовать команде nonce в Бобу, и представление будет отклонено.
Что вам нужно сделать, так это сделать скрытое поле хеш MD5 или SHA1 идентификатора сеанса с солью. Таким образом, вы сравниваете представленное значение с хэшем идентификатора сеанса плюс соль, и если они совпадают, это действительно. Если злоумышленник может угадать токен, то они уже украли идентификатор сеанса, и теперь было бы бессмысленно защищаться, так как логин уже был взломан. Это действительно так просто. Вот одна отличная информация для OWASP о том, как предотвратить CSRF https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
Давайте рассмотрим сценарий атаки:
example.com и вы используете токены CSRF в своих формах. Это оставляет такой сценарий: используя Javascript, Eve получает форму с вашего сервера как Alice , затем отправляет эту форму обратно, включая действительный токен. Т.е. Ева полностью олицетворяет Алису за весь процесс регулярной подачи формы с использованием Javascript. Этому препятствует Политика Одинакового Происхождения . Eve Javascript не сможет получать информацию с вашего сервера, браузер Alice предотвратит это, так как он нарушает политику одного и того же происхождения.
То есть, если предположить, что в браузере нет дыр в безопасности, которые позволяют Еве обойти эту политику. Это также означает, что вам нужно защищать от XSS, то есть против того, чтобы Ева могла внедрить один из своих сценариев на ваш сайт, поэтому постоянные посетители вашего сайта будут запускать скрипты Eve как часть вашего сайта из одного источника.
Как немного саморекламы, я только что реализовал основанную на подписке библиотеку токенов CSRF, на которую вы можете посмотреть: Kunststube \ CSRFP . Я также хотел бы попросить экспертную оценку и критиковать ее, пока я нахожусь в ней.
Во-первых, вы должны иметь в виду, что вы не можете помешать хакерам атаковать ваше приложение, только вы можете сделать все сложнее.
Идея приходит ясно, когда вы думаете о том, что является основной целью атак CSRF. CSRF – это атака, которая обманывает жертву при загрузке страницы, содержащей вредоносный запрос. Он злонамерен в том смысле, что он наследует личность и привилегии жертвы выполнять нежелательную функцию от имени жертвы, например, изменять адрес электронной почты жертвы, домашний адрес или пароль или приобретать что-то. Атаки CSRF обычно нацелены на функции, которые вызывают изменение состояния на сервере, но также могут использоваться для доступа к конфиденциальным данным.
Так, как и выше, злоумышленники не делают атаки непосредственно на вашу веб-страницу, им нужен мост, им нужна жертва, поэтому они могут использовать жертву и привилегии для выполнения действий.
когда вы сказали:
Однако этот процесс кажется немного ошибочным, поскольку, включив значение токена в скрытое поле POST, атака может просто просто посмотреть исходный код веб-сайта
это не имеет смысла, потому что злоумышленник не будет атаковать себя.
Надеюсь, это поможет.