1

Java Websocket エンドポイント (JSR356 3.1) をプログラムでデプロイしていますがOrigin、CSRF 攻撃を軽減するためにリクエスト ヘッダー値を検証し、ヘッダー値と一致するハンドシェイク リクエストのみを受け入れるようHostにOriginしたいと考えています。

進むべき道はメソッドをオーバーライドすることだと私には思えます:

ServerEndpointConfig.Configurator.checkOrigin(String originHeaderValue)

(Tomcat 8 によって提供される実装は常に を返しますtrue)、しかし、私が見る問題は、このメソッドには 1 つのパラメーターしかなく、この値を比較するためのホスト ヘッダー値を見逃していることです。

また、このクラスはこの情報を返すメソッドを提供しないため、元のヘッダー値を以前に既知のホスト値または値のセットと比較しない限り、このメソッドは役に立たないと思いますが、これも意味がありません。私のアプリケーションは、ホスト名または IP が変化する別の場所で表示される可能性があります。

すべてのヘッダー値を読み取ることができる実装内でこの検証を実行することを検討していmodifyHandshake(ServerEndpointConfig sec, HandshakeRequest request, HandshakeResponse response)ますが、何かを誤解していると確信しています。

だから私の質問は：

この検証を実行する適切な方法は何ですか?

ありがとう、ナチョ

4

1 に答える 1

1

問題をもう少し掘り下げた後、Websocket API (JSR-356) は、定義済みの一連の許可されたオリジンである「ホワイト リスト」に対してオリジン チェックを実行するように設計されていると結論付けました ( Weblogicのこの例でわかるように)。):

 ...
 import javax.websocket.server.ServerEndpointConfig;

 public class MyConfigurator extends ServerEndpointConfig.Configurator {
 ...  
     private static final String ORIGIN = "http://www.example.com:7001";

     @Override
    public boolean checkOrigin(String originHeaderValue) {
        return ORIGIN.equals(originHeaderValue)   
    }
 }
 ...

残念ながら、この API はHostvsOriginヘッダー検証を実装する可能性を考慮していません。

回避策として、Websocket エンドポイントをサーブレット スタックの背後に配置するサービス プロバイダー (Websocket 機構がサーブレット フィルターによってトリガーされる Tomcat などorg.apache.tomcat.websocket.server.WsFilter) の場合、使用するために、リクエストへのスレッドローカル アクセスを有効にする外部フィルターを作成できます。ヘッダー値checkOrigin()を取得するメソッドでそれを使用します。Host

これは、なぜこのタイプのチェックがホワイト リスト ソリューションよりも優先されないのか疑問に思い、興味深い投稿を見つけたところです: Origin and Host headers for same domain requests

于 2016-02-15T16:27:25.583 に答える