Web应用安全 -- DVWA -- XSS Stored

一、前言：

存储型XSS最典型的攻击场景就是：盗取用户cookie，如果被盗用户是网站的管理员，那后果非常严重！

今天就使用 DVWA XSS（Stored）演示一下，用户cookie是如何被盗取的。并阐述4种防御策略。

前提：已部署好DVWA，可参见《 Web应用安全 -- DVWA部署（Linux、Docker版）》

二、实验流程简述：

1）部署一个简单的服务：接受并存储盗取的cookie信息。

2）一些准备工作：DVWA改为low级别，修改文本域字符大小限制。

3）在DVWA XSS（Stored）下提交攻击语句。

4）获取cookie信息，并以该身份进入网站。

5）复盘分析

三、实验操作：

1）部署一个简单的服务：接受并存储盗取的cookie信息。

$ docker exec -it dvwa /bin/bash #进入容器 $ cd /var/www/html #进入程序部署目录 $ vim 123.php #创建一个php文件，代码见下方，i：录入，ecs退出编辑模式，:wq!：强制保存

访问：http://你的ip:8444/123.php?cookie=your cookie $ cat cookie.txt #验证，如果得到下面结果，证明部署成功~

cookie接收成功.png

2）一些准备工作：DVWA改为low级别，修改文本域大小限制

安全级别改为low

调整文本域录入限制

由于攻击脚本字符数一般都较长，客户端通过字符限制来初步防御脚本的录入，但是可以通过开发者工具将当前页面的字符限制改大，从而绕过这个初级防御策略。 这里说明一个问题：前端不可信。前端的安全、校验拦截只是初步的拦截，对一些重要的（权限、安全、业务）一定要后台做验证！这点很重要！

3）在DVWA XSS（Stored）下提交攻击语句

录入攻击脚本

点击“Sign Guestbook”按钮。

注入成功

4）获取cookie信息，并以该身份进入网站

$ cat cookie.txt #验证：再次在服务器上执行这个命令，查看结果。

成功获取cookie

# 验证：利用攻击获取的Referer和cookie登录 1、复制Referer地址。 http://你的ip:8444/dvwa/vulnerabilities/xss_s/ 2、Chrome打开无痕模式，访问上面这个地址，会踢到登录页面. 3、Chrome开发者模式，修改本地cookie。 4、再次访问Referer地址。 是不是在无密的情况下也登录进了系统？ 如果你的网站/系统存在XSS漏洞，细思极恐~！

image.png

四、复盘分析：

什么是存储型XSS：

攻击者将恶意脚本通过拥有XSS漏洞的服务存储到服务器/数据库中，当用户使用浏览器访问被嵌入恶意代码的网页时，恶意代码将在受害者浏览器上执行。

一般出现在：网站留言、评论、博客日志等交互处。

产生原因：

漏洞网站执行了攻击者上传的恶意脚本，通常形式为。

这些代码不是源站的代码，而是攻击者通过漏洞服务上传到服务器，在信息回显展示时，原样被加载到网页中，浏览器将这段代码执行，导致攻击事件发生。

产生原因

防御策略：

1、限制字符大小（输入侧防御）

由于攻击脚本一般都是很长字符，所以限制字符大小是一种基础的防御策略，但是要注意的是这个限制不仅要在前端做，后端也要进行校验。例如本文，就把前端的限制通过开发者工具给改掉，从而失去防御效果。

2、关键字替换（输入侧防御）

通过案例我们可以看到，罪魁祸首是