---

今天的剑桥对我而言只是一百年前那个剑桥的幻影，但我还会不由自主地、一次又一 次地回那里去。站在那里我仍会觉得温暖，隐约闻到一百年前的气息，记忆中的白绸长 裙和牛津式白底高跟鞋又鲜明起来。

全文约9K字，大致阅读完约10分钟，包含主要知识点：Sqlmap常用命令、python调用SqlmapApi进行批量扫描、Python移植Sqlmap的WAF识别功能并拓展、Python完成Sql注入漏洞扫描、Python移植Sqlmap的Payload分析，其中关键部位文字使用橙色重点标注，网址使用绿色重点标注。

• 移植Sqlmap的WAF识别功能与拓展
• 批量Sql注入识别之Python检测报错型
• 批量Sql注入识别之sqlmap命令检测
• 批量Sql注入识别之封装整个sqlmap验证

使用Sqli-Labs搭建SQL注入靶场进行练习，靶场练习下载地址,手工注入练习地址

大致流程就是如此，如果想实现全自动化，就需要对传入的网址进行如下处理流程：

1. 爬行传入的网址，获取静态链接，超链接，不同路径下的超链接
2. 对爬行的链接进行清洗筛选，比如同一目录下的同一类型的请求就可以只取其一
3. 对链接进行SQL注入检测，包括但不限于报错型判断，盲注型判断，联合查询型判断等
4. 对判断存在的SQL注入的链接，交给sqlmap进行进一步获取数据，然后提取数据结果
5. 对扫描结果进一步清洗整理，自动生成漏洞扫描报告

• 对sqlmap扫描结果的数据进行清洗整理

• 扫描结果自动化生成报表

其中获取静态链接和超链接的代码工程量较大，爬取超链接有单纯的爬虫、selenium自动化获取的链接、以及抓取浏览器流量提取的链接等，本文字数太多，加在一起比较臃肿无法详细写出构架思路与代码细节，所以和SQLMAP自动生成漏扫报表一起放在日后专门文章写

基于简单的报错类批量识别

最简单的识别方式，思路是加上一些让能让数据库报错的东西，比如单引号，and1=2这样的。然后在链接上加上这些payloads，根据返回的页面是否有数据库报错语句。

比如在链接后加上单引号，页面会报错

主流数据库报错内容整理如下：

比如报错页面出现 SQL syntax 则有可能是存在mysql数据库注入，该方法最简单粗暴，但是也有最多的弊端，如果网页内容中本身就有关键词则会触发误报，有时候会直接触发防火墙，但是因为幸存者效应，该方法扫描出来真实存在注入的网站防护做的都不是很好，可以作为软柿子捏…

能引发报错的字符串如整理后保存在元祖内

数据库报错内容对应数据库数据保存在字典中

后面的就很好理解了，在爬行到的链接加上验证的payload，然后在返回的页面判断是否出现了数据库报错的语句，通过这种方式判断是否有注入。

存在mysql数据库注入

关于批量识别，将超链接保存在文本中，读取保存为列表，然后循环测试即可。

的确是很粗糙啦，性能优化有几点，以后在写…

1. 采集链接的时候还要深入二级目录下面采集，更加全面
2. 注入的Payload可以用||1=1这样，绕过安全狗之类的软件检测注入

基于Sqlmap自动批量识别

如前文所述，将爬行或者采集到的超链接保存在文本中，使用sqlmap批量命令即可，这里有个小技巧，现在许多网址都是使用伪静态，可以将静态网址保存在一起加上*号一起识别检测，站x之家等一些大网站的许多分站就是这样扫出来一大堆注入。

当然实际情况不可能这么简单的一条命令，你要需要加上一些延迟注入，或者提升sqlmap的检测等级，或者使用tamper，再或者要加入post，cookie注入等等方式。

也可以通过sqlmapapi进行批量验证，sqlmapapi返回的结果更加方便整理，方便获取想要的重要数据。

直接封装Sqlmap打包进行批量扫描

不移植部分功能了，直接基于sqlmap封装成一个体系，即直接使用sqlmap进行扫描，成功的结果再保存，这样扫描成功率将会大大提高。

即使用python的subprocess库，直接扫描链接，然后从结果清洗提取数据，这里涉及到的东西比如：

