在讨论 Web 应用安全之前,先简单介绍一下 Web 应用基础概念,这样便于理解为什么 Web 应用是脆弱的,容易受到***。
1、 什么是 Web 应用
Web 应用是由动态脚本、编译过的代码等组合而成。它通常架设在 Web 服务器上,用户在 Web 浏览器上发送请求,这些请求使用 HTTP 协议,经过因特网和企业的 Web 应用交互,由 Web 应用和企业后台的数据库及其他动态内容通信。
2、 Web 应用的架构
尽管不同的企业会有不同的 Web 环境搭建方式,一个典型的 Web 应用通常是标准的三层架构模型,如图 1 所示。

图 1: Web 应用通常是标准的三层架构模型
Web
在这种最常见的模型中,客户端是第一层;使用动态 Web 内容技术的部分属于中间层;数据库是第三层。用户通过 Web 浏览器发送请求(request)给中间层,由中间层将用户的请求转换为对后台数据的查询或是更新,并将最终的结果在浏览器上展示给用户。
当讨论起 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 应用***之前,我们需要先了解两个组织:WASC 和 OWASP。这两个组织在呼吁企业加强应用安全意识和指导企业开发安全的 Web 应用方面,起到了重要的作用。
Web Application Security Consortium(WASC),是一个由安全专家、行业顾问和诸多组织的代表组成的国际团体。他们负责为 WWW 制定被广为接受的应用安全标准。WASC 组织的关键项目之一是“Web 安全威胁分类”,也就是将 Web 应用所受到的威胁、***进行说明并归纳成具有共同特征的分类。该项目的目的是针对 Web 应用的安全隐患,制定和推广行业标准术语。WASC 将 Web 应用安全威胁分为如下六类:
Authentication(验证)
用来确认某用户、服务或是应用身份的***手段。
Authorization(授权)
用来决定是否某用户、服务或是应用具有执行请求动作必要权限的***手段。
Client-Side Attacks(客户侧***)
用来扰乱或是探测 Web 站点用户的***手段。
Command Execution(命令执行)
在 Web 站点上执行远程命令的***手段。
Information Disclosure(信息暴露)
用来获取 Web 站点具体系统信息的***手段。
Logical Attacks(逻辑性***)
用来扰乱或是探测 Web 应用逻辑流程的***手段。
可以通过如下的网址访问该组织网站,获得更多详细信息:[url]www.webappsec.org[/url]。也可以通过参考资料中链接,具体了解“Web 安全威胁分类”项目。
Open Web Application Security Project(OWASP),该组织致力于发现和解决不安全 Web 应用的根本原因。它们最重要的项目之一是“Web 应用的十大安全隐患”,总结了目前 Web 应用最常受到的十种***手段,并且按照***发生的概率进行了排序。这个项目的目的是统一业界最关键的 Web 应用安全隐患,并且加强企业对 Web 应用安全的意识。

图 3: Web 应用十大安全隐患
Web
可以通过如下的网址访问该组织,了解更为详细的信息:[url]www.owasp.org[/url]。也可以通过参考资料中链接,具体了解“Web 应用十大安全隐患”项目。
IBM Rational,是上述两个组织的成员。
在 OWASP 组织列举的十大 Web 应用安全隐患中,有两个概率最高的***手段,它们分别是“跨站点脚本***”(Cross-Site Scripting)和“注入缺陷”(Injection Flaws)。下面将通过举例来说明这两种***是如何实施的。
1、 跨站点脚本***
首先来看一下跨站点脚本的利用过程,如图 4。

