在讨论 Web 应用安全以前，先简单介绍一下 Web 应用基础概念，这样便于理解为何 Web 应用是脆弱的，容易受到***。
一、 什么是 Web 应用
Web 应用是由动态脚本、编译过的代码等组合而成。它一般架设在 Web 服务器上，用户在 Web 浏览器上发送请求，这些请求使用 HTTP 协议，通过因特网和企业的 Web 应用交互，由 Web 应用和企业后台的数据库及其余动态内容通讯。
二、 Web 应用的架构
尽管不一样的企业会有不一样的 Web 环境搭建方式，一个典型的 Web 应用一般是标准的三层架构模型，如图 1 所示。
图 1: Web 应用一般是标准的三层架构模型
在这种最多见的模型中，客户端是第一层；使用动态 Web 内容技术的部分属于中间层；数据库是第三层。用户经过 Web 浏览器发送请求（request）给中间层，由中间层将用户的请求转换为对后台数据的查询或是更新，并将最终的结果在浏览器上展现给用户。
当讨论起 Web 应用安全，咱们常常会听到这样的回答：
“咱们使用了防火墙”、“咱们使用了网络脆弱扫描工具”、“咱们使用了 SSL 技术”、“咱们每一个季度都会进行***测试”……因此，“咱们的应用是安全的”。现实真是如此吗？让咱们一块儿来看一下 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 应用十大安全隐患
能够经过以下的网址访问该组织，了解更为详细的信息：
[url]www.owasp.org[/url]。也能够经过
参考资料中连接，具体了解“Web 应用十大安全隐患”项目。
IBM Rational，是上述两个组织的成员。
在 OWASP 组织列举的十大 Web 应用安全隐患中，有两个几率最高的***手段，它们分别是“跨站点脚本***”（Cross-Site Scripting）和“注入缺陷”（Injection Flaws）。下面将经过举例来讲明这两种***是如何实施的。
一、 跨站点脚本***
首先来看一下跨站点脚本的利用过程，如图 4。
图 4: 跨站点脚本***的过程
在上图中，恶意***者（这里使用 Evil.org 表示）经过 E-mail 或 HTTP 将某银行的网址连接发给用户（银行用 bank.com 表示），该连接中附加了恶意的脚本（上图步骤一）；用户访问发来的连接，进入银行网站，同时，嵌在连接中的脚本被用户的浏览器执行（上图步骤2、三）；用户在银行网站的全部操做，包括用户的 cookie 和 session 信息，都被脚本收集到，而且在用户绝不知情的状况下发送给恶意***者（上图步骤四）；恶意***者使用偷来的 session 信息，假装成该用户，进入银行网站，进行非法活动（上图步骤五）。
所以，只要 Web 应用中，有可被恶意***者利用执行脚本的地方，都存在极大的安全隐患。***们若是可让用户执行他们提供的脚本，就能够从用户正在浏览的域中偷到他的我的信息、能够彻底修改用户看到的页面内容、跟踪用户在浏览器中的每个动做，甚至利用用户浏览器的缺陷彻底控制用户的机器。
目前，跨站点脚本***是最大的安全风险。
二、 注入缺陷
目前的 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 对软件开发生命周期的支持
1) 开发过程当中的安全保障
AppScan DE（AppScan 开发版）能够做为多种平台的插件，这些平台包括 Eclipse、WebSphere、Visual Studio、JBuilder，协助开发人员对编写的模块进行自我安全诊断。图 7 是 AppScan DE 做为 Visual Studio 插件使用的示例。
图 7: AppScan DE 做为 Visual Studio 的插件
2) 质量管理过程当中的安全保障
经过和 Rational ClearQuest 的集成，AppScan 能够将发现的安全隐患方便的导入到变动管理平台中，确保发现的每个问题，都被记录，并详细跟踪其在整个修复过程当中的状态变化。如图 8 所示。
图 8: AppScan 和 Rational ClearQuest 集成
除 Rational ClearQuest 以外，AppScan 还能够和 Mercury 的 Quality Center 集成。
3) 在集成和发布阶段中的安全保障
在集成和发布阶段，能够经过简单的配置，使用 AppScan 对应用进行全面的扫描，企业仅须要指明 Web 应用的入口连接，AppScan 就会利用网络爬行（Crawling）技术，遍历应用中全部须要测试的连接，并对每一个连接发送多种测试参数，诊断其有无漏洞可被利用。最后将结果呈如今用户面前。如图 9 是对示例网站 [url]http://demo.testfire.net[/url] 进行诊断的结果。
从结果能够看出，本次诊断共发现了 88 个安全隐患，并按照严重程度进行了统计。诊断结果的中部，显示了 AppScan 扫描出来的应用结构、每一个模块或连接包含的漏洞数；右上方则按照严重程度，对扫描出来的漏洞进行了分类；结果的右下方对每一种隐患，进行了解释，并提出了详细的修复建议，同时说明了为发现这个漏洞，AppScan 发送了哪些测试参数等。
图 9: AppScan 的诊断结果示例
4) 对诊断结果进行全面的分析和报告
Rational AppScan 不只能够对 Web 应用进行自动化的扫描、指出安全漏洞的修复意见，还能够将诊断结果，使用不一样的行业标准、法规，造成针对性的报告，让相关人员对应用安全情况和法规听从等有了全面的认识。如图 10，左图是 AppScan 能够自动生成的行业标准报告，而右图则是近 40 种的法规听从报告，如赛班斯法规听从等。
图 10: 自动生成的行业标准报告
|
|
经过上述对 Web 应用现状和常见的 Web 应用***示例分析，咱们能够看出，目前因特网上的 Web 应用，存在着极大的安全隐患和风险，企业对 Web 应用安全的保护，已经刻不容缓。IBM Rational AppScan，做为先进的 Web 应用自动化诊断工具，能够协助企业在整个 Web 应用开发生命周期，将安全意识贯彻到企业全员具体的工做中，高效率的发现应用中存在的安全隐患、给出详细的修复建议、并生成多种符合行业标准和法规的报告，已在全球拥有近千个成功案例，是一个完整的、端到端的 Web 应用安全解决方案，能真正为企业的 Web 应用披上安全的盔甲。
本文同步分享在 博客“xjsunjie”（51CTO）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。web