6

Spring WebFlow 2でビルドされたアプリケーションにCSRF保護を追加する（うまくいけば簡単な）方法を探しています。

Spring WebFlow 3（リリースされた場合）に適切に移行するアプローチが推奨されます。

4

2 に答える 2

4

CSRFを防ぐ最も簡単な方法は、リファラーをチェックしrequest.getHeader("referer");て、リクエストが同じドメインからのものであることを確認することです。この方法は、 CSRF防止に関するチートシートでカバーされています。

このCSRF保護システムは、メモリ要件が制限された組み込みネットワークハードウェアでよく見られますが、モトローラはほとんどのハードウェアでこの方法を使用しています。これは最も安全なCSRF保護ではなく、トークンベースの保護の方が優れていますが、両方のシステムをxssでバイパスできます。トークンベースのCSRF保護の最大の問題は、すべてのリクエストに戻って修正するのに多くの時間がかかり、おそらくいくつかのリクエストを見逃してしまうことです。

これを実装する安全な方法は、すべての着信POSTリクエストでリファラーをチェックし、パスワードの変更、ユーザーアカウントの追加、コードの実行、構成の変更などの機密性の高い機能にPOSTを使用することです。GETは、ナビゲーションまたは検索にのみ使用する必要があります。基本的に、GETは、状態の変化を引き起こさないものに対して安全です。

必ずxssスキャナーでサイトをテストしてください。

于 2010-05-04T19:57:52.527 に答える
2

OWASPには、CSRF攻撃を防ぐための優れたガイドがあります。

リファラーヘッダーをチェックするのは確かに最も簡単であり、少なくともリファラーがサードパーティであるか空のインスタンスをログに記録することをお勧めします。ただし、リファラーだけを使用することを信頼できないものにするいくつかの欠点があります。

  • 企業のファイアウォールは、プライバシー上の理由からリファラーヘッダーを削除する可能性があります
  • HTTPSからHTTPに移行する場合、リファラーは送信されません
  • CFRF攻撃では、一般にリファラーを「偽造」することは困難ですが、メタリフレッシュタグを使用して行うことができます。

幸い、WebFlowを使用すると、カスタムの一意のフローごとのトークン呼び出しCSRFフィルターを簡単に実装できます（ビュー/フォームを変更する必要がない場合があります）。

まず、FlowExectionListenerを使用して、フローが開始するたびに新しいランダムトークンを作成し、それをflowScopeに格納します。次に、イベントが通知されるたびに、送信されたトークン（リクエストのパラメーターとして送信された）がflowScopeに格納されている値と等しいことを確認します。

次に、生成されたURLに「_token」パラメーターを追加するカスタムFlowUrlHandlerを構成します。これにより、フローを参照するために$ {flowExecutionUrl}を使用している場合、フローにPOST/GETするたびにトークンが追加されます。FlowUrlHandler内からflowScopeからトークンをフェッチするには、RequestContextHolderを使用する必要がありました。

 private String retrieveToken() {
    RequestContext requestContext = RequestContextHolder.getRequestContext();
    if (requestContext == null) {
        return null;
    }
    return (String) requestContext.getFlowScope().get(CsrfTokenFlowListener.TOKEN_NAME);
}
...

このメソッドには、GETとPOSTの両方で$ {flowExecutionUrl}を出力するたびにCSRFトークンが含まれます。また、post-redirect-getを使用している場合は、CSRFトークンがURLバーに表示されないようにすることができます。

POSTのCSRFトークンのみをチェックしないように注意します。

WebFlowや他の多くのWebフレームワークは、GETとPOSTを区別しません。デフォルトでは、リクエストメソッドを自分で確認しない限り、通常、GETを使用してPOSTで行うことは何でもできます（とにかく良いアイデアです）。したがって、CSRFフィルターをバイパスしたい攻撃者は、POSTではなくGETを実行するだけです。

編集： $ {flowExecutionUrl}にCSRFトークンを含める際に注意すべき1つの欠点は、CSRFトークンが常にリクエストURLの一部として送信される可能性があることです（HTMLフォームの「action」属性の一部であるため）。そして、POST本文には決してありません。サーバー/ISPログに記録される可能性が高いため、要求URLに機密情報を含めることは適切ではありません。別の方法は、CSRFトークンを含む各フォームに非表示の入力を追加し、POSTリクエストに対してのみその存在を強制することです。

于 2011-11-10T17:13:54.863 に答える