使用 Tomcat 和 Apache 进行 CRSF 令牌和会话复制
我有一个符合 J2EE 的 Web 应用程序。我使用基于会话的令牌将辅助 ID 附加到我的应用程序生成的所有传入链接。为了防止我的应用程序受到 CSRF 攻击，我在允许用户会话在后续页面上工作之前验证辅助 ID。
最近，在使用会话复制机制实现时，我观察到在会话故障转移时，生成的辅助 ID 会丢失，并且用户会被重新定向到登录页面/默认页面。
关于如何确保我生成的辅助令牌 id 不会从复制会话中丢失，有什么建议吗？
I have an J2EE compliant web application. I use a session based token to append a secondary id to all incoming link generated by my application. To prevent my application against CSRF attack, I validate the secondary id before I allow the user session to work off the subsequent page.
Recently, while working with session replication mechanism implementation, I observed that on session failover, the generated secodary id is lost and the user get re directed to the login page/default page.
Any suggestions on how I can ensure that the my generated secondary token id is not lost from the replicated session?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
表示令牌的对象应该实现 java.io.Serialized 以便在会话要作为二进制流（通过网络、磁盘文件系统等）存储/读取/传输时继续存在在会话复制和故障转移机制中。
这通常已经在相关机制的文档中明确提及。我建议再次阅读它，以确保您涵盖了使复制/故障转移完美运行的所有内容。
以下是有关该主题的 Tomcat 6.0 文档 的摘录，来自集群基础知识一章：
The object representing the token should implement
java.io.Serializableto survive whenever the session is to be stored/read/transferred as binary stream (over network, on the disk file system, etc) as would occur in session replication and failover mechanisms.This is usually already explicitly mentioned in the documentation of the mechanism in question. I'd suggest to read it once again to be sure that you covered everything to get the replication/failover flawlessly to work.
Here's an extract of the Tomcat 6.0 documentation regarding the subject, from the chapter Cluster Basics:
简单的辅助令牌只能提供有限的针对 CSRF 攻击的保护。对于我们自己的框架 (pulse)，我们决定通过在 URI 上生成自定义哈希代码来对每个 URL 进行签名：然后用会话存储的秘密（开箱即用的可序列化的 Long）加盐，然后用 SHA-256 进行消化。
这样，当秘密添加到 URI 时就不会暴露。整个过程很容易通过注释（@RequireToken）控制
A simple secondary token will only provide limited protection against CSRF attacks. For our own framework (pulse) we decided to sign each URL by generating a custom hash code on the URI which is then salted with session stored secret (a Long which serializable out of the box) before being digested with SHA-256.
This way the secret is not exposed when it's added to the URI. The whole process is easily controlled by an Annotation (@RequireToken)