Web安全与Rational AppScan入门.docx
- 文档编号:8439303
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:11
- 大小:248.94KB
Web安全与Rational AppScan入门.docx
《Web安全与Rational AppScan入门.docx》由会员分享,可在线阅读,更多相关《Web安全与Rational AppScan入门.docx(11页珍藏版)》请在冰豆网上搜索。
Web安全与RationalAppScan入门
使用RationalAppScan保证Web应用的安全性
——Web安全与RationalAppScan入门
本文将从对Web应用现状的分析入手,通过列举常见的攻击手段,阐明Web应用目前面临的挑战,同时,通过对RationalAppScan平台的介绍,协助企业制定Web应用安全解决方案,为企业的Web应用披上盔甲。
在第一部分,将介绍Web安全与RationalAppScan的入门知识。
在后续的第二部分将介绍如何使用RationalAppScan应对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应用逻辑流程的攻击手段。
OpenWebApplicationSecurityProject(OWASP),该组织致力于发现和解决不安全Web应用的根本原因。
它们最重要的项目之一是“Web应用的十大安全隐患”,总结了目前Web应用最常受到的十种攻击手段,并且按照攻击发生的概率进行了排序。
这个项目的目的是统一业界最关键的Web应用安全隐患,并且加强企业对Web应用安全的意识。
图3:
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 * from products where product_id = ` 325 `
数据库会将ID为325的产品信息返回给用户。
2)在界面上,需要用户输入产品ID的地方,黑客会输入如下数据:
` or `1`= `1
可以看到,黑客并没有输入正常合法的产品编号。
3)通过黑客的非法输入,需要执行的SQL语句变为:
Select * from products where product_id = ` ` or `1`=`1`
可以看出,SQL语句的意义就完全改变了,当产品ID为空或者1=1时,返回产品所有信息,而1=1是永远成立的条件,因此,黑客并没有输入任何产品编号,就可以返回数据库中所有产品的详细信息。
通过这个例子,我们可以看出,注入缺陷是风险非常高的安全漏洞,一旦Web应用中给用户提供了需要其输入数据的接口,就有可能遭到攻击,将后台的数据完全暴露在用户的面前。
上述说明的“跨站点脚本攻击”和“注入缺陷攻击”,是目前Web应用中比例最高的两种攻击手段,按照OWASP的项目排序,还有如下八种风险性较高的攻击方法:
MaliciousFileExecution(恶意文件执行);
InsecureDirectObjectReference(不安全的直接对象引用);
Cross-SiteRequestForgery(跨站点的请求伪造);
InformationLeakageandImproperErrorHandling(信息泄漏和不正确的错误处理);
BrokenAuthentication&SessionManagement(损坏的认证和Session管理);
InsecureCryptographicStorage(不安全的密码存储);
InsecureCommunications(不安全的通信);
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应用披上安全的盔甲。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Web安全与Rational AppScan入门 Web 安全 Rational AppScan 入门