CSRF-токен session_store с ember-simple-auth вместе с Devise

Question

Можно ли одновременно реализовать Rails csrf через cookie_store при использовании ember-simple-auth Devise?

Руководства, подобные этому, всегда отключаются Rails.application.config.session_store что, насколько я понимаю, не позволяет Rails отслеживать токены csrf, что приводит к тому, что Rails теряет отслеживание сессий g. После попытки многих решений, включая:

1. require jquery_ujs на рельсе манифест.
2. Rails.application.config.session_store :disabled,
3. https://github.com/abuiles/rails-csrf.
4. Изменение адаптера Ember.js для добавления CSRF.

Конечный результат остается почти таким же:

Невозможно проверить подлинность токена CSRF с последующим завершением 422 необработанного объекта, если для protect_from_forgery задано: исключение вместо:null_session.

Пример транзакции:

Частичный запрос HEADER:

X-CSRF-Token:1vGIZ6MFV4kdJ0yYGFiDq54DV2RjEIaq57O05PSdNdLaqsXMzEGdQIOeSyAWG1bZ+dg7oI6I2xXaBABSOWQbrQ==

Ответчик HEADER

   HTTP/1.1 422 Unprocessable Entity
   Content-Type: text/plain; charset=utf-8
   X-Request-Id: 71e94632-ad98-4b3f-97fb-e274a2ec1c7e
   X-Runtime: 0.050747
   Content-Length: 74162

  The response also attaches the following:
  Session dump
  _csrf_token: "jFjdzKn/kodNnJM0DXLutMSsemidQxj7U/hrGmsD3DE="

Ответ rails-csrf из моей ветки csrf (ветка удалена).

beforeModel() {
    return this.csrf.fetchToken();
},

Partial dump of the return statement:

_result: Object
param: "authenticity_token"
token: "1vGIZ6MFV4kdJ0yYGFiDq54DV2RjEIaq57O05PSdNdLaqsXMzEGdQIOeSyAWG1bZ+dg7oI6I2xXaBABSOWQbrQ=="

Насколько я понимаю, все эти попытки решения имеют общий корень: session_store отключен...

Answer 1

Обновить!

Приведенный ниже ответ оказался неправильным по своей природе после того, как он узнал больше о защите CSRF и Ember-Cli-Rails.

---

Идея здесь состоит в том, чтобы иметь два хранилища: хранилище на основе файлов cookie только для токена csrf, поддерживаемого Rails, и localStorage, поддерживаемый Ember-simple-auth, где позаботятся о токене аутентификации пользователя, электронной почте и идентификаторе. пользовательский сеанс SessionAccount наследует эти значения и проверяет их на сервере перед настройкой пользователя, который будет доступен для всего Ember.js.

Проверка с помощью SessionAccount происходит для обнаружения любого вмешательства в localStorage. Проверка происходит каждый раз, когда SessionAccount запрашивает localStorage (например, перезагрузку страницы), когда он связывается с сервером через модель токена (токен, электронная почта и идентификатор). Сервер отвечает 200 или 404 через TokenSerializer, который только отображает электронную почту или проверку ошибка, таким образом, не раскрывая интерфейс для просмотра других аутентификационных маркеров, если пользователь не войдет в систему через форму входа в систему, которая требует адрес электронной почты и пароль.

Насколько я понимаю, слабые места в этой методологии недостаточно уязвимы, чтобы их можно было легко взломать, если:

• Кто-то вторгается на сервер и получает содержимое базы данных. Несмотря на то, что пароли являются солеными, любой человек, у которого есть дамп базы данных, может изменить токен localStorage, адрес электронной почты и идентификатор на человека, которого они хотят выдать за себя, и проверка сервера будет работать. Однако это может быть сведено к минимуму работником, который меняет маркер аутентификации для не авторизованных пользователей каждые 24 часа (или на любом другом периоде времени). В разделе примера кода в настоящее время нет рабочего, поскольку я до сих пор не узнал о них.
• Кто-то знает пароль и адрес электронной почты человека, которого они хотят взломать... Сейчас я мало что могу с этим поделать.
• Кто-то перехватывает данные, передаваемые через JSON API. Сильная реализация SSL должна хорошо работать.
• Если в вашем sessionAccount есть что-то в строках is_Admin, то токен может быть отправлен вместе с POST-запросом только для запросов администратора для дальнейшей проверки бэкэнда, поскольку вы никогда не можете доверять внешнему интерфейсу.
• Что-то другое? Это те, о которых я знаю.

Теперь о практическом подходе:

1. Задавать Rails.application.config.session_store :csrf_cookie_store, key: '_xxxxx_id', httponly: false на session_store.db.
2. Создайте csrf_cookie_store в lib и загрузите его в application.rb с require 'csrf_cookie_store',
3. Задавать protect_from_forgery with: :exception на application.rb.
4. Создайте TokenController для обработки проверки.
5. TokenSerializer, чтобы только электронная почта отправлялась обратно.
6. Обновите контроллер Devise Session, чтобы изменить токен при входе в систему и пропустить проверку токена аутентификации при уничтожении сеанса.
7. Проверьте свои маршруты, чтобы токены были только созданы и имели пользовательский сеанс Devise.
8. Создайте модель токена Ember.js
9. Сопоставьте свой SessionAccount с тем, что я создал.
10. Обновите свой Devise Authenticator, чтобы отправить запрос на удаление на сервер, когда сеанс аннулируется.
11. Проверьте это.