GWT&x27；s内置XSRF保护

关于这一点，我有几个问题：

• 一般来说，XSRF对于最新的浏览器仍然是一个问题吗？据我所知，默认情况下已禁用跨域请求，现在通过CORS进行控制。当人们使用过时的浏览器时，浏览器中可能存在很多安全漏洞，所以XSRF无论如何都不重要。顺便说一下，XSRFTKEnServServices类仍然被标记为不用于生产，因此GWT DEVS似乎认为这不是一个重要的问题，或者不相信他们自己的实现。
• 其次，GWT使用servlet创建XSRF令牌。通过返回（哈希）JSSESSID，这不会引入明显的攻击向量吗？我认为您之所以使用XSRF，正是因为攻击者不知道JSSessionID，只是让您的浏览器将其与请求一起发送。现在，该请求返回它的关键散列，他可以用它来假装知道JSESSIONID。我这里出了什么错？难道不应该在客户端独立于服务器对JSESSIONID进行散列，以证明客户端实际上可以读取JSESSIONID cookie吗？这在从其他站点加载的页面调用站点时是不可能的

---

毫无疑问，现代浏览器使攻击变得更加困难，但每个浏览器都会出现bug。至于第二部分，如果令牌是一个简单的散列，没有密钥或只有服务器知道的特殊salt，那么客户端可以在窃取会话id时重新创建它（这就是为什么让客户端进行散列是一个坏主意）。客户端不需要重新创建它。它被发送到客户端，以便客户端可以在将来的请求中识别自己。。。从未提到客户端需要重新创建它。我只是说，如果客户端知道会话id就可以重新创建会话，那么它确实有点违背了它的目的，因为从其他站点泄漏cookie数据的bug是人们寻找漏洞的主要目标。XSRF令牌本身从来不会持久地存储在任何地方，因此只有当您合法地访问该页面时，您才会读取它。这不是真的。xsrf令牌是从jsessionid生成的，因此它实际上存储为cookie。您只需应用md5总和。