一、Brute Force（暴力破解）漏洞
（级别：low）：
1.查看代码
可以看到，服务器只是验证了参数Login是否被设置，没有任何的防爆破机制
2.使用burpsuit抓包
3.单击Action发送到Intruder进行密码爆破
4.先清除 ，然后选中要爆破字段，点击添加
5.设置Payloads
6.点击右上角开始攻击
7.成功爆破
测试过程（级别：medium）：
1.查看代码
从源码可以看到，与初级相比多出了红框框的内容，就是对一些特殊字符进行了转义还是与初级一样进行爆破
4.1.3.修复建议
1.如果用户登录次数超过设置的阈值，则锁定帐号(有恶意登录锁定帐号的风险)
2.如果某个 IP登录次数超过设置的阈值，则锁定IP
3.增加人机验证机制
二、Command injection（命令执行）漏洞
（级别：low）：
1.查看代码
可以看图中红框圈出的语句，可以发现没有任何的保护措施，ip字段如果在IP后面加 ‘|’ 再添加一个命令，则会直接执行该命令。
2.执行127.0.0.1&&ipconfig
3.执行127.0.0.1 | netstat -nr
测试过程（级别：medium）：
1.查看代码
屏蔽了&&和；并没有对我们的&和|进行过滤，所以我们可以用后两个来进行，也可以用双写来绕过，比如我们可以构造这样一个命令连接符&;&,它只会过滤其中的分号，然后剩余的其他字符，又连接成为了&&，同样达到了目的与低等级一样ip字段如果在IP后面加 ‘|’ 再添加一个命令，则会直接执行该命令。
2.执行127.0.0.1&;&whoami
4.2.3.修复建议
1.减少或不使用代码或命令执行函数
2.客户端提交的变量在放入函数前进行检测
3.减少或不使用危险函数
三、.CSRF（跨站请求伪造）漏洞
（级别：low）：
1.查看代码
http://192.168.215.1:9096/DVWA/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change# —用户只要访问以上链接密码就会直接被更改
4.3.3.修复建议
1、验证http referer字段根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。
2.在请求中加入不可伪造的token，并在服务端验证token是否一致或正确，不正确则丢弃拒绝服务。
3.CSRF攻击是有条件的，当用户访问恶意链接时，认证的cookie仍然有效，所以当用户关闭页面时要及时清除认证cookie，对支持tab模式（新标签打开网页）的浏览器尤为重要。
4.尽量少用或不使用request（）类变量，获取参数指定request.form()还是request.querystring(),这样有利于阻止CSRF漏洞攻击，此方法只不能完全防御CSRF攻击，只是一定程度上增加了攻击难度。
四、File Inclusion（文件包含）漏洞
（级别：low）：
1.查看代码
从Low级别的代码我们可以看出，服务端对上传的的page参数没有任何过滤
2.点击file1.php效果如下：
3.burpsuit抓包
4.首先我们尝试包含本地一个不存在的文件
出现上图所示报错，从第一行警告我们可以看出它使用的是include函数，也直接爆出了含有include函数文件的位置；从第二行我们可以看出没有找到指定文件
5.尝试包含一个存在的，在已经文件路径的前提下
6.尝试使用…/来进行目录穿越（…/表示返回上一层目录）
已知test.php的绝对路径在D:\phpStudy\WWW\DVWA\vulnerabilities\test.php
我们当前在http://127.0.0.1:8008/dvwa/vulnerabilities/fi/下，由下图文件具体位置可以看出，一个…/就返回到了有test.php目录的目录
4.4.3.修复建议
1.建议白名单：判断文件类型在判断文件类型时，可以结合MIME Type、后缀检查、文件内容检查等方式。
2.使用随机数、时间戳改写文件名和文件路径:脚本文件上传后，如果要执行代码，就必须要能够访问到这个文件。
3.单独设置文件服务器域名
五、File Upload（文件上传）漏洞
（级别：low）：
1.上传文件在服务器上存放的路径
2.到我们的一句话成功上传，我们尝试用菜刀连接一下
3.查看代码
看来没做什么过滤，文件路径就是DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/"再加上文件名。
4.5.3.修复建议
1.通过白名单的方式判断文件后缀是否合法
2.对上传后的文件重命名，并且自定义添加后缀
3.文件上传目录设置为不可执行权限
4.文件上传目录设置为不可执行权限
六、.不安全的验证码（Insecure CAPTCHA）漏洞
（级别：low）：
1.打开config.inc.php
2.修改在/var/www/html/config/config.inc.php 中添加字段
3.修改后会加载出此页面
4.输入账号密码后由于加载不出验证码无法登录，需要*
5.burpsuit抓包
6.更改step参数绕过验证码：
4.6.3.修复建议
修改验证逻辑，如是否登录成功服务器端返回一个参数，但是到此就是最终验证，不需要再对返回的参数进行使用并作为登录是否成功的最终判断依据！
七、Sql Injection（sql注入）漏洞
（级别：low）：
1.输入用户1
2.输入用户2
3.输入1’ or ‘1’=’1
4.输入1’ order by 2#
6.暴库：查询database，1’ union select 1,database()# ,可以看出database是dvwa
5.暴表名：查询table_name, 1’ union select 1,(select group_concat(table_name) from information_schema.tables wheretable_schema=‘dvwa’)#
7.暴字段名：1’ union select 1,(select group_concat(column_name) from information_schema.columns where table_name=‘guestbook’)#
- 爆字段名：1’ union select 1,(select group_concat(column_name)from information_schema.columns where table_name=‘users’)#
8.暴字段值：1’ union select 1,(select group_concat(User,Password) from users)#
9.看到用户名是admin，密码使用MD5进行解密
10.查看代码
直接把id放到sql语句，没有做任何处理。
4.7.3.修复建议
1、对数据库进行严格监控
2、对用户提交数据信息严格把关，多次筛选过滤
3、用户内数据内容进行加密
4、代码层最佳防御sql漏洞方案：采用sql语句预编译和绑定变量，是防御sql注入的最佳方法
八、Sql盲注 （SQL Injection Blind)漏洞
（级别：low）：
与刚才的题差不多
1.暴库：查询database，1’ union select 1,database()#,可以看出database是dvwa
2.暴表名：查询table_name, 1’ union select 1,(select group_concat(table_name) from information_schema.tables where table_schema=‘dvwa’)#
3.暴字段名：1’ union select 1,(select group_concat(column_name) from information_schema.columns where table_name=‘users’)#
4.暴字段值：1’ union select 1,(select group_concat(User,Password) from users)#
4.8.3.修复建议
1.确认每种数据的类型，比如数字型的数据就必须是数字，数据库中的存储字段必须对应为int。
2.数据长度应该严格规定，能在一定程度上防止比较长的SQL注入语句无法正确执行。
3.网站每个数据层的编码统一，建议全部使用UTF-8编码，上下层编码不一致有可能导致一些过滤模型被绕过。
九、弱会话ids（Weak Session IDs）漏洞
（级别：low）：
1.burpsuit抓包
2.构造payload：dvwaSession=12; security=low;PHPSESSID=9uu34n47j66u3g420tv8j7chu0
3.通过火狐浏览器的hackbar，提交，选择cookie提交方式，提交后发现直接登录dvwa，绕过密码验证：
4.9.3.修复建议
由于SessionID是用户登录之后才持有的唯一认证凭证，因此黑客不需要再攻击登陆过程(比如密码)，就可以轻易获取访问权限，无需登录密码直接进入特定用户界面， 进而查找其他漏洞如XSS、文件上传等等。
十、XSS（DOM）(DOM型跨站脚本)漏洞
（级别：low）：
1.查看代码
2.插入参数default= <script>alert(/xss/)</script>
4.10.3.修复建议
DOM型XSS主要是由客户端的脚本通过DOM动态地输出数据到页面而不是依赖于将数据提交给服务器端，而从客户端获得DOM中的数据在本地执行，因而仅从服务器端是无法防御的。其防御在于：
1.避免客户端文档重写、重定向或其他敏感操作，同时避免使用客户端数据，这些操作尽量在服务器端使用动态页面来实现；
2.分析和强化客户端JS代码，特别是受到用户影响的DOM对象，注意能直接修改DOM和创建HTML文件的相关函数或方法，并在输出变量到页面时先进行编码转义，如输出到HTML则进行HTML编码、输出到
十一、XSS（Reflected）(反射型跨站脚本)漏洞
（级别：low）：
1.查看代码
可以看到系统直接使用了name参数，没有做任何过滤
2.插入参数 <script>alert(/一个嚣张的XSS/)</script>
4.11.3.修复建议
1.假定所有输入都是可疑的，必须对所有输入中的script、iframe等字样进行严格的检查。这里的输入不仅仅是用户可以直接交互的输入接口，也包括HTTP请求中的Cookie中的变量，HTTP请求头部中的变量等。
2.不仅要验证数据的类型，还要验证其格式、长度、范围和内容。
3.不要仅仅在客户端做数据的验证与过滤，关键的过滤步骤在服务端进行。
十二、XSS（Stored）(存储型跨站脚本)漏洞
（级别：low）：
1.查看源码可以看到直接用sql语句存储了，并没有多余的设置
2.由于name这一输入栏被设置了长度，初步判断是有前端代码的限制
3.看到 maxlength = 10 限制了我们的输入长度，取前端的设置绕过的
4.修改好以后，我们接着在Name上面输入
4.12.3.修复建议
xss漏洞本质上是一种html注入，也就是将html代码注入到网页中。那么其防御的根本就是在将用户提交的代码显示到页面上时做好一系列的过滤与转义。
1.采用htmlspecialchars()函数对用户的输入进行过滤,或者设置严格的白名单过滤用户输入的内容.
2.对输出的数据也要检查，数据库里的值有可能会在一个大网站的多处都有输出，即使在输入做了编码等操作，在各处的输出点时也要进行安全检查。