我正在使用遗留的Java应用程序（13yrs +），它没有防止CSRF攻击的机制。
在前端，它使用多种技术，dwr，jquery和请求来自各种来源，AJAX，形式汇总帖子，获取请求。使用应受CSRF保护的Get请求进行非安全操作。
在后端，一切都通过Struts Actions。
没有适当的自动化功能测试，应用程序非常庞大，没有人知道它是如何工作的，因此无法轻易引入更改。
要更改应用程序以向每个get-link和每个表单提交添加秘密令牌将非常困难。对于DWR和jquery，事情更简单，因为所有请求都有一个入口点。
应用程序不需要使用浏览器书签，在内部它提供了一个收藏夹菜单，它保留了特定于它的书签。 此外，表单操作或链接的URL始终通过struts或标准taglib呈现。因此，如果我将JSESSIONID更改为通过url重写而不是cookie，那么应用程序可能会进行微小的更改......
这给了我以下想法，即在没有大量开发工作的情况下为应用程序引入CSRF保护：
*使用URL重写代替cookie来传递JSESSIONID。 *为了克服在标题中显示JSESSIONID的问题，为http会话引入了第二个秘密cookie。因此，在首次建立会话时，将包含随机值的HttpOnly cookie发送回客户端，并将其也放入HTTP会话中。 *在所有struts Actions的父级中，检查此秘密cookie的值与HTTP会话中的值，如果不相等则抛出异常。
与在每个请求中重写应用程序以引入令牌的巨大努力相比，这似乎是一种简单的方法。也许太容易了......我的想法是不是有点了？
答案 0 :(得分：0)
在上一篇文章中，我考虑将jsessionid用作带有Url重写的csrf令牌，并使用第二个自定义HttpOnly cookie进行身份验证。 但最后我决定：
不使用jsessionid作为csrf令牌，但保留它进行身份验证，因为它是默认设计的。
使用Origin标头保护表单提交和ajax调用。这不包括执行非安全操作的获取请求。此外，它仅适用于较新的浏览器。
使用csrf令牌保护获取请求。应用程序中的URL由标签c：url，html：rewrite组成，因此只需用自定义的标签覆盖这些标签，该标签包含csrf标记。