CSRF - Cross Site Request Forgery, Безопасность | Security

#4 Безопасность — Закрываем уязвимости CSRF.

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

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

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

Более свежая версия DVWA, которая идет без Metasploitable2, имеет более защищенную оборону от уязвимости CSRF, и не только.

****************************************************************

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

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

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

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

Как только Вы создаете токен, Вам нужно подтвердить его со стороны клиента. Это может быть слегка непонятным, поэтому можно рассмотреть пример на практике:

Давайте представим,  что цель хочет сменить пароль.

К примеру: id=3, newPassword = 555, Token Key = rT56Mv1

Токен является статичным.

Генерация токена будет проходить соединением id, newPassword, Token Key.

Вот, что получится: Token = 3555rT56Mv1

Ключ токена хранится в коде PHP, поэтому мы не увидим его в браузере.

Далее можем зашифровать данные, с помощью одностороннего шифрования MD5, или любого другого:

48692dee4e181f88163b1a4508c3caf6

Для демонстрации работы токена, перейдем в уязвимое веб-приложение «Mutillidae»:

На данном этапе «Securty Level: 0».

Проверим исходный код нашего поля:

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

Давайте укажем максимальную защищенность – это level 5:

Мы не знаем, как выглядит ключ и сам токен. Все это происходит в фоновом режиме.

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