DVWA渗透测试演示（下）

八、DVWA之PHP+MySQL手工注入：

（1）SQL注入：在用户的输入没有为转移字符过滤时，就会发生这种形式的注入攻击，它会被传递给一个SQL语句。这样就会导致应用程序的终端用户对数据库上的语句进行操纵。就是通过吧SQL命令插入到web表单或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意代码的SQL命令。

（2）view source:

由此可知，当输入正确的ID时，将显示ID：xxx  First name:xxx  Surname:xxx

（3）测试过程如下：

输入“  ’  ”,返回错误如下：

输入1 or 1=1，尝试遍历数据库表：

目的失败，猜解程序将此处看成了字符型，可以尝试构造“  1' or '1'='1 ”来进行遍历改数据库表：

‘

这里使用order by number语句来测试查询信息列表：

1’ Order by 1 --    

1’ order by 2 -- 

1’ order by 3 -- 

注意：输入时“--”之后有空格

所以我们可以知道结果值为两列。

接下来我们使用user(),datebase(),version()这三个内置函数来分别获取数据库的账户名、数据库名、数据库版本信息：

首先输入：1’ and 1=2 union select1,2 – 

由上图可知，得出Fist name处显示结果为查询结果第一列的值，surname处显示的结果为查询结果第二列的值。

得知显示后，我们使用user(),database(),version(),三个内置函数得到链接数据库的账户名、数据库名称、数据库版本信息，输入：

1’ and 1=2 union select user(),database() –

所以得到数据库名称：root@localhost，数据库名称：dvwa

之后是使用以下注入语句获取数据库版本信息：

1’ and 1=2 union select version(),database() -- 

通过注入：1’ and 1=2 union select1,@@global.version_compile_os from mysql.user –获取操作系统信息：

通过注入：1’ and 1=2 union select1,schema_name from information_schema.schemata –

查询MySQL数据库中所有的数据库的名字：这里利用MYSQL默认的数据库information_scehma，该数据库存储了MySQL所有的数据库和表的信息，如下图所示：

通过注入：1’ and exists(select *from users) – 猜解dvwa数据库的表名：

猜解字段名：

1’ and exists(select 表名 from users) –

爆出数据库胆子字段的内容：

1’ and 1=2 union select first_name,last_name from users–

这个其实就是存放管理员账户的表，那么有户名、密码就爆出来了：

查看low等级的源代码：

由代码可以看出，对输入$id 的值并没有任何过滤就直接带入数据库进行了查询，这样带来的隐患极大！

中等级安全过滤：

可以看到中等级别时，对$id 的数值使用了mysql_real__eascape_string()函数进行了处理。此函数的作用在于“转义SQL语句中使用字符串的特殊字符”，但是使用这个函数对单数进行转换时存在绕过的，只需要将攻击字符进行转换一下编码格式就可以绕过防护函数，比如使用ＵＲＬ编码方式。

同时发现此处的ＳＱＬ语句变成了“where user_id=$id”的形式，所以此时变为了数字型注入，所以此函数几乎没有起到防护作用，我们课使用1 pr 1=2 语句来进行注入。

高级代码过滤验证：
验证源码：

从源代码中可以看出，此处认为字符型注入。对传入$id的值使用`stripslashes()`函数处理以后，在经过到`$mysql_real_escape_string()`函数进行第二次过滤。在默认情况下，PHP会对所有的GET，POST，,和cookie数据自动运行`addslashes()`，`adslashers()`函数返回在部分与定义之前添加反斜杠。就是将“’”变成“\’”，`Stripslashes()`函数则是删除由`addslashes()`函数添加的反斜杠。在使用两个函数进行过滤之后再使用`is_numric()`函数检查$id的值是否为数字，彻底断绝了注入的存在。此种防护不存在绕过的可能。

九、DVWA之反射性XSS

（1）跨站脚本攻击（Cross Site Scripting）为了不和层叠样式（Cascading Style Sheets,CSS）的缩写一致，故将跨站脚本攻击缩写为XSS。恶意攻击者往WEB页面中插入恶意HTML代码，当用户浏览该页面时，嵌入其中WEB里面的HTML代码会被执行，从而达到恶意攻击用户的目的。

（2）XSS攻击分为两种类型：

非持久性攻击

持久性攻击

（3）测试流程：

调节安全级别为low：

打开XSS（Reflected）:

随便测试用例：Tom

发现会直接显示“hello+你所输入的内容”

尝试一个弹框操作：

输入：<script>alert(/xss/)</script>test之后点击提交：

点击确定之后：

查看view source：

可以看出只是对是否输入进行了检测，至于输入内容没有进行任何检测与过滤，由此导致了XSS漏洞。

（4）中等级别的反射性XSS：

调节安全级别我medium：

查看验证源码：

可以看出，此处使用了str_replace()函数将<script>用空格来代替过滤，但是这种防护有缺欠，并未对大小写进行严格的过滤，所以我们可以照样输入一下代码进行Xss漏洞的利用：

<Script>alert(/xss/)</Script>test

点击提交后：

至于高级验证如下：

几乎没法绕过，过滤严谨！

十、DVWA之存储型XSS

（1）测试流程：

调解安全等级为low：

打开XSS（Stored）页面：

在message一栏中输入：

<Script>alert(/xss/)</Script>test   

提交后，弹出XSS页面，并且每次刷新都会弹窗：

查看源代码：

可以看到此处对输入Name、message中的仅仅做了防止SQL注入的过滤，没有对输入的字符安全性的过滤。

（2）中等级别的反射性XSS

调节安全验证机制为medium级别：

查看源码：

虽然过滤有所提高但是未对大小写进行严格过滤：

输入：<Script>alert(/xss/)</Script>test  

（3）高级存储型XSS：

调节安全级别为high：

查看验证源码：

可以看出此处对Message和Name的参数使用htmlspecialshars()函数进行了转换，htmlspecialchars()函数主要是将一些预定义的字符转换为HTML实体。使得此处输入代码后无法执行。但是使用该函数过滤并不能保证万无一失，需要看具体场景。构造特殊的编码或者语句是可以绕过该函数的防御。但在此处无法绕过该函数。