CISP-PTE实战：从靶场到真实场景的SQL注入攻防解析

1. SQL注入实战入门：从靶场到真实场景

刚接触SQL注入时，很多人会觉得这是一项高深莫测的黑客技术。其实不然，SQL注入本质上就是通过构造特殊输入，让数据库执行我们想要的SQL语句。我在实际渗透测试中发现，90%的网站都存在不同程度的SQL注入漏洞，只是防护级别不同而已。

我们先从一个最简单的登录框开始。假设有个网站登录页面，后端代码可能是这样的：

sql复制SELECT * FROM users WHERE username='$username' AND password='$password'

如果我们输入admin'-- 作为用户名，密码随便填，实际执行的SQL就变成了：

sql复制SELECT * FROM users WHERE username='admin'-- ' AND password='123456'

--后面的内容被注释掉了，这就绕过了密码验证。我第一次用这个方法成功登录后台时，那种成就感至今难忘。不过现在大多数网站都会对这种基础注入做防护，我们需要更高级的技巧。

2. 手工注入实战技巧

2.1 信息收集与判断注入点

在靶场环境中，我习惯先用单引号'测试。如果页面返回数据库错误，基本可以确定存在SQL注入。比如在文章发布系统测试时，输入：

code复制测试' and '1'='1
测试' and '1'='2

观察两次返回结果是否不同。如果第一次正常显示，第二次不显示内容，说明存在字符型注入。

2.2 绕过常见过滤机制

现代WAF（Web应用防火墙）会过滤很多特殊字符。有次遇到一个过滤空格的系统，我用了/**/代替空格成功绕过：

sql复制1'/**/union/**/select/**/1,2,3,4#

还有次遇到过滤union的情况，尝试双写绕过：

sql复制0'ununionion select 1,2,3,4#

最棘手的是同时过滤多种字符的情况。记得有次靶场练习，我花了3小时才构造出有效的payload：

sql复制1')-+#-+(select(0x7e))-+#-+'

这个payload利用了十六进制编码和特殊注释符，成功绕过了--、#和空格的过滤。

3. sq