通过分析关于互联网攻击增长的几个潜在因素，提到了关于个人信息已被明码标价在互联网上进行非法购买，而更多的黑客开始将精力投入到企业网站攻击这样的一个高回报率的攻击行为中。也提到了关于web应用防火墙对于保护企业网站和防止数据窃取方面的独到之处。今天我们就通过一个攻击实例来具体了解攻击是怎么发生的，又是如何进行数据窃取。另外，部署专业的web应用防火墙加上严格的安全管理策略才能真正为企业提供细致到位的安全防护。

 

文中引用的攻击实例发生在一家国外已部署WEB应用防火墙产品的企业，由于处在网络调整阶段，所以防火墙被临时置于“被动模式”（被动模式：只监控并记录对网站的访问，任何攻击防护都未启用），正是由于一时的疏忽，给黑客侵入该公司市场部数据库制造了机会。分析显示，发起该攻击的黑客采用了多项应用攻击手段，并且从亚洲和欧洲两个区域分别发起攻击。窃取了一部分资料，由于企业及时发现了攻击行为，并将防火墙恢复到了主动模式（主动模式：监控记录对网站的访问，并且提供安全防护），没有造成更严重的数据泄漏。

 

小贴士1：Web 应用的设计保证了数据能够透明地穿过网络防火墙，因此传统的四层网络防火墙无法检测并阻止七层（应用层）的攻击；然而，许多企业都还没有充分意识到四层安全措施已经不能满足当前的需求，从而使得这些企业极易受到针对各种应用的攻击行为。 

 

小贴士2：不管动机如何，针对 Web 应用的攻击，尤其是 SQL 注入攻击，都被证明是渗透网络并窃取数据的最有效途径：

Web 应用攻击仅占全部数据泄露事件的 54%，但被窃取的数据占92％

SQL 注入攻击仅占 Web 应用攻击的25%，但是被窃取的数据占89%

 

数据泄露事件说明：

 

此次数据泄露事件的主要原因有以下几点：

1. 网站的PHP 代码存在错误

2. 原本应定期进行的代码漏洞扫描被忽略，导致没有及时发现PHP代码问题

3. 网站维护人员没有开启Web应用防火墙的安全防护功能

对有漏洞的代码未加以保护，受到攻击只是个时间问题。根据Web应用防火墙的记录和报告，攻击的过程记录如下：

 

时间                                         描述

2011-04-10 00:07:59 GMT 第一个IP开始对网站主页进行探测

2011-04-10 00:16:15 GMT 攻击者在尝试了175个URL后找到了存在漏洞的URL，开始探测数据库

2011-04-10 03:10:43 GMT 第二个IP地址开始对存在漏洞的URL进行探测

2011-04-10 10:10:00 GMT 攻击开始，黑客试图检索数据库用户

2011-04-10 10:16:00 GMT 攻击者放弃针对用户的攻击，转而尝试获取数据库的列表(list)和架构(schema)

2011-04-10 10:19:00 GMT 攻击者开始盗取数据

2011-04-10 17:30:00 GMT 发现网站被攻击

2011-04-10 17:37:00 GMT 发现WEB应用防火墙针的防护功能暂未开启

2011-04-10 17:39:59 GMT 开启WEB应用防火墙的防护功能， 此后没有再发现任何攻击行为发生

2011-04-10 21:00:00 GMT 源自这些IP地址的攻击不再进行停止

 

数据泄露事件具体过程：我们将以图解的方式结合各式日志来分解这次攻击。

 

 

 

 

