51CTO下载Web+安全与+Rational+AppScan+入门.docx
《51CTO下载Web+安全与+Rational+AppScan+入门.docx》由会员分享，可在线阅读，更多相关《51CTO下载Web+安全与+Rational+AppScan+入门.docx（12页珍藏版）》请在冰点文库上搜索。
51CTO下载Web+安全与+Rational+AppScan+入门
Web安全与RationalAppScan入门
本文将从对Web应用现状的分析入手，通过列举常见的攻击手段，阐明Web应用目前面临的挑战，同时，通过对RationalAppScan平台的介绍，协助企业制定Web应用安全解决方案，为企业的Web应用披上盔甲。
前言 当今世界，Internet（因特网）已经成为一个非常重要的基础平台，很多企业都将应用架设在该平台上，为客户提供更为方便、快捷的服务支持。
这些应用在功能和性能上，都在不断的完善和提高，然而在非常重要的安全性上，却没有得到足够的重视。
由于网络技术日趋成熟，黑客们也将注意力从以往对网络服务器的攻击逐步转移到了对Web应用的攻击上。
根据Gartner的最新调查，信息安全攻击有75%都是发生在Web应用而非网络层面上。
同时，数据也显示，三分之二的Web站点都相当脆弱，易受攻击。
然而现实确是，绝大多数企业将大量的投资花费在网络和服务器的安全上，没有从真正意义上保证Web应用本身的安全，给黑客以可乘之机。
本文将从对Web应用现状的分析入手，通过列举常见的攻击手段，阐明Web应用目前面临的挑战，同时，通过对RationalAppScan平台的介绍，协助企业制定Web应用安全解决方案，为企业的Web应用披上盔甲。
Web应用现状
Web应用的基础概念
在讨论Web应用安全之前，先简单介绍一下Web应用基础概念，这样便于理解为什么Web应用是脆弱的，容易受到攻击。
1、什么是Web应用 Web应用是由动态脚本、编译过的代码等组合而成。
它通常架设在Web服务器上，用户在Web浏览器上发送请求，这些请求使用HTTP协议，经过因特网和企业的Web应用交互，由Web应用和企业后台的数据库及其他动态内容通信。
2、Web应用的架构 尽管不同的企业会有不同的Web环境搭建方式，一个典型的Web应用通常是标准的三层架构模型，如图1所示。
图1:
Web应用通常是标准的三层架构模型
在这种最常见的模型中，客户端是第一层;使用动态Web内容技术的部分属于中间层;数据库是第三层。
用户通过Web浏览器发送请求（request）给中间层，由中间层将用户的请求转换为对后台数据的查询或是更新，并将最终的结果在浏览器上展示给用户。
Web应用安全全景
当讨论起Web应用安全，我们经常会听到这样的回答：
“我们使用了防火墙”、“我们使用了网络脆弱扫描工具”、“我们使用了SSL技术”、“我们每个季度都会进行渗透测试”……所以，“我们的应用是安全的”。
现实真是如此吗?
让我们一起来看一下Web应用安全的全景图。
图2:
信息安全全景
在企业Web应用的各个层面，都会使用不同的技术来确保安全性。
为了保护客户端机器的安全，用户会安装防病毒软件;为了保证用户数据传输到企业Web服务器的传输安全，通信层通常会使用SSL（安全套接层）技术加密数据;企业会使用防火墙和IDS（入侵诊断系统）/IPS（入侵防御系统）来保证仅允许特定的访问，不必要暴露的端口和非法的访问，在这里都会被阻止;即使有防火墙，企业依然会使用身份认证机制授权用户访问Web应用。
但是，即便有防病毒保护、防火墙和IDS/IPS，企业仍然不得不允许一部分的通讯经过防火墙，毕竟Web应用的目的是为用户提供服务，保护措施可以关闭不必要暴露的端口，但是Web应用必须的80和443端口，是一定要开放的。
可以顺利通过的这部分通讯，可能是善意的，也可能是恶意的，很难辨别。
这里需要注意的是，Web应用是由软件构成的，那么，它一定会包含缺陷（bugs），这些bug就可以被恶意的用户利用，他们通过执行各种恶意的操作，或者偷窃、或者操控、或者破坏Web应用中的重要信息。
因此可以看出，企业的回答，并不能真正保证企业的应用安全：
∙ 网络脆弱性扫描工具，由于它仅仅用来分析网络层面的漏洞，不了解应用本身，所以不能彻底提高Web应用安全性;
∙ 防火墙可以阻止对重要端口的访问，但是80和443端口始终要开放，我们无法判断这两个端口中通讯数据是善意的访问还是恶意的攻击;
∙ SSL可以加密数据，但是它仅仅保护了在传输过程中数据的安全性，并没有保护Web应用本身;
∙ 每个季度的渗透测试，无法满足处于不断变更之中的应用。
∙ 只要访问可以顺利通过企业的防火墙，Web应用就毫无保留的呈现在用户面前。
只有加强Web应用自身的安全，才是真正的Web应用安全解决之道。
常见的Web应用攻击 两个重要的国际应用安全组织
在讨论常见的Web应用攻击之前，我们需要先了解两个组织：
WASC和OWASP。
这两个组织在呼吁企业加强应用安全意识和指导企业开发安全的Web应用方面，起到了重要的作用。
WebApplicationSecurityConsortium（WASC），是一个由安全专家、行业顾问和诸多组织的代表组成的国际团体。
他们负责为WWW制定被广为接受的应用安全标准。
WASC组织的关键项目之一是“Web安全威胁分类”，也就是将Web应用所受到的威胁、攻击进行说明并归纳成具有共同特征的分类。
该项目的目的是针对Web应用的安全隐患，制定和推广行业标准术语。
WASC将Web应用安全威胁分为如下六类：
Authentication（验证） 用来确认某用户、服务或是应用身份的攻击手段。
Authorization（授权） 用来决定是否某用户、服务或是应用具有执行请求动作必要权限的攻击手段。
Client-SideAttacks（客户侧攻击） 用来扰乱或是探测Web站点用户的攻击手段。
CommandExecution（命令执行） 在Web站点上执行远程命令的攻击手段。
InformationDisclosure（信息暴露） 用来获取Web站点具体系统信息的攻击手段。
LogicalAttacks（逻辑性攻击） 用来扰乱或是探测Web应用逻辑流程的攻击手段。
可以通过如下的网址访问该组织网站，获得更多详细信息：
www.webappsec.org。
也可以通过参考资料中链接，具体了解“Web安全威胁分类”项目。
OpenWebApplicationSecurityProject（OWASP），该组织致力于发现和解决不安全Web应用的根本原因。
它们最重要的项目之一是“Web应用的十大安全隐患”，总结了目前Web应用最常受到的十种攻击手段，并且按照攻击发生的概率进行了排序。
这个项目的目的是统一业界最关键的Web应用安全隐患，并且加强企业对Web应用安全的意识。
图3:
Web应用十大安全隐患
可以通过如下的网址访问该组织，了解更为详细的信息：
www.owasp.org。
也可以通过参考资料中链接，具体了解“Web应用十大安全隐患”项目。
IBMRational，是上述两个组织的成员。
∙ 常见的Web应用攻击示例 在OWASP组织列举的十大Web应用安全隐患中，有两个概率最高的攻击手段，它们分别是“跨站点脚本攻击”（Cross-SiteScripting）和“注入缺陷”（InjectionFlaws）。
下面将通过举例来说明这两种攻击是如何实施的。
∙1、跨站点脚本攻击 首先来看一下跨站点脚本的利用过程，如图4。
图4:
跨站点脚本攻击的过程
在上图中，恶意攻击者（这里使用Evil.org表示）通过E-mail或HTTP将某银行的网址链接发给用户（银行用表示），该链接中附加了恶意的脚本（上图步骤一）;用户访问发来的链接，进入银行网站，同时，嵌在链接中的脚本被用户的浏览器执行（上图步骤二、三）;用户在银行网站的所有操作，包括用户的cookie和session信息，都被脚本收集到，并且在用户毫不知情的情况下发送给恶意攻击者（上图步骤四）;恶意攻击者使用偷来的session信息，伪装成该用户，进入银行网站，进行非法活动（上图步骤五）。
因此，只要Web应用中，有可被恶意攻击者利用执行脚本的地方，都存在极大的安全隐患。
黑客们如果可以让用户执行他们提供的脚本，就可以从用户正在浏览的域中偷到他的个人信息、可以完全修改用户看到的页面内容、跟踪用户在浏览器中的每一个动作，甚至利用用户浏览器的缺陷完全控制用户的机器。
目前，跨站点脚本攻击是最大的安全风险。
∙2、注入缺陷 目前的Web应用中，绝大多数都会向用户提供一个接口，用来进行权限验证、搜索、查询信息等功能。
比如一个在线银行应用，首先会有对注册客户进行身份验证的登录界面，在正确登录后，会提供更多交互功能，如根据客户的银行卡号信息，查询客户的最近交易、转账细节等。
这些都是注入缺陷的最佳利用场景。
所谓注入缺陷，就是在上述场景中，用户输入的数据被当做命令和查询的一部分，送到后端的解释器中解释执行。
如果用户的输入是正常合法的，Web应用自然会返回正常合理的结果，但是，如果恶意攻击者，利用输入数据可被后台执行的原理，偷梁换柱，使用非法的输入，脆弱的Web应用会怎样呢?
下面我们举一个例子来说明注入缺陷是如何进行的。
在一个交易网站中，用户必须输入产品ID号才可以查看该产品的详细信息。
为了实现这个需求，通常会用SQL语句查询数据库来实现。
开发人员在编写应用程序时，可能会使用如下的SQL语句来实现上述目的（这里仅为示例）：
∙1）Select*fromproductswhereproduct_id=`+用户输入的ID+` 这里的products是数据库中用来存放产品信息的表，+号表示SQL语句需要和用户输入的真实ID进行拼接。
如果用户输入325，则该语句在执行时变为：
Select*fromproductswhereproduct_id=`325` 数据库会将ID为325的产品信息返回给用户。
∙2）在界面上，需要用户输入产品ID的地方，黑客会输入如下数据：
`or`1`=`1 可以看到，黑客并没有输入正常合法的产品编号。
∙3）通过黑客的非法输入，需要执行的SQL语句变为：
Select*fromproductswhereproduct_id=``or`1`=`1` 可以看出，SQL语句的意义就完全改变了，当产品ID为空或者1=1时，返回产品所有信息，而1=1是永远成立的条件，因此，黑客并没有输入任何产品编号，就可以返回数据库中所有产品的详细信息。
通过这个例子，我们可以看出，注入缺陷是风险非常高的安全漏洞，一旦Web应用中给用户提供了需要其输入数据的接口，就有可能遭到攻击，将后台的数据完全暴露在用户的面前。
上述说明的“跨站点脚本攻击”和“注入缺陷攻击”，是目前Web应用中比例最高的两种攻击手段，按照OWASP的项目排序，还有如下八种风险性较高的攻击方法：
o MaliciousFileExecution（恶意文件执行）;
o InsecureDirectObjectReference（不安全的直接对象引用）;
o Cross-SiteRequestForgery（跨站点的请求伪造）;
o InformationLeakageandImproperErrorHandling（信息泄漏和不正确的错误处理）;
o BrokenAuthentication&SessionManagement（损坏的认证和Session管理）;
o InsecureCryptographicStorage（不安全的密码存储）;
o InsecureCommunications（不安全的通信）;
o FailuretoRestrictURLAccess（未能限制URL访问）
在这里，我们就不过多的讨论这几种安全隐患，可以使用3.1节中提供的链接得到更多的描述信息。
∙ 构筑安全的Web应用 功能和性能，往往是我们衡量应用是否满足需求的指标，但是，对于载体为Internet的特殊应用-Web应用而言，安全性也是必要的考量标准，皮之不存，毛将焉附?
如果失去了安全性，即使功能再完备、性能再可靠的Web应用，一旦遭到黑客的攻击和破坏，一切都失去了意义。
因此企业，尤其是提供Web应用的企业，一定要加强对应用安全的重视程度。
针对目前Web应用安全性不高的现状，IBMRational提出了构筑安全Web应用的解决方案。
∙加强全员应用安全性意识
一个根本、底层的战略手段就是加强企业全员的应用安全意识。
正如前面所阐述过的，对于应用而言，无论是开发人员、测试人员、质量管理人员还是项目经理、企业高层，都会对其功能和性能做更多的关注，这也是由于早期应用多为C/S架构的应用，安全问题并不突出。
但是在当今的环境，就不得不将安全作为应用质量的基础。
图5中功能、易用性、可靠性、性能、可支持性，是由RationalUnifiedProcess（RUP）定义的FURPS质量模型，它告诉我们应用的质量需要从这几个方面着手衡量，对于Web应用，就必须将安全性作为质量模型的基础条件。
图5:
适于Web应用的质量模型
要加强全员应用安全意识，就需要对每一个相关角色落实安全要求。
1）对于需求分析、设计人员而言，是否已将产品的安全性考虑到产品的需求设计中，从而保证在项目初期，安全因素已被关注; 2）对于开发人员，在应用中实现了身份认证等安全功能，并不意味着在编程中已考虑到了应用安全性，它们还必须掌握Web应用安全编程规范等技术; 3）对于测试人员，验证了应用的FURPS，不能保证产品已具备安全性，还需要借助其他工具或平台，对应用的安全隐患，进行自动化的扫描，得出全面的安全性报告; 4）对于质量管理人员，产品的质量过关，也不等于产品已经安全可靠，他们和测试人员一样，需要借助工具，掌握Web应用全面的安全隐患汇总和分析。
使用先进的工具确保软件开发生命周期中的安全性 在企业全员都具有了应用安全意识之后，必须将该意识贯彻到项目的具体工作之中，除了要求每个人具备严谨认真、不断学习的态度之外，还需要借助先进的工具，对开发的Web应用进行自动化的安全隐患发现、分析、报告、提供修复意见等工作，建立人工检查和自动化工具配合的完整保障措施。
IBMRationalAppScan，正是这样一种Web应用自动化诊断工具，下面我们对其进行简单的介绍。
RationalAppScan，是对Web应用和WebServices进行自动化安全扫描的黑盒工具，它不但可以简化企业发现和修复Web应用安全隐患的过程（因为这些工作，以往都是由人工进行，成本相对较高，但是效率却非常低下），还可以根据发现的安全隐患，提出针对性的修复建议，并能形成多种符合法规、行业标准的报告，方便相关人员全面了解企业应用的安全状况。
图6说明了AppScan在软件开发生命周期中的各个阶段，都可以协助安全隐患的诊断。
图6:
AppScan对软件开发生命周期的支持
1）开发过程中的安全保障 AppScanDE（AppScan开发版）可以作为多种平台的插件，这些平台包括Eclipse、WebSphere、VisualStudio、JBuilder，协助开发人员对编写的模块进行自我安全诊断。
图7是AppScanDE作为VisualStudio插件使用的示例。
图7:
AppScanDE作为VisualStudio的插件
2）质量管理过程中的安全保障 通过和RationalClearQuest的集成，AppScan可以将发现的安全隐患方便的导入到变更管理平台中，确保发现的每一个问题，都被记录，并详细跟踪其在整个修复过程中的状态变化。
如图8所示。
图8:
AppScan和RationalClearQuest集成
除RationalClearQuest之外，AppScan还可以和Mercury的QualityCenter集成。
3）在集成和发布阶段中的安全保障 在集成和发布阶段，可以通过简单的配置，使用AppScan对应用进行全面的扫描，企业仅需要指明Web应用的入口链接，AppScan就会利用网络爬行（Crawling）技术，遍历应用中所有需要测试的链接，并对每个链接发送多种测试参数，诊断其有无漏洞可被利用。
最后将结果呈现在用户面前。
如图9是对示例网站进行诊断的结果。
从结果可以看出，本次诊断共发现了88个安全隐患，并按照严重程度进行了统计。
诊断结果的中部，显示了AppScan扫描出来的应用结构、每个模块或链接包含的漏洞数;右上方则按照严重程度，对扫描出来的漏洞进行了分类;结果的右下方对每一种隐患，进行了解释，并提出了详细的修复建议，同时说明了为发现这个漏洞，AppScan发送了哪些测试参数等。
图9:
AppScan的诊断结果示例
4）对诊断结果进行全面的分析和报告 RationalAppScan不仅可以对Web应用进行自动化的扫描、指出安全漏洞的修复意见，还可以将诊断结果，使用不同的行业标准、法规，形成针对性的报告，让相关人员对应用安全状况和法规遵从等有了全面的认识。
如图10，左图是AppScan可以自动生成的行业标准报告，而右图则是近40种的法规遵从报告，如赛班斯法规遵从等。
图10:
自动生成的行业标准报告
小结 通过上述对Web应用现状和常见的Web应用攻击示例分析，我们可以看出，目前因特网上的Web应用，存在着极大的安全隐患和风险，企业对Web应用安全的保护，已经刻不容缓。
IBMRationalAppScan，作为先进的Web应用自动化诊断工具，可以协助企业在整个Web应用开发生命周期，将安全意识贯彻到企业全员具体的工作中，高效率的发现应用中存在的安全隐患、给出详细的修复建议、并生成多种符合行业标准和法规的报告，已在全球拥有近千个成功案例，是一个完整的、端到端的Web应用安全解决方案，能真正为企业的Web应用披上安全的盔甲。
升级会员 