SQL注入防御：用三种策略应对SQL注入攻击[1]

从去年下半年开始很多网站被损害他们在用于生成动态网页的SQL数据库中存储的文本中被注入了恶意的script标签这样的攻击在年第一季度开始加速传播并且持续影响有漏洞的Web程序

这些Web应用程序有这样一些共同点

* 使用经典ASP代码的程序

* 使用SQL Server数据库的程序

应用程序代码根据URI请求字符动态地生成SQL查询这体现了一种新的SQL注入（SQL injection）的途径在过去SQL注入攻击的目标是具有如下特点的特殊Web应用程序攻击者知道或者可以探测出后台数据库的漏洞或者结构这样的攻击（指本文讨论的攻击 译者注）不同因为它是抽象的对于攻击来说任何存在于使用URI请求字符串动态创建SQL查询的ASP页面都可能存在

这样的攻击并非利用了WindowIISSQL Server或者其他底层代码的漏洞而是利用了在这些平台上运行的由程序员自行编写的代码中的漏洞Microsoft已经对这些攻击进行了彻底的调查并且发现他们和以往的Microsoft产品的补丁和day漏洞无关

正如上面所指出的这些攻击在近年来呈现一种增长的趋势这至少与两个因素有关

第一有暴力性的恶意攻击工具自动化进行此类操作该工具使用搜索引擎来寻找具有SQL注入漏洞的站点

第二一个或多个恶意僵尸正在进行SQL注入攻击用以广泛传播僵尸

一旦某台服务器被该漏洞所攻击它将被插入指向某js文件的恶意script标签虽然这些文件的内容不同但是他们都尝试利用已经被修复的Micfosoft产品的漏洞或者第三方ActiveX控件的漏洞由于这些脚本被单独存储这些脚本就很容易的被更新以利用更新的客户端漏洞也更容易按照不同浏览器来定制

给信息技术/数据库管理员的建议

有很多事情是信息技术管理员或者数据库管理员可以采取的以减少他们的风险和响应他们的代码和平台中可能出现的事件

* 检查IIS日志和数据表来寻找未知风险的标志

由于该漏洞利用方式通过URI请求字符串作用管理员们可以检查IIS日志来查找尝试利用该漏洞的非正常请求

如果IIS日志表明服务器可能已经被侵害那么下一步要采取的行动就是审计相应的Web应用程序所使用的数据库中的表并且查找附加在文本内容中的script标签

提示IIS服务器不应当在生产环境中关闭日志存储和适当的管理对于IIS日志都是重要的缺少IIS日志对于响应安全事件是非常困难的

* 如果运行了使用后端数据库的第三方代码则考虑不受SQL注入影响的独立软件开发商（ISVIndependent Software Vendors）

在使用第三方ASP Web程序的情况下管理员应当联系应用程序厂商来确定他们的产品不受SQL注入攻击的影响

* 确认Web应用程序所使用的数据库帐户具有最少的权限

管理员应当确保Web应用程序所使用的SQL用户具有最小的必要权限Web应用程序不应当以诸如sysadmin的服务器管理员权限或者db_owner的数据库权限链接

给Web开发者的建议

有很多优秀的文档论述在编码时如何防御SQL注入攻击由于这些攻击者leverage有漏洞的Web应用程序代码所以完全防御他们的唯一方法是解析在代码中存在的漏洞程序中任何一个使用外部资源（一般指从URI请求字符串）数据来动态生成SQL请求的地方都应当被认为是可疑的当代码漏洞被识别出来他们应当被小心的修复

[] []