Смысл CSRF Token`а

#веб_программирование #token #csrf

Доброго времени суток! 

Изучаю csrf и не могу понять одну вещь, помогите пожалуйста разобраться.
На сайте learn.javascript есть статья по этому поводу. Там сказано:


  Типичный способ защиты сайтов – это «секретный ключ» (secret),
  специальное значение, которое генерируется случайным образом и
  сохраняется в сессии посетителя. Его знает только сервер, посетителю
  мы его даже не будем показывать.
  
  Затем на основе ключа генерируется «токен» (token). Токен делается
  так, чтобы с одной стороны он был отличен от ключа, в частности, может
  быть много токенов для одного ключа, с другой – чтобы было легко
  проверить по токену, сгенерирован ли он на основе данного ключа или
  нет.
  
  Для каждого токена нужно дополнительное случайное значение, которое
  называют «соль» salt.
  
  Формула вычисления токена:
  
  token = salt + ":" + MD5(salt + ":" + secret) Например:
  
  В сессии хранится secret="abcdef", это значение создаётся один раз.
  Для нового токена сгенерируем salt, например пусть salt="1234". token
  = "1234" + ":" + MD5("1234" + ":" + "abcdef") = "1234:5ad02792a3285252e524ccadeeda3401".
Это значение – с одной
  стороны, случайное, с другой – имея такой token, мы можем взять его
  первую часть 1234 в качестве salt и, зная secret, проверить по
  формуле, верно ли он вычислен.
  
  Не зная secret, невозможно сгенерировать token, который сервер
  воспримет как правильный.
  
  Далее, токен добавляется в качестве скрытого поля к каждой форме,
  генерируемой на сервере.При её отправке сервер проверит поле csrf,
  удостоверится в правильности токена, и лишь после этого отошлёт
  сообщение.
  
  «Злая страница» при всём желании не сможет сгенерировать подобную
  форму, так как не владеет secret, и токен будет неверным.


Мне непонятно вот что:


secret хранится в сессии, а сессия хранится в куках на клиентской машине, и каждый
раз отправляется веб серверу. Разве хакер не сможет получить доступ к кукам? К ним
вообще можно же получить доступ? Они хранятся же в файле где-то?
Если токен приходит каждый раз с формой, разве хакер не сможет этот токен из html
который пришел выдрать, заюзать его и отправить для своего запроса?
Я так понимаю смысл всей этой ерунды есть только тогда, когда либо


Сайт разрешает кросс-доменные запросы от всех Origin: *
либо
Злоумышленник мог ранее уже встроить форму на тот же сайт через XSS, чтобы оставаться
в том же домене, так как во всех остальных случаях у нас есть CORS, зачем нам CSRF?

Не понял, почему формула токена именно такая:

token = "1234" + ":" + MD5("1234" + ":" + "abcdef") = "1234:5ad02792a3285252e524ccadeeda3401"


Зачем нужно соль "1234" склеивать со сгенерированной md5-функцией строкой? Ведь соль
1234 становится явно видна в токене!
Т.е. получается бразузер шлет каждый раз "abcdef" в куках как Id-сесии, и также шлет
токен. Сервер еще раз генерирует токен, используя этот id сессии, и сверяет с тем,
что пришел от формы? Не совсем ясно, как это помогает, если токен можно подглядеть(если
можно?)


Спасибо заранее за помощь!
Отличие от данного вопроса в том, что там так и не понятно, зачем нужен CSRF если
есть CORS
    

Ответы

Ответ 1

secret хранится в сессии, а сессия хранится в куках на клиентской машине, и каждый
раз отправляется веб серверу. Разве хакер не сможет получить доступ к кукам? К ним
вообще можно же получить доступ? Они хранятся же в файле где-то?


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


  Если токен приходит каждый раз с формой, разве хакер не сможет этот токен из html
который пришел выдрать, заюзать его и отправить для своего запроса?


Только в случае MITM. При CSRF у хакера нет доступа к серверу, клиенту или каналу связи.


  я имею в виду разве он не может получить форму просто еще раз скриптом и этот токен
потом отправить в своем запросе?


Не может - тут сработает CORS. Если запрос get, то сервер его получит, но если он
не пошлёт разрешающие заголовки, то запрашивающему скрипту браузер ответ не отдаст.
А на POST вообще будет OPTIONS-запрос сначала.

А если послать запрос не из браузера, а с сервера, то не будет авторизации пользователя
и токен он опять же не получит.


  Я так понимаю смысл всей этой ерунды есть только тогда, когда либо
  Сайт разрешает кросс-доменные запросы от всех Origin: * либо ...


Нет. Браузер позволит отправит форму, вот:


  
  




  Не понял, почему формула токена именно такая:


Форма может быть разной.


  Зачем нужно соль "1234" склеивать со сгенерированной md5-функцией строкой? Ведь
соль 1234 становится явно видна в токене!


Если соли нет, то ключ одного клиента подойдёт другому и хакер сможет использовать
свой, поэтому нужна соль.

Хм.. А вообще, что-то я задумался, есть тут сомнения...

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


  он не совпадет, потому что хакеру неизвестен id сессии, на основе котороой генерируется
токен?


Я имел в виду, что у хакера может быть свой токен, который корректен для него. Но
этот токен не совпадёт с тем токеном, который лежит у другого пользователя в куках.
А из чужих кук он его достать не может.


  Т.е. получается бразузер шлет каждый раз "abcdef" в куках как Id-сесии, и также
шлет токен. Сервер еще раз генерирует токен, используя этот id сессии, и сверяет с
тем, что пришел от формы? Не совсем ясно, как это помогает, если токен можно подглядеть(если
можно?)


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


Ответ 2

Зачем нужно соль "1234" склеивать со сгенерированной md5-функцией строкой? Ведь соль
1234 становится явно видна в токене!


А ее и не нужно прятать. Она не для прямой секретности, а для двух других целей:


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