Session Error(DWR)

DWR Session Error封面

引言：一个看似诡异的 Session Error

那是 2014 年初的一个普通工作日。我们的一个基于 DWR（Direct Web Remoting）构建的 Web 项目突然出现了奇怪的问题 —— 前台页面毫无征兆地弹出了一个 “Session Error” 的对话框，而与此同时，后台控制台则疯狂地打印着错误日志：

1 2	2014-2-23 11:58:53 org.directwebremoting.util.CommonsLoggingOutput error 严重: A request has been denied as a potential CSRF attack.

“跨站请求伪造攻击？” 看到这条日志的第一反应是紧张。难道系统遭到了安全攻击？但很快我就排除了这种可能 —— 这是一个内部管理系统，而且问题是在没有任何外部干扰的情况下突然出现的。

经过几个小时的排查和分析，我终于找到了问题的根源。这篇笔记记录了整个问题的分析过程和解决方案，希望能帮助到遇到同样问题的开发者。

什么是 DWR？

在深入问题之前，先简单了解一下 DWR 是什么。

DWR（Direct Web Remoting） 是一个开源的 Java 库，它允许浏览器中的 JavaScript 代码直接调用服务器端的 Java 方法。简单来说，它让前端的 JavaScript 可以像调用本地函数一样调用后端的 Java 方法，而不需要手动编写繁琐的 AJAX 请求代码。

在 2014 年前后，DWR 在企业级 Java Web 开发中非常流行，特别是在那些需要大量前后端数据交互的场景中。

问题分析：CSRF 保护机制

错误日志解读

控制台输出的关键信息是：

A request has been denied as a potential CSRF attack.

这句话翻译过来就是：请求被拒绝，因为可能存在 CSRF（Cross-Site Request Forgery，跨站请求伪造）攻击。

什么是 CSRF？

CSRF 是一种网络安全攻击方式。攻击者通过诱导用户在已登录的状态下访问恶意网站，利用用户的身份认证信息向目标网站发送未经授权的操作请求。比如，你在银行网站登录后没有退出，攻击者让你点击一个链接，这个链接实际上是在银行网站上执行转账操作。

为什么 DWR 会误判？

DWR 从 2.0 版本开始内置了 CSRF 保护机制。默认情况下，它会检查请求的来源域（Domain），如果请求不是从同一个域发起的，就会被拒绝。

在我们的场景中，页面 URL 可能是被一个跨域的服务所调用，或者是在某些代理、负载均衡器的环境下，请求的来源域信息被改变了，导致 DWR 误判为潜在的 CSRF 攻击。

CSRF攻击原理示意

解决方案

方法：配置 crossDomainSessionSecurity

在 web.xml 配置文件中，找到 DWR 的配置部分，加入 crossDomainSessionSecurity 参数：

<servlet>
    <servlet-name>dwr-invoker</servlet-name>
    <servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
    <init-param>
        <param-name>crossDomainSessionSecurity</param-name>
        <param-value>false</param-value>
    </init-param>
</servlet>

参数说明

参数名	默认值	说明
`crossDomainSessionSecurity`	`true`	`true` 表示禁止其他域发送请求；`false` 表示允许跨域请求

重要提醒：将 crossDomainSessionSecurity 设置为 false 能够解决跨域请求被拒绝的问题，但这样做在安全性上会有一些冒险。因为这意味着 DWR 不再验证请求的来源域，任何域都可以向你系统的 DWR 接口发送请求。

安全性评估

如果你的系统满足以下条件之一，关闭跨域安全保护的风险是可控的：

系统是内网部署的，外部无法直接访问
有其他层面的安全防护措施（如 Token 验证、签名校验等）
DWR 接口只执行只读操作（查询类操作）

但如果你的系统暴露在外网，且 DWR 接口包含写操作（增删改），建议采用更安全的方式，比如：

使用 CSRF Token 机制
配置严格的 CORS 策略
升级 DWR 到更高版本，使用更安全的替代方案

延伸思考：CSRF 防护的现代方案

回看 2014 年的这个问题，CSRF 防护技术在过去十年中已经有了很大的发展。以下是一些现代 Web 应用中常用的 CSRF 防护方案：

1. Synchronizer Token Pattern（同步令牌模式）

这是最经典的 CSRF 防护方式。服务器在表单中嵌入一个随机生成的 Token，在提交时验证该 Token 是否匹配。

现代浏览器支持在 Cookie 中设置 SameSite 属性：

1	Set-Cookie: sessionId=abc123; SameSite=Strict

Strict：完全禁止跨站请求携带 Cookie
Lax：允许顶层导航（如点击链接）时携带 Cookie，但禁止跨站 POST 请求

在请求头和 Cookie 中同时发送 CSRF Token，服务器比对两者是否一致。

踩坑总结

回顾这次问题的排查过程，我有几点体会想分享：

第一，不要被错误信息吓到。 看到 “CSRF attack” 这样的字眼很容易让人紧张，但要保持冷静，分析这是否是真正的安全攻击还是框架的保护机制误判。

第二，理解框架的默认行为很重要。 DWR 默认开启了跨域安全保护，这是框架的安全设计理念。遇到问题时，先理解框架为什么这样设计，再决定是否要修改默认行为。

第三，安全性与便利性的权衡。 关闭安全保护可以解决问题，但一定要评估潜在的风险。在实际工作中，我见过太多因为”图方便”而关闭安全措施，最终导致安全事件的案例。

参考资料

原始问题的讨论可以参考：
http://my.oschina.net/u/566829/blog/81935

这篇笔记记录于 2014 年 4 月，是我在排查 DWR Session Error 问题时的心得总结。一个看似诡异的问题，背后其实是框架的安全保护机制在工作。理解这些机制，不仅能帮助我们快速定位问题，更能让我们对 Web 安全有更深的认识。技术之路，就是不断地在问题中成长。