Когда использовать/не использовать protect_from_forgery

Я знаю, как включить/отключить проверку токена подлинности, но не знаю, когда это имеет смысл включать.

Например, в приложении rails я понял следующее. пожалуйста, дайте мне знать, если я ошибаюсь

Интернет:

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

API:

  • общедоступный API (незарегистрированный, доступ JSON) должен включать проверку токена подлинности
  • API аутентификации (вход, регистрация, утерянный пароль..., доступ JSON) должен включать проверку токена подлинности.
  • частный API (вход в систему, доступ JSON) не нужно включать проверку токена подлинности

authentication ruby-on-rails json antiforgerytoken
person Benj    schedule 31.07.2014    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Неправильно, что для частных страниц не нужно включать защиту CSRF. Частные страницы, на которых пользователь аутентифицирован, уязвимы для CSRF. В этой атаке кто-то, кто вошел в систему, обманом (например, щелкнув ссылку в электронном письме), чтобы выполнить действие, которое он не собирался совершать, что сайт принимает, потому что оно исходит от вошедшего в систему пользователя с действительным сессия. protect_from_forgery предотвращает это, гарантируя, что запросы, отличные от GET, могут быть инициированы только с самого сайта пользователем, знающим о предпринимаемых им действиях.

person Ryan Mitchell    schedule 31.07.2014
comment
Очень понятно спасибо. Как насчет запросов JSON (например, из мобильного приложения)? Я так понимаю, там нет риска быть "обманутым"? Зная, что файлы cookie находятся внутри приложения, и приложение не принимает внешние действия, которые можно было бы выполнить с помощью простой ссылки. - person Benj; 31.07.2014
comment
Вы будете уязвимы до тех пор, пока злоумышленник сможет обманом заставить пользователя инициировать тот же запрос из другого контекста. Например, см. раздел сценария POST на сайте owasp.org/index.php/Cross- Site_Request_Forgery_(CSRF). Те же ограничения политики происхождения могут затруднить выполнение этой атаки для запросов, отличных от GET или -POST, но не сделать это невозможным (см. Другие методы HTTP на той же странице). Мое эмпирическое правило таково: будьте очень осторожны, предполагая, что запрос не может быть подделан, и ошибайтесь в сторону включения защиты. - person Ryan Mitchell; 31.07.2014