如何应对WEB攻击的防护盲点-51CTO.COM

WEB攻击的数量逐年上升，占了大部分攻击事件比例。WEB安全已经推到了前沿浪尖，无论是政府还是企业都迫切解决这个棘手的问题，Gartner统计：目前75%攻击转移到应用层。原有的传统防御设备已经不能满足企业对网络攻击的防御。WEB应用技术在积极发展的同时需要强有力的安全保障，所以WAF是应形势需求诞生的产品，它走上应用安全的舞台，是一个必然的趋势。

Web漏洞归类

众所周知，WEB服务系统实际不是一个单一的软件，它由OS+Database+WEB服务软件（比如：IIS、Apache）+脚本程序（比如：Jscript、PHP代码文件）构成，所以要考虑它最基本的依赖，那就是OS和Database、WEB服务软件自身的安全，这个可以通过安全加固服务来实现，而最核心的应用程序代码是不能用同样的手段来解决，这也是WEB安全问题的主要来源。

WEB 应用安全漏洞与操作系统或者网络设备的漏洞是不同的，这是因为编写代码者是不同的，产生的代码也是不同的，所以国外有成立正门的WEB安全组织来归类一些漏洞，让开发人员、安全厂家、第三方专家等能用一种一致的语言来讨论WEB安全问题。比较有名的是OWASP的TOP10漏洞，还有Web Application Security Consortium (WASC)归类的Thread Classification，如下表：

从安全角度看，WEB从设计到开发必须遵循：

1.安全设计

2.安全编码

3.安全测试（代码审计和扫描、渗透）

4.安全运维

其中最根本的在于安全设计和安全编码，也就是上线前必须保证WEB产品的自身强壮性。目前大部分的WEB应用程序是用户自己或请人编写，其他的或网站里部分组件，比如论坛、邮件系统、留言板等会用到商业版，代码是不相同的，而且程序员的水平参差不齐，更重要的是他们都遵循了软件的安全开发标准吗？

记住，这是我们为什么需要WAF的第一个理由！

攻击从未停止

让我们先看下图，是攻击网站的基本步骤和方法。

如上所示，互联网每天都充斥着数千万的攻击流量，而WAF可以自动识别和屏蔽大部分主流的攻击工具特征，使得它们在攻击的前奏就失效，绿盟科技WAF采用的是透明代理模式，使得客户端和服务器的双向流量都必须经过WAF清洗，而又无需另外配置，保持原有的网络结构，每个报文需要接受WAF对其的“搜身检查”，合格之后再进行转发。

可能有人会说Firewall和IPS不是这样的设备吗？它们为什么不能防御呢？详细的对比参数我就不列举了，大家知道OSI 7层模型，防火墙通常工作在OSI的第三层，也就是针对网络层，包括包过滤型和状态包检测型防火墙，即使是应用层防火墙也无法阻挡大多数WEB攻击行为，这是它自身技术定位决定的局限性。攻击者只需在浏览器上操纵URL就可攻击目标网站。当然，作为互补型的IDS（入侵检测系统）、IPS（入侵防护系统）产品是能防护应用层的攻击行为，但是市面上绝大多数的产品都只能防护一部分WEB攻击，甚至有些产品也是直接在IDS类产品上做修改而形成的WAF，基本只依靠规则来实现，严重滞后于繁杂多样的WEB攻击手段。当然，我在这里要重申一下，WAF可以和传统的FS+IPS作为一个有益的补充，但绝不是去代替他们。

所以，WAF的自身代理架构使得分析和阻挡攻击具有天然的优势，这是我们为什么需要WAF的第二个理由！

WAF的防护原理

好，我们再回到防护盲点的产生这个焦点话题，那就是无论如何安全设计和编码，或者经过最严谨代码审计、渗透测试之后都难免会有漏洞，因为理论上1000行代码就有1个Bug，检查只能让这些减少而已，无法真正做到没有安全漏洞的产品，这也就是为什么软件厂商会不断地推出一个个补丁来弥补，而这些Bug只要能被攻击者发现和利用那么就会带来威胁。

