安全

我们很谨慎的对待DWR的安全问题，并且认为有必要解释一下避免错误要做的事情。

首先DWR让你明确哪些是被远程调用的，是如何被远程调用。原则就是DWR必须调用那些你明确允许的代码。

dwr.xml要求你为每一个远程类定义一个'create'项。你还可以通过指定include和exclude元素来更精确的控制远程调用Bean中可以被调用的方法。

除此之外如果你希望允许DWR在转换你的JavaBean到Javascript或者从Javascript转换到JavaBean时有一定的许可限制，同样可以精确控制哪些Bean的属性可以被转换。

一个很明显但又必须指出的 – 不要在生产环境中打开test/debug模式控制台。如何打开或关闭debug控制台在配置web.xml部分可以找到详细描述。

审查 - DWR带来的最大好处

很值得对比一下DWR和Servlet、JSP或周围的其他web框架。

如果你要审查基于DWR的功能，那是非常简单的。看看dwr.xml你就能得到一个哪些方法被暴露到外面的描述了。你也可以俯视全局用DWR可以访问哪些资源。

但是要在其他系统里做这件事可不是这么容易。如果是Servlet你需要检查WEB-INF/web.xml文件，然后检查写在Servlet中的request.getParameter(...)。如果是Struts和其他Framework你需要检查配置文件，然后顺着流程检查代码，看请求信息出了什么问题。

DWR允许你通过两种基于J2EE的机制来进行访问控制。首先你可以基于J2EE角色定义DWR的访问。其次你可以在DWR里面定义访问方法的角色。

DWR不允许你定义任何内部类的create和convert。这样设计是为了不出现意外的攻击来操作DWR的核心文件以提升访问权限。

有什么机会可以让攻击者窥视你的系统呢？使用DWR你攻击者可以使服务器创建任何你在dwr.xml中指定的Java对象的实例。并且(如果你用BeanConverter)Java类的任何方法、以及方法任何参数都是可见的。这些类的任何一个属性都有可能是攻击者需要的。

如果你知道DWR是怎么工作的，这些都是很显而易见的结论，但是往往粗心会造成问题。如果你创建了一个有appendStringToFile()方法的FileBean的类，而且用DWR把它暴露出去，那么你就给了攻击者一个机会来填满你的文件系统。

你必须时刻注意用了DWR以后，有没有给攻击者什么机会。

一般来说这样的情景让人感觉使用DWR是有风险的，但是这样的问题在所有的传统web架构中都存在，只是在那些架构中这些不明显，所以就很难被修复。

这已经很安全了，那么你还能做什么来保证更加安全了？首先记住上面这些关于审查的内容，当web应用的其他地方不安全时，即使它看上去很安全，过多的关注DWR是很愚蠢的。如果DWR让人感觉恐惧，那是因为它的问题都在明处。所以第一步是多检查几遍传统架构的问题。

你可以通过把可远程访问的类放到不同的包里，并且使用代理来防止DWR访问机制出问题。如果你愿意还可以再次检查基于角色的安全控制。这些内容只是在检查DWR已经为你做的事情。

比多检查几次更好的方法是检查DWR的源码，保证它是在正确的工作。这些代码已经被很多人检查过了，但多双眼睛总是有好处的。

DWR可以整合Acegi security framework。更多的信息见整合DWR和Acegi.

尽管我们很谨慎的对待DWR的安全，但是我们不能声称DWR是绝对安全的，如果这样做是很愚蠢的。你的web站点的安全是你的责任。DWR可以通过在开源授权下提供源码来帮你，你可以自己研究，我们鼓励你这样做，并且很多已经这样做了。