图 4: 跨站点脚本***的过程
跨站点脚本***的过程
在上图中,恶意***者(这里使用 Evil.org 表示)通过 E-mail 或 HTTP 将某银行的网址链接发给用户(银行用 bank.com 表示),该链接中附加了恶意的脚本(上图步骤一);用户访问发来的链接,进入银行网站,同时,嵌在链接中的脚本被用户的浏览器执行(上图步骤二、三);用户在银行网站的所有操作,包括用户的 cookie 和 session 信息,都被脚本收集到,并且在用户毫不知情的情况下发送给恶意***者(上图步骤四);恶意***者使用偷来的 session 信息,伪装成该用户,进入银行网站,进行非法活动(上图步骤五)。
因此,只要 Web 应用中,有可被恶意***者利用执行脚本的地方,都存在极大的安全隐患。***们如果可以让用户执行他们提供的脚本,就可以从用户正在浏览的域中偷到他的个人信息、可以完全修改用户看到的页面内容、跟踪用户在浏览器中的每一个动作,甚至利用用户浏览器的缺陷完全控制用户的机器。
目前,跨站点脚本***是最大的安全风险。
2、 注入缺陷
目前的 Web 应用中,绝大多数都会向用户提供一个接口,用来进行权限验证、搜索、查询信息等功能。比如一个在线银行应用,首先会有对注册客户进行身份验证的登录界面,在正确登录后,会提供更多交互功能,如根据客户的银行卡号信息,查询客户的最近交易、转账细节等。这些都是注入缺陷的最佳利用场景。所谓注入缺陷,就是在上述场景中,用户输入的数据被当做命令和查询的一部分,送到后端的解释器中解释执行。如果用户的输入是正常合法的,Web 应用自然会返回正常合理的结果,但是,如果恶意***者,利用输入数据可被后台执行的原理,偷梁换柱,使用非法的输入,脆弱的 Web 应用会怎样呢?
下面我们举一个例子来说明注入缺陷是如何进行的。在一个交易网站中,用户必须输入产品 ID 号才可以查看该产品的详细信息。为了实现这个需求,通常会用 SQL 语句查询数据库来实现。开发人员在编写应用程序时,可能会使用如下的 SQL 语句来实现上述目的(这里仅为示例):
1) Select * from products where product_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 的项目排序,还有如下八种风险性较高的***方法:
  • Malicious File Execution(恶意文件执行);
  • Insecure Direct Object Reference(不安全的直接对象引用);
  • Cross-Site Request Forgery(跨站点的请求伪造);
  • Information Leakage and Improper Error Handling(信息泄漏和不正确的错误处理);
  • Broken Authentication & Session Management(损坏的认证和 Session 管理);
  • Insecure Cryptographic Storage(不安全的密码存储);
  • Insecure Communications(不安全的通信);
  • Failure to Restrict URL Access(未能限制 URL 访问)
在这里,我们就不过多的讨论这几种安全隐患,可以使用 3.1 节中提供的链接得到更多的描述信息。




回页首


功能和性能,往往是我们衡量应用是否满足需求的指标,但是,对于载体为 Internet 的特殊应用-Web 应用而言,安全性也是必要的考量标准,皮之不存,毛将焉附?如果失去了安全性,即使功能再完备、性能再可靠的 Web 应用,一旦遭到***的***和破坏,一切都失去了意义。因此企业,尤其是提供 Web 应用的企业,一定要加强对应用安全的重视程度。
针对目前 Web 应用安全性不高的现状,IBM Rational 提出了构筑安全 Web 应用的解决方案。
一个根本、底层的战略手段就是加强企业全员的应用安全意识。正如前面所阐述过的,对于应用而言,无论是开发人员、测试人员、质量管理人员还是项目经理、企业高层,都会对其功能和性能做更多的关注,这也是由于早期应用多为 C/S 架构的应用,安全问题并不突出。但是在当今的环境,就不得不将安全作为应用质量的基础。
图 5 中功能、易用性、可靠性、性能、可支持性,是由 Rational Unified Process(RUP)定义的 FURPS 质量模型,它告诉我们应用的质量需要从这几个方面着手衡量,对于 Web 应用,就必须将安全性作为质量模型的基础条件。

