DWR安全方面(网摘)

安全
我们很谨慎的对待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的源码，保证它是在正确的工作。这些代码已经被很多人检查过

了，但多双眼睛总是有好处的。