【DVWA实战篇】12分钟学会 SQL 注入攻击实战

说起SQL注入，这是网络安全领域的老话题了。
我记得刚入行的时候，这个东西是论坛上的热门话题。

说实话，SQL注入是让开发者头疼、让黑客高兴的事情。
简而言之，攻击者通过将 SQL 命令插入 Web 表单或域名查询字符串来欺骗服务器执行这些命令。
就像偷偷在数据库中打开一个小后门一样，数据库中的信息可能会被窃取。

当时，我接手了一个项目，论坛后端遭遇了SQL注入。
测试时发现，输入ID字段后，页面直接报错。
当时我还很困惑，后来了解到这是SQL注入的典型症状。
数据库为MySQL，测试发现注入点为字符类型。
我们使用UNION来查询数据库字段，然后就可以得到数据库信息。

后来我使用SQLMap工具自动化了注入过程，轻松获取了数据库名、表名和字段信息。
这个过程就像玩游戏一样，一步步解码，非常有趣。

接下来，我继续进行中级SQL注入练习。
这次，安全级别设置为Medium，发现页面是通过POST发送的。
我使用 Burpsuite 等工具创建用于注入的 POST 包。
该测试证明注入点是数字化的。
我使用UNION来查询字段名并获取数据库信息。

有趣的是，后来我遇到了高级SQL注入。
这次将安全级别设置为最高级别，并且页面输入和结果显示页面分离，防止自动注入。
但注入点还在，于是我修改了SQL语句结构，使用UNION查询字段名，获取数据库信息。
这个过程和前面的过程类似，但是难度更大。

最后，我还遇到了不可能级别的SQL注入。
这次，安全级别被设置为不可能，并检测到使用了PDO技术。
PDO是PHP的一种数据对象技术，可以有效防止SQL注入攻击。
当时我就觉得这东西真的很厉害。
单独提交 SQL 语句及其变量可以防止后门。

因此，随着技术的发展，SQL注入防御方法也在不断完善。
然而，这就是网络安全领域的神奇之处。
你必须不断学习新技能来应对新挑战。

sql注入的类型

数字输入：可以直接嵌入的数字参数类型，例如：id=1 OR1 =1 字符插入：需要用引号括起来的参数字符串，例如：name='admin'OR'1 '='1 '--。
搜索注入：关闭LIKE，例如：keyword='test'OR'%1 '='%1 '。

实现联合查询：UNION SELECT，字段个数相同。
故障注入：创建故障并从故障中提取数据。
Blind：逻辑盲，看True/False；盲区时间，使用 SLEEP() 进行延迟。
宽字节注入：GBK编码，用%df'绕过。
二次部署：先存款，再发起后续请求。
堆栈注入：多个语句之间用分号分隔，例如：id=1 ;DROPTABLEusers。

XFF 实现：X-Forwarded-For 标头更改。
Cookie 实现：使用 cookie 参数完成。

SQL注入的测试方法有哪些？安全测试的最佳实践

SQL注入...你必须尝试一下。

2 02 2 年的这个时候，我正在上海的一家公司做测试。
当我遇到一个网站时，关于用户名和密码...我在输入框中输入了一个简单的引用'，然后按回车键。

嘿！页面直接崩溃，出现一堆截断字符，与数据库版本有关。
我当时很困惑，想法错误。
我赶紧告诉开发方，他们过来一看，原来是SQL注入。

还有一次...我在杭州测试一个论坛。
我发帖的时候偷偷在标题里加了AND 1 =1 -
。
这个东西是注释，但是有时候数据库处理不正确。
结果消息发送了，但是当我查看后台日志时，发现执行的SQL语句和我想象的不一样。
这意味着什么？表示注射风险。

测试不能依赖单一方法。

手动注入，需要懂一些SQL。
例如，基于布尔盲注，我可以尝试以下操作：输入 'AND 1 =1 -
并查看页面是否发生变化。
如果没有任何变化，我再试一次 ' AND 1 =2 -
。
如果这次页面显示错误，则说明中间步骤已经建立，可以进行注入了。
这需要耐心和慢慢的猜测。

时间盲注更加严重。
例如 'AND IF(1 =1 , SLEEP(5 ), 1 ) -
。
如果输入这句话后页面停止五秒钟，则表明存在漏洞。
2 02 2 年，我在一个电商网站上尝试使用这个方法，成功了！不过，他们的反应速度相当慢，花了很长时间才弄清楚。
联合查询也很常用。
例如“UNION SELECT 1 ,2 ,3 -
”。
如果数据可读，则意味着联合查询是可能的。
这需要猜测表名和列名，这有时非常乏味。

应该使用自动化工具。
SQLMap 太强大了。
我只需找到一个网站，启动并运行它，它就会自动找到注入点并自动提升权限。
2 02 2 年，我测试了一个有数千页的旧系统。
我连夜运行了 SQLMap，发现了几个高危漏洞。
但有时也会报误报，需要手动确认。

代码审计是更深层次的事情。
你需要看源码，看看数据库是如何使用的。
如果你看到用户输入直接插入到 SQL 语句中，那么基本上就有问题了。
例如，如果您看到这样的代码：
sql 字符串查询 = "SELECT FROM users WHERE username = '" + username + "'";
这肯定行不通。
您必须使用参数化查询，如下所示：
sql 字符串查询=“从用户中选择用户名=？”； PreparedStatement stmt = connection.prepareStatement(query); stmt.setString(1 , 用户名); 结果集 rs = stmt.executeQuery();
这是安全的书写方式。
2 02 2 年我给几个队伍训练过，很多人一开始都不懂，但是慢慢就学会了。