1. 获取传入网址的目录，目录下的静态链接和超链接
2. 对伪静态与url路径处理进行去重复
3. 还需要修改sqlmap源码中的一些判断流程机制，直接修改成确定输入
4. 一个网址成一个项目类，如伪静态或者其中一个url扫描确认存在注入则马上暂停该项目并保存结果
5. 扫描后的结果进行正则匹配等

详细展开还能写许多…放在以后的安全脚本开发专栏里面专门写好了QAQ

1. 加载脚本对高level测试，设置随机请求头等等优化
2. 加载前面的全部验证功能一起验证，如果其中有一个返回了成功注入结果就停止验证。

原理是即使用python的subprocess库，直接扫描链接，然后从结果清洗提取数据，这里涉及到的东西比如：

1. 获取传入网址的目录，目录下的静态链接和超链接
2. 对伪静态与url路径处理进行去重复
3. 还需要修改sqlmap源码中的一些判断流程机制，直接修改成确定输入

返回结果格式内容是这样的

其实以前一直想移植sqlmap的检测注入功能，但是太多的事情耽搁迟迟没有动手，最近为了完善Langzi_Api不得不提前着手阅读sqlmap源码移植功能，在以前的文章说过sqlmap检测注入有5种方法，依次判断注入点，通过查看sqlmap目录下的文件很容易就找到注入的payload，使用正则把他们提取出来，然后加上验证即可。

sqlmap有5中检测注入方式，排除了U 联合查询注入，S 多语句查询注入，T 基于时间盲注。
联合查询注入值截取了前面部分的payload检测方式。

保留E 错误型注入和B 布尔型注入。

然后在自定义一些注释符想让页面强制报错，完善部分。

获取前后缀拼接在注入链接前后，中间加载payload，发起网络请求，对于报错类型的对结果进行正则匹配，对盲注类型的对返回页面进行相似度判断。

联合查询有些复杂和基于时间盲注比较耗时，这里不提取验证了。

首先前后缀，请求判断方式为

基于错误型的注入根据结果正则匹配就行，基于bool类型的要判断页面相似度。获取相似度使用difflib库。

获取sqlmap前后缀来源于:

用正则提取出来，保存前后缀的字典

先看看让页面强制报错的部分payload，我做了一些整理但是可能还不完全。

这个列表的内容为一些加载url后缀，如果没有waf拦截并且网址程序员没有做过滤的话，带入到数据库执行会报错，为了编码统一对这些后缀进行url编码。

如果页面报错了就会根据下面字典重的键与值进行正则匹配判断，报错内容来源于

用正则提取出来报错的内容和对应的数据库类型，整合在一个字典中

这是我自己完善的第一步，第二步就是加载使用sqlmap的错误型注入payload，内容来源是:

同样根据正则提取内容，保存在一个新的列表中，sqlmap的巧妙之处在于使用随机获取的参数进行验证

通过两步分别加载和验证：

通过查看源码，发现sqlmap会对传入的参数进行编码，需要三个函数和一个设置一个系统默认值编码

# 注入参数字符串编码

第三步是加载盲注的payload，同样整理到字典里面了

在url1情况下： 本身页面就是对的 LEVEL 1 代表正请求与原始页面一样，正请求与错误页面不一样，正请求与负请求页面不一样，负请求与原始页面不一样，负请求与错误页面可能一样(有waf就一样) -->存在注入 LEVEL 2 代表正请求与原始页面不一样，正请求与错误页面可能不一样，正请求与负请求页面不一样，负请求与原始页面一样，负请求与错误页面不一样(有waf就一样) LEVEL 3 代表正请求与原始页面一样，正请求与错误页面不一样，正请求与负请求页面不一样，负请求与原始页面不一样，负请求与错误页面可能一样(有waf就一样) 在url2 情况下：本身页面就是错的 LEVEL 1 代表正请求与原始页面一样，正请求与错误页面可能不一样(有waf就一样)，正请求与负请求页面一样，负请求与原始页面不一样，负请求与错误页面可能一样

默认等级是level 1，注意一下，如果设置level=4的话，前面的三个也会一起扫描的，并不是设置level 4 就只扫描【复杂的基于BOOL类型的GET/POST盲注测试】，比如设置level 2 就会扫描 【 简单基于报错的GET/POST注入测试】 和【略复杂的基于报错页面的GET/POST注入测试】这样子。

欢迎关注公众号：【安全研发】获取更多相关工具，课程，资料分享哦~

