使用Rational AppScan应对Web应用攻击

　　互联网的发展历史也可以说是攻击与防护不断交织发展的过程。当前，Web 安全性已经提高一个空前的高度，然而针对网站的攻击却频频得手。如何最大化的保护 Web 应用呢，IBM Rational 提出了全面的解决方案。本文将针对 Web 安全的现状、根源、以及 Rational AppScan 产品的技术细节做全面的介绍，最后阐述IBM解决方案给企业带来的深层次价值。

　　1 当前 Web 安全现状

　　互联网的发展历史也可以说是攻击与防护不断交织发展的过程。目前，全球因特网用户已达 13.5 亿，用户利用网络进行购物、银行转账支付和各种软件下载，企业用户更是依赖于互联网构建他们的核心业务，对此，Web 安全性已经提高一个空前的高度。

　　然而，现实世界中，针对网站的攻击愈演愈烈，频频得手。CardSystems 是美国一家专门处理信用卡交易资料的厂商。该公司为万事达 (Master)、维萨 (Visa) 和美国运通卡等主要信用卡组织提供数据外包服务，负责审核商家传来的消费者信用卡号码、有效期等信息，审核后再传送给银行完成付款手续。这家公司为超过 10 万家企业处理信用卡信息，每年业务金额超过 150 亿美元。这家已有 15 年历史的公司怎么也没想到，居然有黑客恶意侵入了它的电脑系统，窃取了 4000 万张信用卡的资料。这些资料包括持卡人的姓名、账户号码等。这是美国有史以来最严重的信用卡资料泄密事件。此次攻击事件不仅仅对消费者，对公司造成了巨大的损失，甚至对美国的信用卡产业产生了严重的影响!

　　1.1 Web 安全的认识误区

　　然而什么才是 Web 安全呢，或者说什么样的网站才是安全的呢?用户往往有一些常见的误区。

　　“Web 网站使用了防火墙，所以很安全”

　　无论是应用级还是端口级的防火墙针对的都是网络层面的攻击，通过设置可访问的端口或者应用，把恶意访问排除在外，然而如何鉴别善意访问和恶意访问是一个问题。访问一旦被允许，后续的安全问题就不是防火墙能应对了。

　　“Web 网站使用了 IDS，所以很安全”

　　通过模式识别对网络层面的攻击做出防护措施。然而类似于防火墙，通过利用程序漏洞，通过正常连接进行攻击的访问无法被识别和处理。

　　“Web 网站使用了 SSL 加密，所以很安全”

　　SSL 对网站发送和接收的信息都进行加密处理，然而 SSL 无法保障存储在网站里的信息的安全和网站访问者的隐私信息。采用 64 位甚至 128 位 SSL 加密的网站被黑客攻陷的例子举不胜举。

　　“漏洞扫描工具没发现任何问题，所以很安全”

　　当前漏洞扫描工具已经被广泛使用去查找一些明显的网络安全漏洞。同理，扫描工具无法对网站应用程序进行检测，无法查找应用本身的漏洞。

　　“我们每季度都会聘用安全人员(Pen Tester)进行审计，所以很安全”

　　人为的检测考察不仅仅效率低，不可控因素也较多，同时对于代码变更频繁的今天，Pen Tester 也无法满足全面的安全需求

　　然而这些方法远远不能保障 Web 应用的安全，针对应用层面的攻击可以轻松的突破防火墙保护的网站。例如：最为常见的 SQL 注入攻击表现层面完全是正常的数据交互查询。对于防火墙或者入侵检测系统而言，这是最为正常的访问连接，没有任何特征能够说明此种访问连接存在恶意攻击。所以，一些简单的 SQL 注入语句就可以使得装备昂贵网络安全设备的网站被轻松攻破。

　　1.2 Web 安全现状

　　令人惊诧的是，几乎所有关注 Web 安全领域的人都会存在着上面我们阐述的误区，而当前 Web 的安全现状也同时证明了这些误区的普遍性。“防火墙、IDS 是主要安全手段，SSL 保证了安全性，…”与之相对的是：互联网发展到今天，75%的安全问题竟然是出现在应用程序本身。正如上面介绍的 SQL 注入攻击一样，这是防火墙、SSL、入侵检测系统无法预防、解决、和应对的!

