Можно для тех кто в танке про CSRF?

Question

[ТёмнаяМатерия]

Я ознакомился с https://habrahabr.ru/post/235247/ и другими статьями на ресурсах поменьше.
Сейчас у меня куки ставятся на 1 час в них кроме имени куки ничего не хранится, в сессии хранится email, id и сама сессия нигде не хранится (кроме temp сервера разумеется).

Если я правильно понял то:
1. Юзер авторизуется, при авторизации генерим ему токен и кладём в сессию
2. В любой форме есть скрытое поле token которое заполняется без ведома юзера данными из сессии
3. Но во время приёма данных формы из формы пришедший token надо как-то сравнить с оригиналом, иначе можно отправить любой и всё это обессмыслено. Выходит что бы был оригинал в пункте 1 token надо записать не только в сессию но в БД из которой при каждой проверке извлекать для сравнения.
А обновлять в БД его при каждой авторизации...
4. Get-запросы токенами защитить невозможно
Всё так или я что-то упустил?

Answer 1

[xfg]

4. Get-запросы токенами защитить невозможно

Возможно, но не нужно. Вам не следует выполнять никаких действий, кроме отдачи контента по get запросу. Для update/delete/create нужно использовать POST если это классический веб-сайт и PUT/DELETE/POST если это RESTful API.

Пусть клиент отправляет csrf-токен в POST запросе. Пусть сервер при старте сессии сохраняет csrf-токен в сессию. Пусть сервер перед тем как выполнить POST запрос проверит соответствие токена из запроса с тем, что в сессии.

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

Comments

[ТёмнаяМатерия]

По поводу GET только есть замечание что есть иногда API и у меня скоро в таком будет необходимость которые позволяют добавлять какие-то сущности через API в БД (конечно, после проверки) или для этого случая вы как раз предлагаете PUT юзать?

[xfg]

ТёмнаяМатерия: да, вы не должны изменять/создавать/удалять сущности через GET, делайте это через POST или как принято в RESTful POST - создание, PUT - изменение, DELETE - удаление. GET должен возвращать данные, но не должен их изменять.

Answer 2

[Владимир Грабко]

1) создаем токен
2) пишем в сессию
3) добавляем в нужные места во вьюхах. например, hidden-поля в формы или устанавливаем какой-нибудь заголовок, если запросы делаются через AJAX
4) при каждом POST/DELETE/PUT/PATCH запросах проверяем входной токен и токен в сессии. не совпали = пока.

Answer 3

[Алексей Николаев]

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

Время хранения кук тут роли никакой не играет. Нажмет пользователь "запомнить меня", а вы установите ему куку на час?

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

Get-запросы токенами защитить невозможно

Почему? Посылаете в get токен параметром, на сервере проверяете.

Comments

[ТёмнаяМатерия]

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

А т.е. один на сессию не прокатит? Потому что каждый новый запрос - это по факту обновление страницы простое. Получается мне надо делать update токена в базе не при авторизации а просто при обновлении страницы

[ТёмнаяМатерия]

Алексей Николаев: я понял просто на 4:44 https://www.youtube.com/watch?v=CWje5DWniDQ у человека каждое обновление токен меняется, я прифигел немного...

[Алексей Николаев]

ТёмнаяМатерия: нет, в том и суть, что он должен быть одноразовым. Сессия может быть долгой, и вполне можно каким-либо образом получить токен. В целом да, можно менять при каждом обновлении страницы.

[ТёмнаяМатерия]

Алексей Николаев: Ааа, я рандомно генерирую, кладу в сессию и в форму, а когда форма приходит я должен сравнить с тем что в сессии? Но тут надо не облажаться и не сгенерировать новый токен ДО проверки формы ))))

[Алексей Николаев]

ТёмнаяМатерия: да, примерно так) А насчет второго - тут все зависит от архитектуры проекта в целом) В принципе, если за обработку действий и вывод самой формы отвечают разные части приложения, проблем быть не должно, т.к. есть четкое разделение.

Answer 4

[Артем Сошников]

Посмотрите в сторону готовых решений, наподобии этого:
https://github.com/BKcore/NoCSRF

Если хотите разобраться, как это все работает, можно расковырять код этой библиотеки

Comments

[ТёмнаяМатерия]

Почему-то никто упорно не обращает внимания на вопрос )) Меня не интересуют бибилиотеки интересует правильно ли я понимаю сам механизм работы защиты...

[Артем Сошников]

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

Answer 5

[#алгоптимизируй #отботизируй]

Должны быть готовые решения, гляньте как там реализовано, типа asp mvc. В гет лучше ничего не пихать и вообще им лучше не пользоваться ао многих местах. Если нет сессии, почему вообще встал вопрос об этой уязвимости? Сессия не хранится-это как? Токен должен соответствовать сессии и например пути.

Comments

[ТёмнаяМатерия]

Ещё раз меня не интересуют библиотеки не интересует как это реализовано в asp, мне интересен механизм.

Сессия не хранится-это как?

Это она есть пока живёт кука - 1 час

[#алгоптимизируй #отботизируй]

Токен не нужно хранить, можно хранить например соль.

[#алгоптимизируй #отботизируй]

Механизм заключается в проверке соответствия запроса и сессии с токеном . Это и так ясно, думаю

[ТёмнаяМатерия]

С Sharp: Идите уже в темы по С шарп наконец )))) Если я буду хранить только соль, а токен генерируется только из микротайма я НИКОГДА его не восстановлю для сравнения ))

[#алгоптимизируй #отботизируй]

Микротайм -это что? Метка времени, я не про какие микротаймы не писал . Смотрите любую реализацию и все вопросы отпадут . Нравится использовать постоянный токен - испльзуйте.

[ТёмнаяМатерия]

С Sharp: Просвещайтесь:
$token = md5(microtime(true).rand(1,1000000));