这篇文章讨论常用的"sql注入"技术的细节，应用于流行的Ms IIS/ASP/SQL-Server平台。这里探讨有关这种攻击各种可以注入程序访问数据和数据库防范的方法。这篇文章面向两种读者：一是基于数据库web程序开发人员和审核各种web程序的安全专家。

结构化查询语言(SQL)是一种用来和数据库交互的文本语言SQL语言多种多样，大多的方言版本都共同宽松地遵循SQL-92标准(最新的ANSI标准[译者注：目前最新的是SQL-99])。SQL运行的典型的操作是“查询”，它是可以让数据库返回“查询结果记录集”的语句集合。SQL语句可以修改数据库的结构(用数据定义语言"DDL")和操作数据库里的数据(用数据操作语言"DML")。我们在这里着重讨论Transact-SQL(交互式SQL)，应用于SQL-Server的SQL一种方言(非标准SQL)。如果攻击者可以插一系列的SQL语句进入应用程序的数据查询时，Sql注入攻击就可能发生。

似乎通过删除用户输入的字符串中的单引号或者通过一些方法避免它们出现可以解决这个问题。诚然如此，但是要实施这个解决方法还有很多的困难。因为首先:不是所有的用户提交的数据都是字符串形式，比如我们的用户输入通过'id'(看上去是个数字)来选择一个用户，我们的查询可能会这样：
在这种情况下攻击者可以轻易的在数值输入后面添加SQL语句。在其他SQL方言中，使用着各种分隔符，比如MS Jet DBMS引擎，日期可以用'#'符号来分隔。

其次,避免单引号并不像开始我们想象的那样是必要的解决办法，原因下面讨论。
我们将以Active Server Pages(ASP)登陆页面为例子来详细说明，它访问一个Sql-Server数据库并且验证一个到我们假想的程序的访问。

这是用户填写用户名和密码的表单页面：

如果用户指定了下面这样的数据：

'users'表会被删除，所有用户都不能登陆。'--'是Transact-SQL(交互式SQL)的单行注释符，';'标志着一个查询的结束另一个查询的开始。用户名最后的'--'用来使这个特殊的查询无错误结束。

攻击者只要知道用户名，就可以通过以下的输入以任何用户的身份登陆：

攻击者可以通过下面的输入以用户表里的第一个用户来登陆：

...更有甚者，攻击者通过以下的输入可以以任意虚构的用户登陆：

因为程序相信攻击者指定的常量是数据库返回的记录集的一部分。

[通过错误信息获取信息]

这个技术是David Litchfield在一次渗透入侵测试中首先发现的，后来david写了篇关于这个技术的文章，很多作者都参考过这篇作品。这里我们讨论“错误消息”技术潜在的机制，使读者可以充分理解它并且能灵活应用。

为了操作数据库里的数据，攻击者要确定某个数据库的结构。例如：我们的"user"表是用下面的语句建立的：

并且插入了下面的用户：

我们假设攻击者要为自己插入一个用户，如果不知道表的结构的话，他不可能成功。即使他运气好，'priv'字段的重要性还不清楚。攻击者可能插入'1'，给自己在程序里添加了一个低权限的用户，而他的目标是管理员的权限。

对于攻击者来说幸运的是：如果程序返回错误(asp默认如此)，攻击者可以猜测整个数据库的结构，读取ASP程序连接到SQL-Server的帐号权限内可以读取的任何值。

(下面给出的使用上面提供的示例数据库和asp脚本来说明这些技术怎样实现的)

首先,攻击者要确定查询的表名和字段名。要做到这点，攻击者可以使用'select'语句的'having'子句：

这会引起下面的错误(译者注：having字句必须和GROUP BY或者聚合函数一起配合使用，否则出错)：

所以攻击者就知道了表名和第一列的列名，他们可以通过给每列加上'group by'子句继续得到其他列名，如下：

(结果产生这样的错误)

最后攻击者得到了下面的'username'：

这句没有错误，相当于：

如果攻击者能确定各列的数据类型将会很有用，可以利用类型转换错误信息来达到这一点，看下面的例子：

这利用了SQL-Server试图在确定两行是否相同之前先执行'sum'子句的特性，计算文本域的和会返回这样的信息：

它告诉我们'username'字段的类型是'varchar'。相反的，如果我们试图计算数值型的字段，但结果两行的列数并不匹配：

我们可以用这个技术来大概地确定数据库内各列的类型。

这样攻击者就可以写出一个格式完美的'insert'语句：