发现漏洞

 

  第一次攻击的开始时间为4月9日下午5:07，攻击者的IP地址为 115.134.249.15，来自马来西亚的吉隆坡，该日志条目证实了认为攻击来自马来西亚的在线报告。我们还注意到，攻击者用以探测 Web 网站SQL 注入缺陷的是White hats设计的渗透工具的一个修改版；

 

  第一个攻击者使用自动工具逐步遍历网站，并对每个允许输入的参数项注入一系列 SQL 命令，查找可能的漏洞。SQL 注入工具于下午 5:16 找到了第一个漏洞，但没有继续深入该网页；下午 8:10，IP地址为 87.106.220.57 的第二个客户端加入了攻击行列。经追踪发现，第二个IP地址的服务器在德国，但尚不清楚该服务器是一个代理，还是第二个攻击者。

 

 

 从Web应用防火墙的日志发现，攻击者似乎利用了第二个客户端对已发现的漏洞进行了手动攻击，而主要攻击仍然集中在继续对Web 站点进行扫描，以获取其它漏洞。最终，攻击者们集中力量攻击非主页的一个WEB 页面上的一行弱代码，其输入参数并未进行控制审查。以下是那段代码：<?=Foo_Function( $_GET[‘parameter’] )?> //获得用户输入

 

     因未对输入值进行限定，该代码错误让攻击者们得以向 HTML的输入参数进行注入 SQL 命令来攻击后台数据库。网站开发者们被告知绝对不要信任用户的输入；所有的用户输入在发送到后台服务器之前必须进行审查。然而，通过上述案例，你可以发现仅仅用眼睛很难发现所有的代码错误。这就是为什么除了必要的防范性代码设计以外，企业还需要使用漏洞扫描工具和Web应用防火墙设备来为可能的缺陷提供保护。由于自动式扫描攻击的存在，在一个含有成千上万条代码的 Web 站点中，只要有一个简单的错误就能让攻击得逞。所以还需要添加了一条代码，对受影响的页面上的输入进行限定审查，以保护未来的可能攻击。

 

从漏洞到数据泄露

 

  攻击者们发现了存在漏洞的页面后，企图窃取数据库用户账号。在接下来的 10个小时里，攻击者们尝试了数种方法来强行闯入后台数据库，但是每次都以失败告终。上午3:06，攻击者们改变了策略，集中攻击后台数据库Schema。事实证明，正是这个方法。到 3:19am，攻击者们已经窃取了第一批电子邮箱账号。

 

  网站管理员在10:30am 发现网站被攻击，并于10:39am将Web应用防火墙切换到主动模式开启保护，阻止了来自 IP 地址为 115.134.249.15 的所有后续攻击。接下来的数小时里，攻击者们继续对剩下的 Web 页面进行定时攻击，Web应用防火墙设备将所有这些攻击拒之门外。从攻击文件证实了我们的结论，即：攻击者们使用了一种自动扫描渗透工具，大范围地注入 SQL 命令。最终，攻击者们从两个攻击IP地址总共对 175 个URL 发送了 110,892 个 SQL 注入式命令，其频率为每分钟 42次。

 

  追踪Web应用防火墙上的防火墙日志和访问日志时，确定攻击者们窃取了市场部数据库中的两套记录，包含 21,861 个用户名和电子邮件记录。因为这两套记录还存在副本，并且当中有许多用户已离开原先的公司，所以受影响的用户数比被窃取记录的总数要小得多。

 

 任何数据泄露都是严重的问题。尽管这次攻击的后果还没有进一步的显现，但是类似的泄漏数据中的邮件帐号，可能被用来对受影响的用户进行钓鱼攻击。 

 

结论

 

   这次攻击事件，是一个非常有借鉴意义的教材；为企业和网管人员分享了经验，从多个角度验证对于网站攻击或者数据窃取，部署专业的设备和严格的安全管理策略必不可少。

梭子鱼Web应用防火墙设备产品能够为网站提供对包括SQL注入在内的各种攻击的防护。即使网页中包含PHP代码漏洞，但只要开启梭子鱼Web应用防火墙的防护功能，所有的攻击都在几秒钟内都被阻止。而且，梭子鱼Web应用防火墙的日志和报告提供了完整的攻击记录以及失窃数据的记录，从而为分析和研究Web应用安全提供了一个很好的案例。为了保障网站的安全，在编写高质量的代码和进行漏洞测试的同时，梭子鱼Web应用防火墙设备应该成为防御应用层攻击的第一道防线。