Rails はデフォルトでリクエストをCSRF
保護していないことを理解しています。HTTP GET
ただし、これらの GET 要求からユーザーに返される機密情報があり、悪意のあるサイトがこの情報を取得することは望ましくありません。
RailsHTTP GET
からのリクエストを保護する最良の方法は何ですか?CSRF
Rails はデフォルトでリクエストをCSRF
保護していないことを理解しています。HTTP GET
ただし、これらの GET 要求からユーザーに返される機密情報があり、悪意のあるサイトがこの情報を取得することは望ましくありません。
RailsHTTP GET
からのリクエストを保護する最良の方法は何ですか?CSRF
CSRF攻撃の要求に対する応答を読み取ることができるようにするには、攻撃者は被害者にJavaScriptコードを実行させる必要があります。その場合、アクセスは同一生成元ポリシーによって制限されます。
攻撃リクエストが実際にクロスオリジンであると仮定すると、DOMの同一生成元ポリシーはDOMを介したアクセスを禁止し(たとえば、を使用して埋め込まれた場合iframe
)、クロスオリジンリソースシェアリング(CORS)はXMLHttpRequestを介したクロスオリジンリクエストを次のように規制します。
リクエストが単純なクロスオリジンリクエストの場合、i。e。単純なヘッダーフィールドのみを使用する単純なメソッドの場合、その要求が送信されます(これはHTMLベースのCSRFに似ています)。ただし、単純なクロスオリジンリクエストのレスポンスにアクセスできるかどうかは、レスポンスでリソース共有が許可されているかどうかによって異なります。
他のクロスオリジンリクエストでは、実際のリクエストが送信される前に、いわゆるプリフライトが必要です。そのリクエストは、プリフライトの送信元のオリジンからのリクエストをサーバーが許可するかどうかを確認するために送信されます。また、プリフライトが成功し、実際の要求への応答でリソース共有が許可されている場合にのみ、応答にアクセスできます。
結論として、サーバーがCORSをサポートし、他のオリジンとの共有を明示的に許可しない限り(つまり、Access-Control-Allow-Origin: *
)、CSRF応答は、要求が許可されていたとしても、攻撃側のサイトで読み取ることはできません。