但是，这个技术的潜力不止这些。攻击者可以利用任何错误信息来暴露系统环境或者数据库信息。执行下面的语句可以得到一个标准错误信息的清单：

检查这个清单可以发现很多有趣的信息。

一个特别有用的信息有关类型转换，如果你试图将一个字符串转换成整型，整个字符串的内容将会出现在错误信息里。以我们登陆页的例子来说，使用下面的'username'将会返回SQL-Server的版本以及它所在服务器操作系统的版本信息:

这试图将内置常量'@@version'转换成整型，因为'users'表第一列是整数。

这个技术可以用来读取任何数据库的任何表的任何内容，如果攻击者对用户名和密码感兴趣，他们就可以从'users'表读用户名：

这将选出比'a'大的最小用户名,而且试图将它转换成一个整数:

攻击者就知道'admin'帐号存在，他现在可以把他发现的用户名放进'where'子句来反复测试这行：

一旦攻击者确定了用户名，他就可以搜集密码；

一个更“别致”的技术是将用户名和密码连接成一个单独的字符传，然后试图将它转换成整型。这将举另一种例子；Transact-SQL语句可以将字符串连接成一行而不改变他们的意义，下面的脚本将连接这些值：

攻击者用这个'username'登陆(明显都在同一行)

这创建了一个只包含单列'ret'的表'foo'，而且把我们的字符串放在里面。通常一个低权限的用户可以在示例数据库里创建表，或者一个临时表。

之后攻击者选择查询表里的字符串，就像前面说的：

这些例子仅仅揭开了这项技术的神秘面纱，不用说，如果攻击者可以从数据库获得丰富的错误信息，他们的工作将大大的简化。

一旦攻击者可以控制数据库，他们可能想通过这些权限来获得对网络更多的控制，可以通过很多方法来达到这一目的：

1.利用xp_cmdshell扩展存储以SQL-Server用户的身份在数据库服务器上执行命令
2.利用xp_regread扩展存储读取注册表的键值，也包括SAM(只要SQL-Server是以一个本地帐号运行的)
3.用其他的扩展存储改变服务器设置
4.在联合服务器上执行查询
7.用bcp在服务器上创建任何文本文件

这些只是常见的攻击方法的一部分；攻击者也很可能通过其他方法来达到目的，我们列举这些SQL-Server相关的攻击方法是为了说明如果程序可以被注入SQL语句时可能会发生什么，我们将依次给出以上各种情况的对策。

扩展存储的本质是编译了的动态链接库(DLLs)，它用SQL-Server指定的调用方式去运行接口函数。他们允许SQL-Server程序拥有了和c/c++一样的功能，是个非常有用的特性。SQL-Server内置了大量的扩展存储，而且有各种各样的函数比如发送邮件和更改注册表。
xp_cmdshell是一个内置的扩展存储，它允许执行任意的命令行程序。例如：

将会获得一个SQL-Server进程所在工作目录的列表

将提供主机用户的列表。如果SQL Server正常的以本地'system'帐号或者'domain user'帐号运行，攻击者可以造成更严重破坏。

另外一个有用的内置的扩展存储是xp_regXXX函数

其中一些函数的用法的举例：

(它决定服务器的空连接式共享是否可用)

(它显示所有的服务器上SNMP公共的设置，通过这个信息，攻击者可以在相同的网络区域里重新配置网络设置，因为SNMP共有设置很少被改变而且由很多主机共享)

可以想象攻击者怎样利用这些函数来读取SAM文件，改变系统设置在重新启动后就被服务的应用，或者在用户下一次登陆时运行任意命令。

xp_servicecontrol扩展存储允许用户启动，停止，暂停或者运行服务。

下面是一些其他有用的扩展存储表：

SQL-Server提供了一个服务器联合的机制，就是允许一个数据库服务器上的查询操作其他服务器的数据。这些联合设置存放在master..sysservers表里，如果一个相连的服务器使用了'sp_addlinkedsrvlogin'存储过程，一个自动的登陆了的连接已经存在，可以通过它不登陆而访问该服务器。'openquery'函数允许查询在联合服务器上执行。

[用户自定义扩展存储]

扩展存储的API是相当简单的，创建一个带有恶意代码的扩展存储DLL也是相当容易的。通过命令行有很多方法将DLL上传到服务器，还有其他的很多方法包括各种通信机制来自动实现，比如HTTP下载和FTP脚本。
一旦DLL文件出现在服务器上SQL-Server可以访问，这不一定需要SQL-server本身，攻击者可以通过下面添加扩展存储(这里，我们的恶意扩展存储是个用来操作服务器的文件系统小的木马)

