其实这个站点等待很久啦，一直没有修复，呜呜呜~

师傅们，我也是问了几次了，几个月了，终于等到了。。。

今天就由”威零安全“的课代表同志，当然就是本人，和各位师傅分享他的挖掘思路以及复现过程。这一波必须点个赞，进星球听了两次直播就挖到高危交大。（为什么要说这一段？其实是为了打波广告！）

个人的测试sql注入站点思路，师傅们下手轻点喷

1、寻找sql注入类型的网站，如谷歌语法：inurl:asp?id=

2、初步判断是否存在sql注入点如下：

数字型：/1 /0  +  -  * /  就是加减乘除啦

字符型：’  ‘’     “  “” 

时间型:sleep(3)  [页面无变化的话，可考虑这种]

and or等等基操

查看页面回显情况（burpsuite或原界面）、字符长度等方式从而判断是否存在sql注入点

3、如果可以的话，尝试判断数据库类型

常用的如下：mysql、sqlserver、oracle

4、构造轮子，在这个过程中经常会出现一些waf，做好心理准备，缴械投降！

小手一点，注册资料

修改注册资料，正常抓包

抓包时候发现有三个包，俺一眼就像中了这三个，但是好像她们没相中我。

look了半天，选择这个包 验证手机号码和id号的

在测试的过程中

没想到.....

发现返回包报错了，泄露sql语句，那心情叫一个激动。

猜测可能这里存在sql注入漏洞

前面说到带手机号那个数据包报错了，接着就选择这个带有手机号码和id的数据包

发送到重放模块，初步判断是否存在sql注入

对id直接进行if语句

If(1=1,1165,0)

返回1165时，页面回显为真

返回0时，页面回显为假

返回为真，因此语句构造成功

进一步构造语句，有墙对一些函数禁用

调整位置，最终构造如下语句

if((left(database(),1)='a'),1165,0)

验证语句是否构造成功

放入到爆破模块，对字母进行一个设置，一把梭哈！

再次验证

防范SQL注入，标准方案为输入验证与参数化查询相结合。

输入验证分为白名单和黑名单两种方式，通常在系统中是结合到一起来完成输入验证，具体实现通过正则表达式来完成。需要注意以下几方面：

(1)在可信系统（比如：服务器）上执行所有的数据验证。 

(2)验证所有来自不可信数据源（比如：数据库，文件流，等）的数据。 

(3)应当为应用程序应提供一个集中的输入验证机制和规则。 

(4)为所有输入明确恰当的字符集，比如：UTF-8。在输入验证前，将数据按照常用字符进行编码（规范化）。如果进行关键字的验证，请先统一大小写。

(5)验证的不仅是参数，包含所有来自客户端的数据，包括：所有参数、URL、HTTP头信息（比如：cookie名字和数据值）。 

(6)验证正确的数据类型、验证数据范围、验证数据长度。      

(7)请考虑是否允许输入常见危险字符。部分常见的危险字符包括：< > " ' % ( )   + \ \' \" 。 

(8) 特殊字符单独验证：空字节 (%00)；换行符 (%0d, %0a, \r, \n)；路径替代字符“点-点-斜杠”（../或 ..\）。验证替代字符：%c0%ae%c0%ae/ (使用规范化 验证双编码或其他类型的编码攻击)。

祝师傅们，天天有小妹陪，天天日进斗金，天天高危不重复！