1

我正在以编程方式部署 Java Websocket 端点（JSR356 3.1），我希望它验证Origin请求标头值以减轻 CSRF 攻击，并且只接受Host与Origin标头值匹配的握手请求。

在我看来，要走的路是覆盖方法：

ServerEndpointConfig.Configurator.checkOrigin(String originHeaderValue)

（Tomcat 8提供的实现总是返回true），但我看到的问题是这个方法只有一个参数，我错过了主机头值来比较这个值。

此外，此类不提供任何返回此信息的方法，因此我认为此方法无用，除非您将原始标头值与先前已知的主机值或值集进行比较，但这也没有任何意义，因为我的应用程序可以在不同的、不断变化的主机名或 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 端点放置在 servlet 堆栈后面的服务提供者（如 Tomcat，其中 Websocket 机制由 servlet 过滤器触发org.apache.tomcat.websocket.server.WsFilter），您可以创建一个外部过滤器，以启用对请求的线程本地访问，以便使用它在checkOrigin()方法中获取Host标头值。

这让我想知道为什么这种类型的检查不是白名单解决方案的首选，并且刚刚发现了这个有趣的帖子：Origin and Host headers for same domain requests

于 2016-02-15T16:27:25.583 回答