也就是说代码缺陷是先天存在的，即使后来修复也会具有一定的滞后性，而且不能保证100%地发现所有存在的漏洞那个缺陷。为了给大家更好地理解WAF防护的天然优势我们从两个例子来进行分析，从技术实现角度看WAF，SQL注入采用了规则集静态防护，CSRF采用了算法的动态防护。#p#

静态防护SQL注入

SQL注入的防护一直是焦点话题，从编程角度看最有效的防护是对用户输入的变量通过参数来传递，而不是直接嵌入到SQL语句，但缺陷：

1.不是所有的数据库和编程语言都有相应的参数化功能；

2.编写时面对众多的输入模块，难免会有疏漏；

3.难以批量化和统一部署。

还有一些方法就是把参数进行分类，比如用户递交的参数值统一转换成纯数字或纯字符串类型、加密用户输入、限制输入长度等，但和以上方法的缺陷一样。

比如这段代码是直接把用户输入放置数据库的SQL语句中进行执行，如果不对member_login变量进行过滤和判断是可以注入攻击的：

---漏洞代码段---
member_login=trim(request("login"))
set rs=server.createobject("ADODB.Recordset")
sql="select * from job_Member where Member_login='"&member_login&"'"
rs.open sql,conn,1,3

如果一一检查和修复需要花费大量的精力，而很多网站上线运营之后需要提高安全性的普遍举措是采用一些编写好的通用性的函数，原理是对输入进行判断和过滤，它在一定程度上能缓解攻击行为，并且花费成本相对不大，我们先看一段编写的防护函数：

---防护代码段---
<%

'定义需要过滤的输入字符

dim sql_injdata
SQL_injdata = "'|and|exec|insert|select|delete
|update|count|*|%|chr|mid|master|truncate|char
|declare|1=1|1=2|;"
SQL_inj = split(SQL_Injdata,"|"

'处理POST提交的输入

If Request.QueryString<>"" Then
For Each SQL_Get In Request.QueryString
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.QueryString(SQL_Get),
Sql_Inj(Sql_DATA))>0 Then
Response.Write ""
Response.end
end if
next
Next
End If

'处理GET提交的输入

If Request.Form<>"" Then
For Each Sql_Post In Request.Form
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.Form(Sql_Post),Sql_Inj(Sql_DATA))>0 Then
Response.Write ""
Response.end
end if
next
next
end if
%><%
'定义需要过滤的输入字符
dim sql_injdata
SQL_injdata = "'|and|exec|insert|select|delete
|update|count|*|%|chr|mid|master|truncate|char
|declare|1=1|1=2|;"
SQL_inj = split(SQL_Injdata,"|"
'处理POST提交的输入
If Request.QueryString<>"" Then
For Each SQL_Get In Request.QueryString
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.QueryString(SQL_Get),
Sql_Inj(Sql_DATA))>0 Then
Response.Write ""
Response.end
end if
next
Next
End If
'处理GET提交的输入
If Request.Form<>"" Then
For Each Sql_Post In Request.Form
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.Form(Sql_Post),Sql_Inj(Sql_DATA))>0 Then
Response.Write ""
Response.end
end if
next
next
end if
%>

以上代码首先需要定义相对完整的过滤字符集，然后分别处理用GET和POST方式提交的数据报文，在需要防护的页面里调用包括它既可[an error occurred while processing this directive]

但是编写统一的防止注入函数有缺陷：

1.需要考虑不同语言的不同语法，不能统一，比如ASP、PHP、Java；

2.要充分考虑每一个可能用户输入的地方，但往往会有疏漏；

3.虚拟机往往有大量站点，而管理者是单个站点的属主，系统管理员没权利也没能力统一定制防护措施；

4.如果是IDC或者大型企业的机房，会有更大量不同类型的WEB应用服务器，要实现批量防护则更困难；

5.消耗服务器运算资源和网络带宽，因为大批量的网络连接和提交数据都需要经过函数来处理；

6.过滤不严谨则容易被攻击者绕过。

最后一点其实很关键，不仅仅是过滤不严谨，而且攻击者对于输入可变化大小写，拼接攻击语句，甚至构造字符的不同编码方式，比如字符 < 可被编码为 <、<、&#x3c 或 %3c，而编码方式又是如此之多，Unicode、十六进制、ASIIC、UTF-8等，所以用防护函数方式是非常困难的。