图 5: 适于 Web 应用的质量模型
适于
要加强全员应用安全意识,就需要对每一个相关角色落实安全要求。
1) 对于需求分析、设计人员而言,是否已将产品的安全性考虑到产品的需求设计中,从而保证在项目初期,安全因素已被关注;
2) 对于开发人员,在应用中实现了身份认证等安全功能,并不意味着在编程中已考虑到了应用安全性,它们还必须掌握 Web 应用安全编程规范等技术;
3) 对于测试人员,验证了应用的 FURPS,不能保证产品已具备安全性,还需要借助其他工具或平台,对应用的安全隐患,进行自动化的扫描,得出全面的安全性报告;
4) 对于质量管理人员,产品的质量过关,也不等于产品已经安全可靠,他们和测试人员一样,需要借助工具,掌握 Web 应用全面的安全隐患汇总和分析。
在企业全员都具有了应用安全意识之后,必须将该意识贯彻到项目的具体工作之中,除了要求每个人具备严谨认真、不断学习的态度之外,还需要借助先进的工具,对开发的 Web 应用进行自动化的安全隐患发现、分析、报告、提供修复意见等工作,建立人工检查和自动化工具配合的完整保障措施。IBM Rational AppScan,正是这样一种 Web 应用自动化诊断工具,下面我们对其进行简单的介绍。
Rational AppScan,是对 Web 应用和 Web Services 进行自动化安全扫描的黑盒工具,它不但可以简化企业发现和修复 Web 应用安全隐患的过程(因为这些工作,以往都是由人工进行,成本相对较高,但是效率却非常低下),还可以根据发现的安全隐患,提出针对性的修复建议,并能形成多种符合法规、行业标准的报告,方便相关人员全面了解企业应用的安全状况。图 6 说明了 AppScan 在软件开发生命周期中的各个阶段,都可以协助安全隐患的诊断。

图 6: AppScan 对软件开发生命周期的支持
AppScan
1) 开发过程中的安全保障
AppScan DE(AppScan 开发版)可以作为多种平台的插件,这些平台包括 Eclipse、WebSphere、Visual Studio、JBuilder,协助开发人员对编写的模块进行自我安全诊断。图 7 是 AppScan DE 作为 Visual Studio 插件使用的示例。

图 7: AppScan DE 作为 Visual Studio 的插件
AppScan
2) 质量管理过程中的安全保障
通过和 Rational ClearQuest 的集成,AppScan 可以将发现的安全隐患方便的导入到变更管理平台中,确保发现的每一个问题,都被记录,并详细跟踪其在整个修复过程中的状态变化。如图 8 所示。

图 8: AppScan 和 Rational ClearQuest 集成
AppScan
除 Rational ClearQuest 之外,AppScan 还可以和 Mercury 的 Quality Center 集成。
3) 在集成和发布阶段中的安全保障
在集成和发布阶段,可以通过简单的配置,使用 AppScan 对应用进行全面的扫描,企业仅需要指明 Web 应用的入口链接,AppScan 就会利用网络爬行(Crawling)技术,遍历应用中所有需要测试的链接,并对每个链接发送多种测试参数,诊断其有无漏洞可被利用。最后将结果呈现在用户面前。如图 9 是对示例网站 [url]http://demo.testfire.net[/url] 进行诊断的结果。
从结果可以看出,本次诊断共发现了 88 个安全隐患,并按照严重程度进行了统计。诊断结果的中部,显示了 AppScan 扫描出来的应用结构、每个模块或链接包含的漏洞数;右上方则按照严重程度,对扫描出来的漏洞进行了分类;结果的右下方对每一种隐患,进行了解释,并提出了详细的修复建议,同时说明了为发现这个漏洞,AppScan 发送了哪些测试参数等。

图 9: AppScan 的诊断结果示例
AppScan
4) 对诊断结果进行全面的分析和报告
Rational AppScan 不仅可以对 Web 应用进行自动化的扫描、指出安全漏洞的修复意见,还可以将诊断结果,使用不同的行业标准、法规,形成针对性的报告,让相关人员对应用安全状况和法规遵从等有了全面的认识。如图 10,左图是 AppScan 可以自动生成的行业标准报告,而右图则是近 40 种的法规遵从报告,如赛班斯法规遵从等。

图 10: 自动生成的行业标准报告
自动生成的行业标准报告




回页首


通过上述对 Web 应用现状和常见的 Web 应用***示例分析,我们可以看出,目前因特网上的 Web 应用,存在着极大的安全隐患和风险,企业对 Web 应用安全的保护,已经刻不容缓。IBM Rational AppScan,作为先进的 Web 应用自动化诊断工具,可以协助企业在整个 Web 应用开发生命周期,将安全意识贯彻到企业全员具体的工作中,高效率的发现应用中存在的安全隐患、给出详细的修复建议、并生成多种符合行业标准和法规的报告,已在全球拥有近千个成功案例,是一个完整的、端到端的 Web 应用安全解决方案,能真正为企业的 Web 应用披上安全的盔甲。