扩展存储就可以通过一般的方法调用：

一旦这个扩展存储执行过，可以这样删除它:

[向表中导入文本文件]

利用'bulk insert'语句，可以把一个文本文件的内容插入进一张临时表，我们简单的创建一个表：

然后执行bulk insert来插入数据来自于一个文件：

通过上面介绍过的错误信息技巧就可以得到数据，或者通过一个'union'查询，把文本数据作为查询的数据返回。这对于获得存储在数据库里的脚本如asp脚本很有用。

[利用BCP创建文本文件]

利用和'bulk insert'作用相反的技术创建任意的文本文件非常简单。不过需要一个命令行工具'bcp'('bulk copy program')，因为bcp在SQL-Server进程外访问数据库，它需要一次登陆。但是这不难，因为攻击者都可以创建一个；或者如果服务器配置使用了“完整性”安全模式，攻击者可以利用它。

'S'参数是要运行查询的服务器，'U'参数是用户名，'P'是密码，这里的密码是'foobar'。

SQL-Server提供了一些内置的扩展存储，允许在SQL-Server内创建ActiveX自动脚本。这些脚本在功能上和windows scripting host上运行的脚本或者asp脚本(通常用Javascript或者Vbscript编写)一样，脚本创建自动对象并且通过他们产生作用。一个用Transact-SQL写的自动脚本可以做任何asp脚本或者WSH脚本能做的事。

下面提供一些例子来说明:

1)这个例子用'wscript.shell'对象创建一个notepad的实例(当然这里也可以是任何命令行命令)

在我们的例子里可以使用这样的用户名(都在一行)：

3)下面的例子创建一个asp脚本执行任意命令：

需要注意的很重要的一点是Windows NT4，IIS4平台asp脚本将会以'system'的帐号运行，而在IIS5他们会以低权限的IWAM_xxx帐号运行。

这当然也可以在我们的例子里使用，通过指定下面的'username'(注意例子不只是注入一段脚本，同时也以'admin'的身份登陆了程序)

传统的认识是如果ASP程序使用了数据库系统的存储过程，那么就不可能SQL注入了。这句话不完全对，这依赖于ASP脚本调用存储过程的方式。

本质上，一个带参数的查询执行了，用户提供的参数就被安全的传给查询，SQL注入就不可能了。但是，如果攻击者可以对无数据部分的查询语句施加任何影响，他们仍然可能控制数据库。

1. 如果ASP脚本创建了一个提交给服务器的SQL查询语句，这是很容易被SQL注入的，即使它使用了存储过程。
2. 如果ASP脚本使用了封装传递参数给存储过程的过程对象(如ADO command对象，和参数集合一起使用的)那么它通常就很安全了，但是这还要取决于对象的执行。

明显的，最好习惯于验证所有的用户输入，因为新的攻击技术会不停的涌现。

为了说明存储过程查询的注入，运行下面的SQL语句:

任何附加语句在存储过程执行后还是可以执行。

一个应用程序通常过滤单引号，另一方面限制用户的输入，比如限制长度。

在这里，我们将讨论一些绕过一些明显的SQL注入防范的和长度限制的技巧。

有时候，开发人员可能已经通过过滤单引号来保护应用程序，比如用VBScript的'replace'函数:

不可否认，这会阻止所有的对我们上面给出的对示例站点的攻击，删除';'字符也会起作用。但是，在一个大的程序里一些用户输入可能被假定为数值型。这些值没有限制，提供了很多可以注入的地方。

如果攻击者希望创建一个字符串值而不使用引号，他们可以用'char'函数。例如：

它是一个往表里插入字符的不带引号的查询语句。

当然，如果攻击者使用一个数值型的用户名和密码的话，下面的语句也同样可以很好的执行:

因为SQL-Server自动将数值型的转换成'varchar'类型，类型转换是默认的。

即使一个程序总是过滤单引号，攻击者仍然可以先注入SQL作为数据存放在数据库里然后被程序再次使用。

比如，一个攻击者可能通过注册，创建一个用户名

程序正确的过滤了单引号，'insert'语句如下：

我们假设程序允许用户更改密码，ASP脚本在设置新的密码前先确认用户旧密码正确。代码可能这样写：

