1. 讲座概要内容
1.1. Web基础概念、应用安全现状
1.1.1. 什么是Web应用？
Web 应用是由动态脚本、编译过的代码等组合而成。它通常架设在 Web 服务器上，用户在 Web 浏览器上发送请求，这些请求使用 HTTP 协议，经过因特网和企业的 Web 应用交互，由 Web 应用和企业后台的数据库及其他动态内容通信。
1.1.2. Web应用的架构
由C/S架构发展到了目前应用最为广泛的B/S架构，是Web通常的标准应用架构。Web应用架构不管是三层还是四层或者四层以上的架构，都是要建立一个从服务器传输数据到客户端，由客户端用户自由操作的通道。典型的Web三层应用架构如下图1所示。
图1 典型的Web 应用三层架构模型
在这种最常见的模型中，客户端是第一层，客户端如今都由浏览器所扮演着，常见的有IE，firefox，The World；使用动态 Web 内容技术的部分属于中间层，中间层包括Web服务器层，业务逻辑层，中间件层等；而常见的数据库则是第三层，包括数据库服务器和数据文件。
在这个架构中，用户通过 Web 浏览器发送请求（request）给中间层，由中间层将用户的请求转换为对后台数据的相关操作，并将最终的结果在浏览器上展示给用户。
1.1.3. Web应用安全现状
Web应用安全，指的是Web应用的状况。什么才是 Web 安全呢，或者说什么样的网站才是安全的呢？这里列举一些用户认识上的误区。
“Web 网站使用了防火墙，所以很安全”
“Web 网站使用了 IDS，所以很安全”
“Web 网站使用了 SSL 加密，所以很安全”
“漏洞扫描工具没发现任何问题，所以很安全”
但这些方法远远不能保障 Web 应用的安全，针对应用层面的攻击可以轻松的突破防火墙保护的网站。例如：最为常见的 SQL 注入攻击表现层面完全是正常的数据交互查询。对于防火墙或者入侵检测系统而言，这是最为正常的访问连接，没有任何特征能够说明此种访问连接存在恶意攻击。所以，一些简单的 SQL 注入语句就可以使得装备昂贵网络安全设备的网站被轻松攻破。
再来看目前安全方面投资和被攻击的现状，如下图所示，目前安全投资中，只有 10％花在了如何防护应用安全漏洞，而这却是 75％的攻击来源――10％ Vs 75％，这是多么大的差距！这也是造成当前 Web 站点频频被攻陷的一个重要因素。
图2 当前安全现状统计分析图
1.2. Web常见攻击方式
目前常用的针对应用漏洞的攻击已经多达几百种，最为常见的攻击为下表列出的十种。
| 十大攻击手段 | ||
| 应用威胁 | 负面影响 | 后果 |
| 跨网站脚本攻击 | 标识盗窃，敏感数据丢失… | 黑客可以模拟合法用户，控制其帐户。 |
| 注入攻击 | 通过构造查询对数据库、LDAP 和其他系统进行非法查询。 | 黑客可以访问后端数据库信息，修改、盗窃。 |
| 恶意文件执行 | 在服务器上执行 Shell 命令 Execute，获取控制权。 | 被修改的站点将所有交易传送给黑客 |
| 不安全对象引用 | 黑客访问敏感文件和资源 | Web 应用返回敏感文件内容 |
| 伪造跨站点请求 | 黑客调用 Blind 动作，模拟合法用户 | 黑客发起 Blind 请求，要求进行转帐 |
| 信息泻露和不正确的错误处理 | 黑客得到详细系统信息 | 恶意的系统检测可能有助于更深入的攻击 |
| 被破坏的认证和 Session 管理 | Session token 没有被很好的保护 | 在用户推出系统后，黑客能够盗窃 session。 |
| 不安全的木马存储 | 过于简单的加密技术导致黑客破解编密码 | 隐秘信息被黑客解密盗窃 |
| 不安全的通讯 | 敏感信息在不安全通道中以非加密方式传送 | 黑客可以通过嗅探器嗅探敏感信息，模拟合法用户。 |
| URL 访问限制失效 | 黑客可以访问非授权的资源连接 | 黑客可以强行访问一些登陆网页、历史网页。 |
在 OWASP 组织列举的十大 Web 应用安全隐患中，有两个概率最高的攻击手段，它们分别是“跨站点脚本攻击”（Cross-Site Scripting）也称为（CSS或者XSS）和“注入缺陷”（Injection Flaws）。
跨站点脚本的利用过程，如图3所示。
图3 跨站点脚本攻击的过程
注入缺陷，其实这类攻击大多是抓住SQL漏洞来进行攻击的。因为目前的 Web 应用中，绝大多数都会向用户提供一个接口，用来进行权限验证、搜索、查询信息等功能。而这正是攻击者利用的一个点。
其他的攻击方式就不一一列举了。
1.3. Rational AppScan解决方案介绍以及操作应用
1.3.1. 原理以及简介
Rational AppScan，是对 Web 应用和 Web Services 进行自动化安全扫描的黑盒工具，它不但可以简化企业发现和修复 Web 应用安全隐患的过程（因为这些工作，以往都是由人工进行，成本相对较高，但是效率却非常低下），还可以根据发现的安全隐患，提出针对性的修复建议，并能形成多种符合法规、行业标准的报告，方便相关人员全面了解企业应用的安全状况。
AppScan包括了测试版，Build版，标准版，企业版。标准版是一个单机版工具，个人可以利用它针对Web应用进行黑盒测试。它的工作原理如下图所示：
图4 AppScan工作原理图
AppScan拥有一个庞大完整的攻击规则库，也称为特征库，通过在 http request 中插入测试用例的方法实现几百种应用攻击，再通过分析 http response 判断该应用是否存在相应的漏洞。特征库是可以随时添加的。它的扫描分为两个阶段：
阶段一：探测阶段。探测站点下有多少个Web页面。并列出来。
阶段二：测试阶段。针对探测到的页面，应用特征库实施扫描。扫描完毕，会给出一个漏洞的详细报告。
标准版的AppScan的界面示意图如图5所示
图5 AppScan界面示意图
界面分为五大区域：
（1）视图区
（2）Web应用程序树形列表区
（3）结果列表区
（4）漏洞统计区
（5）漏洞详细信息区
1.3.2. AppScan 扫描举例
下面我们通过简单的实例介绍一下 Rational AppScan 的使用：
定义扫描 首先确定扫描站点的 URL，根据默认的模板配置向导，确定扫描的整个站点模型以及你想扫描的漏洞种类。例如，我想扫描企业应用 http://www-1.fuiou.com:7010/wbp/，想根据默认值扫描是否有安全隐患，启动 AppScan，创建一个扫描，敲入 http://www-1.fuiou.com:7010/wbp/; 根据配置向导直至完成。如图6-图9所示。
图6 AppScan新的扫描
图7 AppScan Web应用扫描配置向导
图8 AppScan Web扫描配置向导——网址
图9 AppScan Web扫描配置向导
探测完毕之后，启动测试，只需要点击执行。执行完毕之后，结果区域会出现相应的结果。
如图10所示，AppScan 以各种维度展现了扫描后的结果，不仅仅定位了问题发生的位置，也提出了问题的解决方案。
图10 扫描结果界面
1.3.3. Rational AppScan 深入介绍
Rational AppScan 同时提供了很多高级功能，帮助客户对复杂应用进行检测。支持的扫描配置有：
- Starting URL：起始 URL，制定被测应用的起始地址
- Custom Error Pages：制定错误网页提高测试效率
- Session IDs：管理测试过程中的 session
- Automatic Server Detection：自动检测应用所在的应用服务器、web server、操作系统
- Exclusion and Inclusion：制定哪些 Web 被扫描或者被排除，哪些文件类型不被扫描
- Scan Limits：其他高级扫描限制，例如扫描次数限制等
- Advanced：扫描的方式，是宽度扫描还是深度扫描
- Communication Settings：对扫描中的延时、线程数量进行配置
- Proxy Settings：代理设置vLogin/logout：对被测应用的登陆进行设置，可以采用录制回放的方式、也可以使用自动登陆的方式
- configure a Test Policy: 配置测试测量，即想测试哪些漏洞。
- ……
如上所述，用户可以通过 AppScan 进行一系列高级配置，制定所要检测的 Web 模型，即哪些需要扫描、哪些不需要、扫描的方式等等；也可以定义需要扫描漏洞的列表，从而保证了用户关心的网站模型有无用户所关心的安全漏洞。在检测出安全漏洞之后，AppScan 又提供了全面的解决方案帮助客户快速解决这些问题，最大化的保证 Web 应用的安全。另外，对于 Web 服务 AppScan 同样可以支持。
AppScan 提供了完善的报表功能，可以支持用户对扫描的结果进行各种分析，包括对行业或者法规的支持程度；同时，AppScan 也提供了一系列的小工具，例如：Authentication Tester 通过暴力检测方法扫描被测网站的用户名称和密码；HTTP Request Editor 提供了编辑 Http request 的功能，等等。
1.4. Rational AppScan 的使用场景
在整个软件开发生命周期中的各个阶段，Rational AppScan 都可以被使用，全面的保障了软件的安全性。如下图11所示，软件开发过程中，软件开发人员、软件测试人员、QA、审核人员等诸多角色都可以通过 AppScan 检测应用，将漏洞尽早挖掘出来。下面我们通过一些使用场景介绍一下 AppScan 给软件开发带来的利益。
图11 AppScan 使用场景
1.4.1. 开发人员使用 AppScan
开发人员在开发过程中可以使用 AppScan 或者专用插件，随时开发随时测试，最大化的保证个人开发程序的安全性。越早发现问题，解决问题的成本就越低，这为 Web 应用的安全提供了最为坚实的基础保障。
1.4.2. 测试人员使用 AppScan
系统测试人员使用 AppScan 对应用做全面的测试，一旦发现问题，可以快速的生成 defect，通过与 ClearQuest 的集成可以实现 defect 电子化跟踪，再传递到开发人员手中，指导开发人员迅速解决问题。极大的提高了开发团队的开发效率，也提供了完整了沟通平台解决方案。
1.4.3. 审核人员上线前使用 AppScan
这是系统上线前的安全质量关卡。任何系统上线都应该经过严格的上线测试，这也最大化的减少了上线后问题的出现，避免生产系统上线后给企业带来的巨额损失。
1.4.4. 上线后审计、监控人员使用 AppScan
上线的系统应该定期检测，一旦出现问题更应该及时检测，越快速的定位发现问题，损失就会越小。
上面我们介绍的是比较通用的使用场景。当然，不同的企业可能不同的特点，AppScan 使用场景的原则是最大化的提高使用效率、尽早的把问题暴露出来，为应用安全打下坚实的基础。每个企业都可以根据自身的开发现状定义适合自己的使用模式。
2. 总结
AppScan这款软件，目前只针对Web应用和Web Service而进行的漏洞扫描，主要还是动态网页的扫描和测试。至于像咱公司后台用C写的代码，可以用静态代码分析工具进行分析，如Rational Software Analyzer。
企业版的AppScan具有如下特点：
（1） 是分布式的；
（2） 基于权限的，可定制用户操作界面的；
（3） 可定制漏洞统计报告内容；
（4） 它是对软件开发的整个生命周期进行管理的；
（5） 它有针对不同漏洞推出不同修改建议的方案；
（6） 内置Web应用安全的培训资料，方便操作员快速上手，理解漏洞扫描的整个过程；
（7） 扫描模板保存在数据库中，而不是像标准版一样保存在一个”*.scan”文件中；
（8） 开发人员，测试人员，经理可以根据不同的角色来使用AppScan。
跨网站脚本攻击一般是针对用户的操作来获取用户信息的，作为企业的管理平台或者门户网站，更多的是注重注入式攻击，尽量屏蔽对数据的非法操作。
我们公司的商户平台、终端管理平台、业务平台均是属于Web应用程序类型，因公司数据库信息均为高度保密性质，故可以试用这款软件来扫描Web应用程序的可能漏洞，测试人员提出这些可能的漏洞，报开发人员修改。
扫一扫
787
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