还必须进行输入验证。
您不能仅仅依赖黑名单，因为这些黑名单很容易被绕过了。
您必须使用白名单。
例如，在电子邮件字段中，您只能输入与电子邮件格式匹配的字符。
ID 字段中只能输入数字。
我在杭州遇到一个项目，其中使用正则表达式直接过滤用户输入。
然而，由于正则表达式写得不好，人们直接使用SQL注入来绕过它。

最小特权原则也很重要。
数据库连接的用户权限不能设置得太高。
我测试了一个数据库用户是sa的系统。
一旦结果注入，就可以直接删除数据库。
后来我切换到低权限用户，注入后什么也做不了。

必须部署WAF。
虽然这并不能完全解决问题，但它可以阻止许多简单的攻击。
我测试了上海的一个网站，不需要打开WAF就可以直接注入。
启用WAF后，部分注入被阻止，但高级注入仍然可以通过。

总之，对于SQL注入，你应该多尝试，多思考。
2 02 2 年，我测试了很多网站，有简单的，有复杂的。
不管怎样，只有结合多种方法才能找到问题所在。

SQL注入的常见攻击方式和案例分析

SQL 注入是......相当烦人的。
只是有人创建了恶意的SQL语句……并把它们塞进了系统……结果，数据库被搞乱了。

我以前见过...有一个客户...他们的旧系统之一...登录框...输入用户名和密码的地方...已被注入破坏。
有人刚刚在用户名里输入了一些东西...' OR '1 '='1 ...想想看...如果后端没有做过滤...这条语句就会被拼接...数据库可能会认为...满足所有条件...就会直接找到所有用户。
我当时很困惑……该怎么做。

URL参数也很常见...比如...有一个搜索框...URL是/search?term=keyword...如果这个词改成...term=' OR '1 '='1 ...那么如果后端不处理...整个数据库搜索可能会被绕过...一切都可以搜索到。
后来我意识到...这其实和输入框类似...都是使用未经过滤的输入。

还有盲注……更加微妙。
攻击者……不直接查看数据库……只取决于您输入内容后页面的反应。
例如...输入用户名'AND 1 =1 ...页面正常...然后输入用户名'AND 1 =2 ...页面就会出错...这样...攻击者就可以猜测...数据库中发生了什么。
或者使用时间盲注入...输入用户名' AND IF (1 =1 , SLEEP (5 ), 0)...如果页面等待五秒...则说明条件成立...漏洞存在。
这个方法……可能你没有什么明显的线索……特别难找。

经典案例...2 009 年的Twitter...搜索功能被注入...攻击者获取了数百万用户信息。
后来我检查了...他们只是没有参数化它...他们直接将用户输入放入SQL中。
雅虎！ 2 01 2 年的声音类似……攻击者泄露了 4 5 0,000 个用户……密码等等。
后来我发现……他们的系统很旧……并且没有得到适当的保护。
也许我有偏见……但有时这就是事情……做得不好。

如何预防？ 首选参数化查询...是使用占位符...例如 ? 或 %s... 来分隔 SQL 和输入。
例如，如果使用Python的sqlite3 ...只需编写execute(query,(用户名,密码))...这样，输入将被视为数据...而不会被作为代码执行。
这个方法……基本上可以防止大部分注射。
但请注意...某些数据库驱动程序...可能不支持它。

ORM也是一个选项...就像Django的ORM...你编写User.objects.filter(username=username)...它会在内部自动参数化它...你不必担心它。
但有时...ORM可能会产生冗余查询...注意优化。

权限也是一件事...数据库帐户...不要使用权限高的...例如root。
只需给予必要的权限...例如，您只能检查...但不能删除。
这样的话……就算注入了……攻击者也做不出什么大事。
之前有一个客户...数据库账号权限太高...结果被注入...整个表都被删除了。
后来，我得到了深刻的教训……我必须改变它。

补丁一定要跟上...像MySQL、PostgreSQL等，如果有漏洞，一定要及时打补丁。
比如2 02 1 年的Log4 j……没有打补丁……而且乱七八糟。
必须有一个流程...定期检查更新...不要等到出现问题时才进行。

还需要进行输入验证...用户输入的特殊字符...必须过滤掉。
例如，使用正则表达式...仅允许使用字母数字字符。
但要小心...黑名单是可以绕过的...你必须找到其他方法。

WAF也可以使用...它可以检测恶意代码...例如SLEEP(5 )或某物……直接拦截。
但WAF并不是万能的...规则必须及时更新...否则新的攻击将会到来...而你将无法阻止它们。

有一个电商网站...以前见过...搜索框没有参数化...结果被注入...用户的订单信息全部被捞出来。
后来改了……用了参数化……权限也被限制了……又没有发生什么。
这个东西……只是提醒你……技术一定要到位……管理也要跟上……比如代码审查……安全培训等等……都要提供。

简单来说...就是了解攻击原理...看看那些案例...然后使用一些组合技术...比如参数化...权限控制...补丁更新...输入过滤...WAF...等等...来降低风险。