DVWA SQL注入源代码审计

Posted 2020-12-24 Lee-404

LOW

 

打开，是个查询ID

 

利用$_REQUEST获取id参数，$_REQUEST 包含了 $_GET，$_POST 和 $_COOKIE 的数组，可以被远程用户篡改而并不可信。

直接将$_REQUEST的数据插入sql查询语句未做任何过滤,造成了SQL注入漏洞

-1\'union select user,password from users #

 

Medium

打开页面，是按钮选择查询，无法输入字符

 

查看源码，发现是用$_POST方法提交，相对比$_GET和$_REQUEST安全

 

从POST表单获取id后，使用mysqli_real_escape_string()过滤，该函数会转义 SQL 语句中使用的字符串中的特殊字符，来预防数据库攻击。下列字符受影响：\\x00 \\n \\r \\ \' " \\x1a

因为WHERE user_id = $id 是直接数字型传参，所以mysqli_real_escape_string()并未生效

是表单选择无法输入，但因为是POST方法提交表单，可以使用抓包工具，修改参数

 

 

 

 

High

先查看页面效果，发现有个链接跳转，打开链接来到session-input.php，先查看一下

 

 

 

没什么值得注意的，这个页面仅仅是将我们的输入放到了 Session 会话中，而且对我们的输入没有进行任何过滤或验证

再查看high的源码

 

从 Session 中取出 id 而没有进行任何的过滤或验证，而且是字符型注入，emmmm，其实就是跳到另一个low级别页面，不是吧，阿sir

 

Imposeable

查看页面，发现和low是一样的

 

查看源码，好了，没事了，打扰了

 

checkToken()检查token，防止CSRF

在处理用户输入的时候，首先是判断用户输入的是不是数字类型，is_nummic()函数判断id是否是数字，是返回true，否则返回false。通过这个判断可以将特殊字符或or、xor等都过滤掉，限制只能是纯数字。

使用PDO prepare 预编译的方式，没有使用常规的mysql过滤函数，因为前者可以指定参数类型，限制了传入更安全。后者可以使用编码绕过