翻訳自分で読むため、許可は取ってない
用語定義
SPAとはJavascriptのフレームワーク(vueとか)でページをレンダリングし、残りの通信はバックエンドapi(railsとか)でする事
ユーザーがアクティブなセッションで認証されているサーバーにユーザーのブラウザに要求を送信させるサードパーティに対する保護としてのCSRF攻撃保護
Ruby on Railsセキュリティガイドラインの例を引用
この例では削除アクションにGETリクエストを使用していますが、ガイドラインのリンクで詳しく説明されているように、悪意のあるWebサイトにPOSTまたはDELETEリクエストをこのように送信させることが可能です。
通常、「静的Webサイトからフォームを送信する」という文脈でCSRF攻撃保護が言及されています。私は最近、API呼び出しに関連するCSRF保護について詳しく読んでいましたが、さまざまなテクノロジのWeb開発者が言うのはあまりに一般的です。→「APIに対するCSRF攻撃保護は必要ありません。」
そのことを頭に入れて、通常彼らは、APIがブラウザ以外の他のクライアント技術(例えば、Android、iPhone、あなたのスマート冷蔵庫)によって使われることが予想されるアプリケーションについて話しています。しかし、通常この文脈ではブラウザセッションを使用しません。 しかし、ブラウザセッションを使用するアプリケーション(例:Devise Gemを使用しているRuby on Rails開発者)がいなくて、そのアプリケーションがAPIと通信している場合は、CSRF保護が必要です。
結論
アプリケーションがセッション/クッキーを使用する場合は、CSRF保護が必要です。他の形式の認証(前述のAWSがCognitoを介してリクエストに署名したようなもの)がある場合は、CSRF保護は必要ありません。
Ruby on Rails WebフレームワークでCSRF APIを処理する方法
Railsにはprotect_from_forgeryメソッドがあります。これはコントローラに配置でき、CSRFトークンが提供されていない限りPOST PUT PATCH DELETE呼び出しが発生しないようにします。
しかし問題はこのトピックがRails Helperを使ってCSRFトークンをレンダリングする静的サイトを扱っていると仮定していることです<<= = csrf_meta_tags%>
CSRFトークンをCookieに格納するようにバックエンドを設定し、その後FrontEndフレームワーク(Angular、React)がCookieから新しい値を取得するというソリューションを指している人々を見ました。
そのため、このようにしてhttp://www.webapp.com/project/1を削除する悪意のある要求がCSRF-TOKENなしで行われることになります=>は実行されません。
これを詳細に説明した良い情報源がすでにあるので、私は段階的なチュートリアルを書くつもりはないです:
https://technpol.wordpress.com/2014/04/17/rails4-angularjs-csrf-and-devise/ https://stackoverflow.com/questions/14734243/rails-csrf-protection-angular-js-protect-from-forgery-makes-me-to-log-out-on https://github.com/jsanders/angular_rails_csrf (gem solution) deep details how CSRF Rails protection work
- 一言doh。 RailsのCSRF保護はGET&HEADリクエストには適用されません。あなたが万が一GET http://www.webapp.com/project/1/destroyのような破壊的な行動を持っているのであれば、あなたはねじ込まれます。