????????? 前些日子写了一篇《几个常见的 Web 应用安全缺陷及样例 》东西，这两天正好有空同事希望能够做一个 IBM Rational AppScan 的实践和 Web 应用安全方面的交流，本来之前对这方面关注、研究的不多，既然现在有这个机会，就索性好好利用下，再研究研究。由于行业的原因平时接触的 MIS 较多，所以这次 SQL 注入类缺陷想得多些。
?
SQL Injection Command Execution
????????? 该缺陷是一种特定的SQL注入，它通过Microsoft SQL Server T-SQL提供的xp_cmdshell存储过程工作，该过程提供了在服务器上执行Shell命令脚本的能力。攻击者可以通过SQL注入缺陷向Web应用注入xp_cmdshell相关SQL语句，通过xp_cmdshell在服务器上执行注入的Shell命令或脚本。这种缺陷往往被攻击者组合使用。出于安全的考虑，Microsoft SQL Server 2005 默认情况下禁用了xp_cmdshell存储过程执行权限，如果在未经sp_configure启用的情况下执行xp_cmdshell存储过程会获得如下错误信息：
?
SQL Injection using DECLARE, CAST and EXEC
????????? 该缺陷是一种特定的SQL注入，通过Microsoft SQL Server T-SQL提供的CAST函数工作。CAST用于将一种数据类型的表达式转换为另一种数据类型的表达式，CONVERT函数也提供了同样的功能。攻击者通过提供需要注入的SQL语句的ASCII编码数组，在CAST函数转换后执行来实现注入攻击目的，一般会与DECLARE和EXEC结合使用。首先DECLARE注入SQL语句的缓冲区；然后通过CAST转换注入SQL语句的ASCII编码数组生成T-SQL可执行语句，并将结果保存入上步定义的缓冲区中；最后，通过EXEC执行注入语句。可以发现这种攻击方式潜在的威胁很大，如果执行注入SQL的Microsoft SQL Server登录用户拥有足够权限，攻击者就可以获得大量的非法数据；同时通过结合SQL Injection Command Execution缺陷，此时若Microsoft SQL Server在Windows执行进程权限足够高，就非常容易执行对服务器有威胁的Shell命令或脚本。
?
?
????????? 在上面的例子中，攻击者首先利用Web应用中showNews.xsql页面的SQL注入缺陷通过domesticindicate查询域传入了利用DECLARE, CAST and EXEC缺陷的SQL语句。其中标记部分，会最终在Microsoft SQL Server中执行如下T-SQL命令（不包括其中的换行）：
?
?
CAST函数处理后的缓冲区将会包含以下T-SQL命令：
?
?
????????? 上面的例子就是通过结合SQL Injection Command Execution缺陷，执行对服务器有威胁的命令脚本，这要求Microsoft SQL Server执行进程有足够权限。
SQL Query in Parameter Value
????????? 该缺陷是一种特定的SQL注入，主要是指Web应用将一些查询目的的SQL语句写入客户可访问的页面中，此时攻击者可以通过伪造页面并伪造其中的SQL语句来实现注入攻击。一般情况下此缺陷的查询SQL语句会被设计存入在页面表单中的隐藏域中。
?
8.3 Naming System Source Code Disclosure
????????? 在Microsoft Windows操作系统中，文件有“长路径”和“8.3格式短路径”两种路径表示方式。一般情况下Web服务器会根据客户访问页面资源文件名和扩展名来判断是否执行解析。此时当具有该缺陷的Web服务器部署在Windows平台上时，攻击者通过发送“8.3格式短路径”来标识访问页面资源的URL，Web服务器就不会对页面进行解析执行，此时页面代码就会被推送到客户端浏览器中，并作为文本（text/plain）显示。该缺陷虽然不会直接造成攻击者在服务端执行脚本代码，但能够造成Web应用源代码泄露，为攻击者进一步精确攻击提供了帮助。
?
Multiple Vendor Java Servlet Source Code Disclosure
????????? 该安全缺陷也会造成Web应用源代码泄露，存在该缺陷的Web服务器会错误的认为URL标识的页面资源不应该进行解析执行，此时页面代码就会被推送到客户端浏览器中，并作为文本（text/plain）显示。该缺陷虽然不会直接造成攻击者在服务器端执行脚本代码，但能够造成Web应用源代码泄露，为攻击者进一步精确攻击提供了帮助。下面列出了典型情况：
?
- Web服务器对页面资源URL标识大小写敏感，未正确解析执行。如：使用“http://TARGET/servlet.JSP”替代“http://TARGET/servlet.jsp”。
- Web服务器对URL编码（或组合）敏感，未正确解析执行。如：
- “http://TARGET/servlet.jsp%00”，空（NULL）的URL编码为“%00”；
- “http://TARGET/servlet.js%70”，字母“p”的URL编码为“%70”；
- “http://TARGET/servlet%2ejsp”，字符“.”的URL编码为“%2e”；
- “http://TARGET/cgi-bin/script.cgi%20”，空格的URL编码为“%20”。
Alternate Version of File Detected
????????? 该缺陷是指在部署的Web应用中遗留了备份文件，并且这些页面资源可以被客户访问，而这些备份文件中往往会包含一些开发时保留的调试目的的执行代码。攻击者会利用这些文件所给出的调试信息来分析Web应用系统，以获得用于执行更精确的攻击所需要的信息。此类攻击一般都需要Directory Listing类缺陷支持，如Apache Jakarta Tomcat URL Parsing Directory Listing、CVS Directory Browsing或Directory Listing Pattern Found等，备份文件往往包含以下标志“Copy of”、“_”、“.”、“~”或“Old”等。该缺陷虽然不会直接造成攻击者在服务器端执行脚本代码，但能够造成Web应用源代码泄露，为攻击者进一步精确攻击提供帮助。
?
TRACE and TRACK HTTP Methods Enabled
????????? HTTP/1.1（RFC2616）规范定义了HTTP TRACE方法，主要是用于客户端通过向Web服务器提交TRACE请求来进行测试或获得诊断信息。当Web服务器启用TRACE时，提交的请求头会在服务器响应的内容（Body）中完整的返回，其中HTTP头很可能包括Session Token、Cookies或其它认证信息。攻击者可以利用此缺陷来欺骗合法用户并得到他们的私人信息。该缺陷往往与其它方式配合来进行有效攻击，由于HTTP TRACE请求可以通过客户浏览器脚本发起（如XMLHttpRequest），并可以通过DOM接口来访问，因此很容易被攻击者利用。
?
Phishing Through URL Redirection
????????? 该缺陷指出Web应用系统中包含了能够跳转到其它Web应用地址的情况。攻击者可以伪装该跳转缺陷，欺骗合法用户并得到他们的私人信息，如典型的钓鱼类网站。
?
?
暂时就先到这里，其它好多缺陷等遇到了再研究。
其中一些缺陷的名称可能 AppScan 与其它略有不同，不过表达的意思是相同的。
注明：以上所有内容和代码，如与我有关项目或文档有相似之处纯属巧合。
哎，这次还是贴图。上面提到的所有内容在附件的 Word 文档中可以找到文字版本，尤其是涉及的样例部分。
?
// 2009.01.19 08:45 添加 ////
?
????????? IBM Rational 的 release 速度还是比较快的，呵呵上周五推出了 AppScan 7.8 （Build 518）。官方网站提供了试用版下载。
Rational AppScan
?
????????? 值得一提的是，AppScan 将 Web 服务的缺陷检测功能放在了独立的 GSC（Generic Service Client） 工具中，如果需要测试 Web 服务，则需要另外安装该工具支持。除此之外，发现 IBM Rational AppScan eXtensions Framework 也是个好东东，通过她就可以开发基于 AppScan 的自定义功能扩展及自动化测试解决方案。不过 AppScan 可不便宜哦。
?
// 2009.01.19 09:22 添加 ////
?
????????? MSDN 上的一篇很好的介绍 SQL 截断缺陷与防御的文章，虽然是06年11月发表的。特别是使用 Microsoft SQL Server 产品的兄弟们。文章的最后还给出了这类缺陷的检测方法，包括了一、二级 SQL 注入，很是精辟。推荐。
新型 SQL 截断攻击和防御方法
?
// 2009.03.07 13:30 添加 ////
作者：lzy.je
出处：http://lzy.iteye.com
本文版权归作者所有，只允许以摘要和完整全文两种形式转载，不允许对文字进行裁剪。未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
?
// 2009.05.22 15:18 添加 ////
?
????????? 这里有篇对跨站请求伪造（Cross Site Request Forgery）缺陷介绍得比较清楚的文章，其中还提到了几个解决方法，可供参考。
CSRF――攻击与防御
?
呃 晕晕 有解决办法吗
解决方法那是必须要有的，对于主流的缺陷有一些成熟的方案，如对于避免 SQL 注入用的比较多的方法是过滤单引号“'”等 SQL 保留字符，或是使用数据库开发框架的 SQL 命令参数（@xxx）方式。同时一定要注意避免截断型攻击。
这次研究的时间、精力有限，没有涉及解决方法相关讨论。其实解决方法也比较好 google 到，AppScan 就提供了较详细的说明。
哈哈，我以后也会做代码安全这块了，找到个同行。
一起研究、共同进步、分享更多。