DVWA上SQL注入测试入门

上周有客户问我如何开始进行SQL注入测试？我向他推荐了方便的工具DVWA（DamnVulnerable Web Application）。
让我详细解释一下如何开始。

首先，用浏览器打开DVWA登录页面，输入用户名和密码进行登录。
登录后记得将安全级别设置为低，这样我们就可以很容易看到SQL注入漏洞。

Next, enter the SQL Injection test page and start testing:
1 .简单ID查询：首先测试是否可以通过输入用户ID查询到对应的用户信息。
这是最基本的测试。

2 检查注入：输入单引号，看是否返回错误。
如果返回错误，则可能存在SQL注入漏洞。

3 浏览数据库表：输入“1 或1 =1 ”。
如果返回全部内容则说明注入成功。

4 查询信息列表的长度：使用“orderby[num]”测试查看返回的结果列数，这可以帮助我们判断数据库的结构。

5 获取数据库信息：使用“unionselect”结合“user()”、“database()”、“version()”等函数获取数据库用户、数据库名称、版本和操作系统等信息。

6 查询所有数据库和表：通过注入语句查询信息，可以找到所有数据库名和表名。

7 猜表名和字段名：使用“exists”语句，结合表名和字段名来猜解。

8 爆破字段内容：最后使用unionselect结合字段名，爆破数据库中的字段内容。

至于代码分析：

低级：将输入值直接放入SQL语句中是非常危险的。

中级：虽然使用了“mysql_real_escape_string()”，但仍然有办法绕过它，并且WHERE关键字拼写错误。

高级：先用“stripslashes()”处理，然后用“mysql_real_escape_string()”，最后用“is_numeric()”检查，这样比较安全。

通过这些步骤和代码分析，您可以深入了解SQL注入漏洞利用的原理和方法，并了解如何在不同的安全级别进行防护。
不管怎样，这取决于你，但我建议你多练习，变得更加熟练。
我还在想这个问题。
如果我发现新的东西，我一定会与你分享。

绕过登录的万能密码 SQL 注入

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

说实话，刚入行的时候，SQL注入让我很害怕。
记得第一次在测试环境渲染盲注漏洞时，我的手心都出汗了，因为我看到后台直接报错，并打印了整条SQL语句——这实在是太明显了。
但后来发现很多生产环境还停留在这个水平，不得不佩服攻击者的耐心。

介绍框注入是最常见的方法。
我见过一个案例，在旅游网站的酒店搜索框直接输入“OR '1 '='1 ”，结果就是全国所有酒店的列表。
有趣的是，后台并没有对输入数据做任何处理。
这让我当时很疑惑。
也许是我在开发过程中偷懒了。
URL参数注入更加微妙。
我遇到了分页功能。
攻击者将下一页参数重写为'AND 1 =1 --，导致直接查询整个用户表。
该漏洞专门测试对动态参数场景的敏感性。

老实说，盲打问题有点神秘。
我有一个朋友，专门做渗透测试。
他告诉我一件事：通过不断改变输入和观察页面加载时间，他实际上猜出了数据库版本信息。
时间盲注就更狠了，利用SLEEP函数制造延迟。
这种类型的攻击甚至不需要读取页面内容，仅依靠数学推理。
我记得在一次测试中我输入了“AND IF(1 =1 ,SLEEP(3 ),0)”——我花了 3 秒才返回到该页面。
当时我就觉得这些攻击者太聪明了。

我对 Twitter 的攻击印象特别深刻，因为当时我还年轻，看到了他们的搜索功能被黑客攻击、数百万数据泄露的新闻。
后来我发现这是一个简单的“AND 1 =1 注入”。
关键是Twitter当时并没有参数化关键词。
雅虎！声音更难听了。
4 5 0,000 个用户数据甚至密码哈希被泄露。
这两个案例最讽刺的是，他们都是大生产者，却连最基本的输入过滤都没有做。

现在让我们看看预防措施。
参数化查询是主要关键。
我在对银行系统做安全审计的时候，发现一个项目还在使用字符串拼接来写SQL，我在需求评审会上直接拒绝了。
ORM 工具实际上是没有麻烦的，但有一个你需要注意的陷阱。
我见过使用DjangoORM时，因为查询语句没有优化，引入了N+1 个查询，最后数据库CPU提升到2 00%。
我特别同意最小特权原则。
我曾经有一个使用 root 的客户数据库帐户，但它被注入并且数据库被彻底删除。
这个教训太惨痛了。

对于WAF，我建议你不要完全信任它。
一位电商客户花费数百万购买了高级WAF，但攻击者使用了我以前从未见过的Unicode编码来绕过它。
最终还是要在代码层面解决。
毕竟，安全就像踢足球一样。
防守再好，也得有进攻思路。
就像我之前提到的电商案例一样，仅仅改变参数化是不够的。
它还必须配合代码审查。
后来发现开发者居然将数据库密码以明文形式记录在日志中——这个操作简直令人发指。

其实，技术方案总是有局限性的，关键还是要看人。
我认识一个安全研究员，他说他见过的最离谱的操作是：攻击者利用SQL注入来获取数据库权限，然后将后台管理界面更改为自己的钓鱼页面。
这种流氓操作提醒我们，技术防范必须与管理流程结合起来，否则无论多么先进的补丁也救不了你。