@Consumes（MediaType.JSON）のようなアノテーションを持つRESTful APIがあります-その場合、CSRF攻撃はそのようなサービスでも可能ですか？サーバー側でCSRFGuardを使用してサービスを保護するか、クライアント側から二重に送信するように調整してきました。ただし、フォームをenctype = "text / plain"で使用してリクエストをPOSTしようとすると、機能しませんでした。テクニックはここで説明されていますこれは、consumesアノテーションにMediaType.APPLICATION_FORM_URLENCODEDがある場合に機能します。コンテンツネゴシエーションは、POST / PUT / DELETE動詞を使用している場合に役立ちますが、GETには引き続きアクセスできるため、調査が必要になる場合があります。
任意の提案や入力は素晴らしいでしょう、またあなたがより多くの情報が必要な場合は私に知らせてください。
乾杯
JAX-RS は、ステートレスであると想定される REST API を作成するように設計されています。クロス サイト リクエスト フォージェリは、ステートレス アプリケーションでは問題になりません。
クロス サイト リクエスト フォージェリのしくみは、誰かがあなたをだましてリンクをクリックさせたり、ブラウザーでリンクを開いたりして、ログインしているサイト (オンライン フォーラムなど) に誘導することです。あなたはすでにそのフォーラムにログインしているため、攻撃者は次のように URL を作成できます: someforum.com/deletethread?id=23454
そのフォーラム プログラムは、設計が悪いため、セッション Cookie に基づいてユーザーを認識し、スレッドを削除する権限があることを確認し、実際にそのスレッドを削除します。
すべては、プログラムがセッション cookie に基づいてユーザーを認証したためです (「remember me」cookie に基づいても)。
RESTful API では Cookie がなく、リクエスト間で状態が維持されないため、セッション ハイジャックから保護する必要はありません。
RESTFul api で通常認証する方法は、追加のヘッダーを送信することです。RESTful API を指す URL をクリックするようにだまされても、ブラウザは余分なヘッダーを送信しないため、リスクはありません。
要するに、REST API が想定どおりに設計されている場合、ステートレスであれば、クロスサイト フォージェリのリスクはなく、CSRF 保護の必要もありません。
Dmitri の回答に別の回答を追加すると、サーバー側の状態と Cookie が混在します。
サーバーが複数の要求でユーザー情報をメモリに保存する場合、アプリケーションはステートレスではありません。これにより、リクエストごとに「正しい」サーバーを見つける必要があるため、水平方向のスケーラビリティが低下します。
Cookie は特別な種類の HTTP ヘッダーです。多くの場合、ユーザー セッションを識別するために使用されますが、すべての Cookie がサーバー側の状態を意味するわけではありません。サーバーは、セッションを開始せずに Cookie からの情報を使用することもできます。一方、他の HTTP ヘッダーを使用しても、アプリケーションが自動的にステートレスになるとは限りません。ユーザーデータをサーバーのメモリに保存する場合、そうではありません。Cookie と他のヘッダーの違いは、ブラウザーによる処理方法です。私たちにとって最も重要なことは、ブラウザーが後続のすべての要求でそれらを再送信することです。これは、誰かがユーザーを騙して、ユーザーが望んでいないリクエストを行う場合に問題になります。
これは、JSON を使用する API の問題ですか? はい、次の 2 つの場合です。
enctype=text/plain: URL エンコードされたコンテンツは、結果が有効な JSON にならないため問題ありません。text/plainサーバーがコンテンツをプレーンテキストではなく JSON として解釈する場合、これは問題です。リソースに注釈が付けられている場合、それは受け入れられず、 status を返す必要@Consumes(MediaType.JSON)があるため、問題はないはずです。(JSON はいつか有効な enctype になる可能性があり、これはもはや有効ではないことに注意してください)。text/plain415Access-Control-Allow-Origin: *。