设置新密码的查询语句可能这样写的：

用户名为admin'--，上面的查询就变成了这样：

因此攻击者可以通过注册了一个名叫admin'--的用户来把admin的密码改成他们自己的。

这是个危险的问题，目前大部分的大型程序都试图过滤数据。最好的解决方法是拒绝非法输入，而不是简单的改变它。这有时候会导致一些问题，非法字符在某些地方是必要的，比如在名字带符号的情况：

从安全的角度，最好的解决办法是不允许出现单引号。如果这样不行，必须避免它们出现，这种情况下，最好保证所有要进入SQL语句的字符(包括从数据库里取出的字符)都被正确的处理过。

即使这样攻击依然可能实现：如果攻击者可以不经过程序而往系统插入数据。比如攻击者有一个email接口，或者有一个可以控制的错误记录数据库。最好总是验证所有的数据，包括系统里的数据，验证函数调用很简单，比如：

有时候输入对数据的长度加以限制会使攻击困难许多，这的确阻止了一些攻击，但一个很短的SQL语句也可能造成非常大的危害：

关闭SQL-Server，只用了12个字符。另一个例子：

如果长度限制是在字符串过滤后，另一个问题可能会发生。假设用户名被限制在16个字符之内，密码也被限制在16个字符之内，下面的用户名和密码结合可以执行'shutdown'命令：

原因是程序过滤用户名最后的单引号，但是字符串又被切回到16个字符，删除了过滤的单引号。结果是密码域可以包含一些SQL, 只要它以一个单引号开始，最后的查询会变成这样:

用户名在查询里就变成:

后面附上的SQL被执行。

SQL Server在sp_traceXXX系列的函数包含丰富审核接口，它可以记录任何数据库里的事件。这里我们特别感兴趣的是T-SQL事件，它记录了所有的SQL语句以及服务器上准备好的和已运行了的批处理。如果这个级别的审核开启的话，所有我们讨论的注入都将被记录下来有经验的数据库管理员将会看到所有发生的事情。但是如果攻击者附加下面的字符：

到一个Transact-SQL语句，这个审核记录如下：

这在所有的的T-SQL日志记录时都会发生，即使'sp_password'出现在注释中。这当然是在用户传递sp_password时有意隐藏用户的明文密码，但这对攻击者相当有用。

所以，为了隐藏所有的注入攻击者只需要在注释符'--'后面加一个字符串：

事实上一些执行了的SQL将被记录，但是查询字符串本身被强制不记录。

这部分讨论一些针对这些攻击的防范措施。输入验证已经讨论过了，一些代码也给出了，后面我们研究SQL-Server防范问题。

输入验证是一个很复杂的问题。一般在一个开发项目中它很少被注意，因为过度的验证往往使一个程序的某部分被打断，所以输入验证是个难题。输入验证往往不加到程序的功能里，因而在工期将至而赶程序时不会被人注意。

下面是关于验证的简单的讨论附示例代码，这个示例代码当然不能直接用在程序里，但可以很好的说明不同的策略。

各种数据验证的途径可以分类为以下几种：

1)整理数据使之变得有效
2)拒绝已知的非法输入
3)只接受已知的合法的输入

有很多概念上的问题；首先，开发者没有必要知道非法数据由什么组成，因为新形式的非法数据随时都可能产生。第二，改变数据会改变它的长度，这样会导致前面提到的问题。最后，还有需要对系统已有数据的重用的话有二次注入的问题.

解决方案2也会遇到和1的一些相似的问题，了解非法数据会过时，因为新的攻击技术也在发展。

解决方案3可能是三种方法中最好的，但是比较难于执行。

从安全角度来考虑可能最好多解决方法是把解决方案2和3结合起来只允许合法的输入，然后再寻找非法字符。

一个必须结合这两种途径的例子是带有连字符的名字的问题：

我们必须在合法输入里允许连字符号，但是也要明白字符串'--'在SQL-Server里意味着什么。

当数据整理结合了非法字符验证时另一个问题就会发生。假设我们应用“非法字符探测器”来探测'--'，'select'和'union'”后使用“数据整理过滤器”删除单引号，攻击者就可以指定这样的输入：

因为单引号被过滤器删除了，攻击者可以把单引号散布于它的已知的非法字符串里来躲避检查。

下面是一些验证的代码:

方法2-抵制已知的非法输入

方法3-只允许合法输入