TOP 10 Web应用脆弱性之一：未经验证的输入
描述
Web 应用使用HTTP 请求(也许还有文件，也是一种特殊请求) 来进行输入，并决定如何进行响应。攻击者可以篡改HTTP 请求的任何部分，包括url，查询字符串（querystring）, headers, cookies, 表单字段（包括隐藏字段），试图绕过服务器的安全机制。常见的通用输入篡改攻击包括：
o 强迫浏览（forced browsing）；
o 命令注入（command insertion）；
o 交叉站点脚本（cross site scripting）；
o 缓冲区溢出（buffer overflows）；
o 格式字符串攻击（format string attacks）；
o SQL注入（SQL injection）；
o 有毒饼干（cookie poisoning）；
o 隐藏字段操作（hidden field manipulation），等等。
某些站点试图通过过滤恶意输入来保护自己。但问题是编码信息的方式无穷无尽。这些编码方式看起来并不是加密的，所以似乎也用不着解码。但是，开发人员仍然经常忘记将所有的参数在使用之前解码为最简单的形式。参数应该在其被校验之前转换为最简单的形式，否则，恶意输入就可能掩饰自己从而流过过滤器。简化这些编码的过程称为是“规格化（canonicalization）”。因为几乎所有的HTTP 输入都可以编码为多种格式，这种技术便可以打乱各种旨在利用和攻击上述弱点的攻击行为。这使得过滤非常困难。
有非常之多的web 应用仅使用客户端校验来验证输入。客户端校验机制是非常容易绕过的，这样就使得Web应用几乎对恶意参数的攻击毫无保护。攻击者可以使用攻击甚至telnet来产生他们自己的HTTP 请求。他们才不关心开发人员预定想要在客户端发生的时候事情呢。注意，客户端校验仅仅在提高性能和可用性方面有益，但是它毫无安全可言。因此，对于恶意参数攻击，服务器端校验是必须的。
这种攻击的数量在不断上升，因为有大量的支持参数的“模糊化”（“fuzzing”）、腐朽（corruption）、以及野蛮强制增长的工具出现。不应该低估了这些使用非校验输入进行攻击的影响。实际上如果开发人员能够在使用参数之前对其进行验证，就可抵挡大部分的攻击。因此，最好使用一个中心化的、强大的验证机制来对所有HTTP 请求的输入都进行验证，这样利用此弱点进行攻击的数量就会大减。
环境影响
所有web servers, application servers, 以及应用环境都容易受到这种参数篡改的攻击。
如何决定你的应用是否脆弱
一个Web应用所用的未经验证的HTTP请求的任何和部分都称为是“脏” 参数。找出脏参数的最简单的方式是进行最详细的代码评审，找出所有从HTTP请求提取信息的方法调用。比如，在J2EE应用中，这些包括HttpServletRequest 类（以及其子类）中的方法。然后你就可以循着代码查看参数变量是在哪里使用的。如果变量在使用之前未作验证，这可能就是一个潜在的问题。在Perl中，你因该考虑使用 “taint” (-T) 选项。
你也可以通过一些工具来找出脏参数，比如OWASP的 WebScarab。它们可以查看和评审通过HTTP/HTTPS的所有数据，并进行分析。
如何保护
保护很简单，那就是确保任何参数在被使用之前都进行了验证。最好的办法是使用一个中心化的组件库，比如Java中的Jarkarta Commons Validator.每个参数都演进行严格检查。涉及到过滤脏数据的“负面”方法或者依赖于签名的方法都不可能很有效率，并且难以维护。
参数应该进行“正向”规格的检查，正向规格（ “positive” specification ）的定义可包括：
- 数据类型(string, integer, real, 等)
- 允许的字符集
- 最大最小长度
- 是否允许null
- 是否必需
- 是否允许重复
- 数值范围
- 特定的法定值 (枚举)
- 特定模式(正则表达式)
* 本系列整理自 OWASP（Opensource Web Applicaiton Security Project ）
EXADEL Studio的3.0发布了，我个人认为这是eclipse平台的轻量IDE中比较好的了。M7的Nitrox不错，但是很贵哦。而且............加密做的不错，很难找到CRACK的。
从2.5版本开始，他就分为了标准版和Pro版，前者是免费的，后者收费。3.0Pro版本同样为＄99，可以说非常便宜了。而Nitrox同时支持JSF和Struts的版本居然是$699。
关于其新特征，可以查看：Pro版：http://www.exadel.com/products_exadelstudiopro.htm 标准版：http://www.exadel.com/products_exadelstudio.htm。
有几个特征值得一提：
导航图：
Tree视图编辑器：
特别是支持表达式的帮助：
这点非常不错，看好！
对Struts的支持，除了常规的导航流图，配置编辑，可视化验证，之类，还直支持TILES的可视化，这点有很大进步，但是和Nitrox比还是有些差距，后者能够支持JSP编辑器中的TILES WYSWYG效果。
还有个有趣的特征是Struts配置文件的Debug, 直接在图形上就可以设置断点。
另外的改进就是支持JSP 的WYSWYG编辑。
PRO版与标准版的支持在于对Hibernate 和Spring 的支持，以及JSP的可视化编辑。其中Hibernate 支持可视化MAP编辑。Spring 则是有Spring IDE提供，无新意。
哈哈，我决定在我后面的Spring 和struts的书中，以它作为演示工具。
Borland 最近宣布了将要升级JBuilder IDE的相关信息。基于Eclipse平台，Borland JBuilder 2006 将提供端对端的开发人员协作功能，以提高对标准的支持和生产力增强。但是这恐怕不是令大家关注的地方，大家感兴趣的还是Eclipse平台。
BEA公司也意图将其IDE Workshop的未来版本转向Eclipse平台，在加上IBM Websphere Studio(现在叫Rational Software Architect和Rational Application Developer)，似乎eclipse的势力在妄图一统天下。著名的Java IDE只剩下Oracle 的JDeveloper和IDEA了。但是实际上Java IDE 却是阴云密布，不容乐观。
基于Eclipse的 JBuilder，代号为Peloton。大约会在明年中期发布。它将会包含 JBuilder的可用性和协作特征，加上应用生命周期管理。
近两年Eclipse社区不断发展壮大，以致在Eclipse3发布的时候，疯狂下载造成服务器几乎瘫痪。因此，在Java IDE市场上， Eclipse估计占到20-30%的市场分额。.
因此，这种增长令商业的专用IDE厂商非常不安，前不久 Oracle终于宣布其JDeveloper向开发人员免费，仅对支持收费。就是一种无可奈何的反应。它们认为，Eclipse （包括商业和开源平台）的开发工具已经占据了50%的半壁江山，Oracle在J2EE方面一直不太理想，还不如让JDeveloper免费，也好做为Oracle Java的形象大使，赚回些关注。
但是实际上，Eclipse提供的是一个骨架平台，当然Eclipse本身也提供一些开源的Plugins,也有其他一些厂商在提供商业的插件支持，比如MyEclipse, Lomboz, Exadel等等。还有其它一些开源的专用插件，层出不穷。
因此，Eclipse-Based IDE实际上成为两种派系：OS和商业的。就商业来说，IBM是最嬉笑颜开的，Eclipse本身就是它鼎力支持的，从WSAD到RAD和RSA，IBM成功地将Rational 品牌产品和Websphere进行了整合，Rational体系如今专注软件开发生产和测试，而RAD和RSA则提供了业界最高标准的，包含基本IDE支持，标准支持，协作，软件生命周期（甚至集成了RUP），MDA等功能为一体的开发平台。
当然，基于Eclipse的商业IDE和开源IDE会否共存？答案当然是肯定的。最简单的原因就是，Java虽然是标准，但是厂商自有独门功夫，因此，IDE商业平台自然带有一定的专有性。如果是大型的企业应用，需要优化等等，则非商业IDE莫属。
另外一个就是Java本身的未来，轻量架构和方法的发展，比如如火如荼的IoC，MetaFramework等等，则又大大促进了开源IDE的发展。
因此，一定时期内，这两种肯定会共存。IDE的较量，背后还是AS和基础平台的较量。
Borland的未来核心是构建一个 Borland Core Software Delivery Platform (SDP), 也都基于Eclipse。JB只是其中一个组件。
SUN的IDE则有些尴尬，NetBeans 一直没什么人感兴趣。现在，SUN的另一个IDE， Java Creator则让人摸不清到底是何意思。Creator的意图是想借JSF的组件架构，构造一个轻量的开发环境，并且还苦心构造了一个轻量的后台的数据支持。这明显和SUN的J2EE架构矛盾，真是搞不懂。不过，Creator对快速开发（RAD）倒是颇有点像VS.NET的那么点样子，可惜是SUN在经营，恐怕也不会对MS造成什么威胁。
另外一个IDEA则也有一大帮拥甭。IDEA有些地方却有独到之处。其它倒是不说，不过IDEA的下一版（恐怕不妥）fabrique倒是非常有意思，它在常规的IDE之上构建了一个专门的应用框架，并且在IDE（应该说是RAD开发平台）提供了业务对象框架，Web应用框架，以及通用的服务（称为Active Libraries）（Forum,Email,...）的支持。非常具有特色。我个人十分欣赏。这点恐怕只是Oracle ADF可以与之一比。
呵呵，先说这么多。
有一个免费的Java在线教程，看样子是一个SUN的专家掌控的，名字 sang.shin ，中国人？韩国人？
其中有很多非常好的材料，有详细的课程表，还包括PPT材料，讲课录音，实验材料等等。我觉得非常有价值。
你还可以注册到一个相关的yahoo群组参与到课程中。初学者不妨试试。虽然是英文的，不过也不要怕，还可以学习英文，岂不更好？
地址是：http://www.javapassion.com
Roger Kitain （ JavaServer Faces co-specification lead ）在其blog宣布了开源的 "Open JavaServer Faces" ，并且在基于OSI-approved CDDL许可之下。
原来SUN JSF RI 是基于 Sun Java Research License [Sun, JRL]对”开放开发”发布。基本上，这意味着你可以免费获得它的代码和源代码，并且你可以修改和分发它，只要你不是用作商业目的, 或者用作内部非生产之用。如果你修改了二进制代码和源代码用作商业用途或者内部生产之用，你必须使用商业许可证并且通过 JSF 技术兼容包 (TCK)的测试。你也可以提交补丁给 JSF RI 代码基。
并且在Java.net社区也launch了一个专门的项目Javaserver Faces，地址是：https://javaserverfaces.dev.java.net/
Ed Burns 也在其BLog中公布了 JavaServer Faces 1.2 和 JavaServer Pages 2.1 Proposed Final Draft Specification的一些细节：
将JSP，JSTL和Faces EL统一起来，并且类似于 OGNL 的使用方式。这将极度方便表现层之间的整合，和MVC之间的简化。
- 针对JSP/JSF应用的新的Tree 创建和内容交织模型（Content Interweaving Model）。
虽然可以不用JSP而使用Faces，但是因为技术、技能和各种生产开发环境的支持，JSP/JSF应用确实最现实和富有效率的。当然，这里还有一些集成问题，比如OnJava中的 Hans Bergsten 的这篇文章所述。 所以规范中将修改针对JSP的Faces ViewHandler 的实现，以及所有Faces组件标签所用的JSP定制标签句柄的基类的实现来解决这些问题。
有一个问题是JSTL不支持PostBack，所以使用 JSTL的 <c:forEach> 包含Faces 输入组件会出现问题。所以需要在JSTL中引入类似于PostBack的新概念，将在下一个版本中发布，并且更好地支持所有Faces组件。
- Back Button 问题和多 Frame 或Multi Window Faces 应用。
因为在Multi Frame 或者 Multi Window 应用中使用Facesa在State Management API方面会出问题，即浏览器的Back按钮会造成状态错误。这个问题已经解决。
- 将消息与页面中的某个特定的组件相关联。
- AJAX support
- 暴露一个application 层面的 ResourceBundle 给 EL.
添加了一个新的 <resource-bundle>到 faces-config 中，列出应该暴露给使用ELResolver 链的EL的资源束。这样可以优化性能。
原文见：http://weblogs.java.net/blog/edburns/archive/2005/08/javaserver_face_3.html