5

Railsアプリと通信するためにRESTとOAuthを使用しています(iPhoneアプリからですが、それは関係ありません)。ただし、Rails の CSRF 保護 (経由protects_from_forgery) でいくつかの問題が発生しています。

CSRF 保護は通常のフォーム送信 (つまり、Content-Type=application/x-www-form-urlencoded) に対してのみ有効であることを理解しているため、JSON または XML データを送信する場合は問題ありません。残念ながら、OAuth は現在 application/x-www-form-urlencoded リクエストに限定されています。OAuth を非フォーム urlencoded データに拡張するドラフト仕様がありますが、これは今のところ役に立ちません。

私の見方では、次のオプションがあります。

  1. OAuth署名の一部ではないため、中間者攻撃の対象になることを認識して、データをJSONとして送信します。明らかに魅力的なソリューションではありません。

  2. UsersController#update_oauth通常のアクション (例 ) に内部的にデリゲートする特別な Rails アクション (例 ) を作成しますUsersController#update。次に、これらを偽造防止から除外します ( protects_from_forgery :only => [:update])。これは機能するはずであり、1 つまたは 2 つのアクションの境界線として許容される可能性がありますが、明らかに非常に厄介なソリューションになります。

  3. Rails CSRF 保護をオーバーライドして、OAuth リクエストを無視します。verify_authenticity_token私はこれを試していませんが、フックの 1 つ (おそらくフィルター) を変更して、OAuth 要求が成功したと見なすことができるように思われます。

誰もこれに遭遇したことがありますか？推奨事項はありますか？それとも、基本的な何かが欠けているのでしょうか?

4

1 に答える 1

5

私は自分の質問に答えます。:)

OAuth コントローラー拡張機能に次のメソッドを追加しました。これがデフォルトの実装の上に追加する唯一のものはoauth?チェックです。これはうまくいくようで、かなりきれいな解決策のように感じます。

def verify_authenticity_token
  verified_request? || oauth? || raise(ActionController::InvalidAuthenticityToken)      
end
于 2009-12-03T20:28:28.133 に答える