　　如下图所示，目前安全投资中，只有 10%花在了如何防护应用安全漏洞，而这却是 75%的攻击来源――10% Vs 75%，这是多么大的差距!这也是造成当前 Web 站点频频被攻陷的一个重要因素。

　　图 1. 当前安全现状统计分析图

　　那么，什么样的防护才是一个完整的解决方案呢?通过附图 2 我们可以看到，一个完整的 Web 防护不仅仅包含了常见的 IDS、Firewall 等防护手段，更需要针对应用本身做好安全防护，这也是解决 75%安全漏洞的手段。那么什么样的攻击是防火墙、IDS、或者 SSL 无法应对的呢，他们又是如何利用应用本身的漏洞进行攻击的呢?下面我们将做详细的阐述。

　　图 2. Web 应用的网络防护

　　常见针对 Web 应用攻击的十大手段

目前常用的针对应用漏洞的攻击已经多达几百种，最为常见的攻击为下表列出的十种。

　　在网站的应用中需要应用到大量的数据库查询检索等功能，例如最简单的例子是网站登陆，用户需要输入登陆名称和密码进行登陆认证。在早期的开发中通常使用最为简单的 select 语句实现此功能，即 select * from users where username = “XXXX” and password = “XXXX”( 假设数据库 user 表名称为 users，用户名和密码字段名称为 username 和 password)。通过截取用户在文本框中录入的字符串，再进行拼接，形成 select 语句，最终如果表 users 中有符合此条件的记录(即该用户名和密码)，系统将会返回有效记录，从而允许登陆系统中。

　　然而，此开发方法隐藏了一个巨大的漏洞，黑客可以通过 SQL 注入攻击攻入网站。如下图所示，黑客在登陆界面录入的不是用户名，而是一串字符串 (’or 1=1 --)。黑客的目的是在原本应该录入用户的地方录入了一串字符串，导致整个 select 语句发生了变化：select * from users where username=’’or 1=1。熟知 Select 语句的人知道，在条件语句中，无论用户名称是否正确，由于 1=1 永远是正确的，所以 select 将会将所有 users 表中的数据返回。最终的结果是，黑客登陆到这个系统中。通过 SQL 注入攻击，黑客可以轻松的敲入一些 sql 语句登陆进网站、对隐秘数据进行查询等等。

　　图 3. 攻击举例

　　通过上述原理描述我们可以看到，对于 SQL 注入攻击无论是防火墙还是入侵检测系统都无法预防和阻止，唯一的办法是将应用本身的漏洞关闭。例如通过参数的传递配合存贮过程来实现数据库查询，这比动态的构建 sql 语句安全很多。比如在 ASP.net 中通过下面的程序将会避免攻击：

　　' Visual Basic example

　　Dim DS As DataSet

　　Dim MyConnection As SqlConnection

　　Dim MyCommand As SqlDataAdapter

　　Dim SelectCommand As String = "select * from users where username = @username"

　　...

　　MyCommand.SelectCommand.Parameters.Add(New SqlParameter("@username",

　　SqlDbType.NVarChar, 20))

　　MyCommand.SelectCommand.Parameters("@username").Value = UserNameField.Value

　　// C# example

　　String selectCmd = "select * from Authors where state = @username";

　　SqlConnection myConnection = new SqlConnection("server=...");

　　SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, myConnection);

　　myCommand.SelectCommand.Parameters.Add(new SqlParameter("@username",

　　SqlDbType.NVarChar, 20));

　　myCommand.SelectCommand.Parameters["@username"].Value = UserNameField.Value;

　　除了注入缺陷攻击，常见的应用攻击还有跨网站脚本攻击、恶意文件执行攻击、不安全直接对象应用攻击、跨站点请求伪造攻击、信息泄漏以及利用错误处理机制展开攻击、等等。每种攻击都类似与 SQL 注入攻击，根据应用程序本身的漏洞，对系统进行破坏工作，例如：获取系统权限、获取机密信息、模拟合法用户等等。

　　综上所述，这些利用 Web 应用漏洞的攻击是 Web 安全最主要的威胁来源，75%的攻击来源于此，只有对应用程序本身进行改造才能避免攻击。然而，如何发现这些应用漏洞是保证安全的第一前提，我们如何以最快最有效的方式发现 Web 应用本身的漏洞呢?没有高效检测手段，安全的 Web 应用将成为水中花镜中月。