1

Is it possible to implement Rails csrf through cookie_store at the same while using ember-simple-auth Devise?

Guides like this one always deactivate Rails.application.config.session_store which from my understanding does not allow Rails to keep track of csrf tokens which causes Rails to lose track of sessionsg. After attempting many solutions including:

  1. require jquery_ujs on Rails manifesto.
  2. Rails.application.config.session_store :disabled.
  3. https://github.com/abuiles/rails-csrf.
  4. Changing Ember.js Adapter to append CSRF.

The end result is still pretty much the same:

Can't verify CSRF token authenticity followed by Completed 422 Unprocessable Entity if protect_from_forgery is set with :exception instead of :null_session.

Example Transaction:

Partial Request HEADER:

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

Responder 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="

The rails-csrf response from my csrf branch (branch has been deleted).

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

Partial dump of the return statement:

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

From my understanding, all of these attempted solutions have the common root: session_store is disabled...

4

1 に答える 1

1

アップデート！

以下の回答は、CSRF 保護と Ember-Cli-Rails についてさらに学習した後、本質的に間違っていることが判明しました。

ここでのアイデアは、2 つのストレージを用意することです。Rails によって維持される csrf トークン専用の Cookie ベースのストレージと、Ember-simple-auth によって維持される localStorage であり、ユーザー認証トークン、電子メール、および ID が処理されます。カスタム セッション SessionAccount はこれらの値を継承し、サーバーに対して検証してから、Ember.js 全体で使用できるユーザーを設定します。

localStorage の改ざんを検出するために、SessionAccount による検証が行われます。検証は、トークン モデル (トークン、電子メール、および ID) を介してサーバーと通信する際に、SessionAccount が localStorage にクエリを実行する (ページのリロードなど) たびに発生します。サーバーは、電子メールまたは検証のみをレンダリングする TokenSerializer を介して 200 または 404 で応答します。エラー、したがって、ユーザーが電子メールとパスワードを必要とするログインフォームからサインインしない限り、他の authentication_tokens を表示するためにフロントエンドを開示しません。

私の理解では、この方法論の弱点は、次の場合を除き、簡単にハッキングできるほど影響を受けません。

  • 誰かがサーバーに侵入し、データベースのコンテンツを取得します。パスワードはソルト化されていますが、データベース ダンプを持っている人は誰でも localStorage トークン、電子メール、ID を偽装したい人に変更でき、サーバーの検証が機能します。ただし、これは、24 時間ごと (またはその他の時間枠) にログインしていないユーザーの認証トークンを変更するワーカーによって最小限に抑えることができます。コード例のセクションには、まだワーカーについて学習していないため、現時点ではワーカーがありません。
  • ハッキングしようとしている人のパスワードとメールアドレスを知っている人がいます。
  • JSON API を介して渡されるデータを誰かが傍受します。強力な SSL 実装はうまく機能するはずです。
  • sessionAccount の行に is_Admin がある場合、フロントエンドを信頼できないため、さらにバックエンドを検証するために、管理者のみのリクエストの POST リクエストと一緒にトークンを送信できます。
  • 他の何か？それらは私が知っているものです。

次に、実際のアプローチに進みます。

  1. session_store.dbに設定 Rails.application.config.session_store :csrf_cookie_store, key: '_xxxxx_id', httponly: falseします。
  2. lib の下にcsrf_cookie_storeを作成し、application.rb で require 'csrf_cookie_store'.
  3. application.rbに設定protect_from_forgery with: :exceptionします。
  4. Validation を処理するTokenControllerを作成します。
  5. TokenSerializerを使用して、電子メールのみが返送されるようにします。
  6. Devise セッション コントローラーを更新して、ログイン時にトークンを変更し、セッションの破棄時に認証トークンの検証をスキップします。
  7. ルートを確認して、トークンが作成され、カスタムの Devise セッションが作成されるようにします。
  8. Ember.jsトークン モデルを作成する
  9. あなたのSessionAccountを私が作成したものと一致させてください。
  10. セッションが無効化されているときにサーバーに削除リクエストを送信するように、 Devise Authenticatorを更新します。
  11. テストしてみてください。
于 2016-03-21T04:56:02.670 に答える