通过上面描述，我们知道了从编程方式来防御攻击具有它的局限性，简单概括：会有疏漏、消耗性能、难以统一、运算复杂等。

而这时WAF的优点就体现出来了，绿盟科技WAF内置了50多条精心配制的规则，用于防护SQL注入，有人可能会疑问这么少的规则能有效防御吗？要知道虽然SQL注入的语句千变万化，但规则只需要找出共同点进行匹配即可，并且可在此基础上自定义规则。规则制定后可用于WAF后需要保护的不同类型的多台WEB服务器，类型一致的可使用同一规则，对于大型WEB群来说这具有无可比拟的优越性。它的优点如下：

1.统一定制的规则能批量适用于不同类型的网站；

2.花费时间和精力最少，无论是应用或编辑规则都方便，不用每台WEB服务器去部署；

3.即使网站存在漏洞，也能在前端把攻击流量给予清洗和阻断；

4.网站无需处理错误的探测，避免把错误处理方式和信息暴露给攻击者，同时也节省了服务器的处理资源。#p#

动态防护CSRF

CSRF全称是Cross Site Request Forgery，翻译过来是跨站请求伪造的意思，它攻击的是客户端，利用用户合法身份访问精心编制的一串url去触发一段具有某功能的脚本或CGI程序，攻击者盗用了客户的身份，并以他的名义发送恶意请求，包括：以假冒身份发送邮件，发消息，盗取用户账号，购买商品，虚拟货币转账，造成个人隐私泄露以及财产安全。特别是随着WEB2.0的普及人们越来越意识到它的攻击威力。如下是一段攻击流程：

1.访问了www.example.org

2.此页面用标签隐含了一段url，但访问时被触发访问请求

3.这段url以Get方式提交了一段具有某功能执行的请求，比如：银行转账、网上购物等

通过上图我们清晰地了解CSRF的攻击方式是利用合法用户的身份来执行恶意动作，当然利用Get方式更容易实施，但POST方式也难逃厄运，比如下一段：

合法链接？

如果把链接改成图片，并且动作设定为onmouseover就更危险了。

目前在WEB服务端抑制CSRF攻击有几种方式：

1.增加一个HASH后的cookie；

2.一次性令牌；

3.加入验证码机制，缺点是这种机制给正常用户的客户体验受损。

以上方式第3种是最佳的，比如每次请求重要功能的页面时（转账、删除等动作）会嵌入一个生成验证码图片的脚本，随机生成值（数字、ASIIC字符、中文等）让用户填写后发送到服务器并保存在session空间。但很多网站的程序员在编写时疏忽了完成每一次会话后去及时清空这个值，那么用户只要成功登陆过一次并填写了验证码之后，以后的会话就无需重新验证了，所以还是容易被利用攻击。

接着，我们来看看WAF的实现方式，相对于用特征集的静态防护，用动态防护CSRF的攻击更具职能性和灵活性，基本思路是通过WAF随机产生的隐含表单来打断一个不变的会话，也就是说即使攻击者获取到了用户身份，但是随机变化的验证码让攻击者无法构造一个不变的报文。

如下图所示，在配置WAF防护的规则之前需要设置referee的规则，然后配置域名和要防护的页面路径即可生效。

在应用了WAF的csrf防护规则之后我们可以通过抓包观察（见下图），在POST报文时发现会多了一个随机生成的隐含表单值，这个值会发送到WAF中进行匹配计算，如果不想符合则认为是攻击者构造的报文。由于这个值每次会话都变化，且长度都不同，很难被攻击者猜测到利用，具有相当高的安全性。

结束

从以上介绍，我们了解WAF对于繁杂多样的攻击能条理地归类出共性，并在WEB系统前端直接分析和过滤，由于篇幅限制，不能一一列举WAF所有防护功能的实现原理，其他的包括比如防御CC、SYN_flood等类型的拒绝服务攻击、网页挂马、防止页面篡改、WEB访问加速等，不再详述。

【编辑推荐】