DVWA实战：存储型XSS攻击的防御与绕过技巧

1. 从零开始：理解存储型XSS与DVWA环境搭建

大家好，我是老张，在安全圈里摸爬滚打了十几年，今天想和大家聊聊一个既经典又危险的漏洞——存储型XSS。很多刚入门安全测试的朋友，一听到XSS（跨站脚本攻击）就觉得头大，反射型、存储型、DOM型，傻傻分不清楚。其实，存储型XSS可以把它想象成一种“慢性毒药”。攻击者不是直接把毒药（恶意代码）喂给你，而是把它下在了你们家公用的水井（网站的数据库）里。之后任何一个来打水（访问页面）的人，都会不知不觉中招。它的危害之所以更大，是因为一次注入，可以持续影响成千上万的用户，不像反射型XSS那样需要每次都去“骗”用户点一个特定的链接。

为了让大家能安全、合法地研究这个漏洞，我们通常会使用一个叫做DVWA（Damn Vulnerable Web Application）的靶场。这就像一个专门为我们搭建的、满是漏洞的“练功房”，在里面你怎么“折腾”都没事，不会触犯法律。DVWA把安全等级分成了四档：Low、Medium、High、Impossible，这模拟了现实中开发人员从毫无安全意识，到逐步加强防护的整个过程。我强烈建议你在自己的本地虚拟机里搭建这个环境，跟着我一步步操作，感受会完全不一样。搭建过程很简单，基本上就是装个XAMPP或者Docker，然后把DVWA的源码放进去，改改数据库配置就行。记住，永远不要在公网服务器上部署这种有漏洞的靶场，那等于给自己挖坑。

在开始实战之前，我们得先搞清楚存储型XSS攻击的完整链条。它通常发生在有用户交互和内容存储功能的地方，比如博客的评论框、论坛的留言板、用户昵称设置，甚至是商品评价区域。攻击者的payload（攻击载荷）会先被提交到服务器，然后原封不动地存进数据库。接下来，当其他普通用户浏览到这个页面时，服务器会从数据库里取出这条被“污染”的数据，并把它当作正常的网页内容的一部分，发送给用户的浏览器。浏览器可不会分辨这是用户留言还是恶意指令，它会老老实实地执行嵌入的JavaScript代码，于是攻击就发生了。理解了这个“提交->存储->读取->执行”的流程，我们后面的绕过和防御思路才会清晰。

2. LOW等级：门户大开与基础攻击手法

当我们把DVWA的安全等级调到Low时，就相当于进入了一个完全不设防的世界。这里开发者几乎没做任何过滤，是我们理解XSS原理和尝试基础payload的绝佳起点。我记得我第一次在这里测试时，输入了一个最经典的 <script>alert('XSS')</script>，然后点击提交，页面刷新后那个经典的弹窗“啪”一下就跳出来了，那种感觉既兴奋又有点后怕——原来一个简单的留言功能，如果处理不当，竟会如此脆弱。

除了在Message（留言内容）里注入，我们还会发现Name（留言者姓名）输入框有长度限制，比如只能输入10个字符。这看起来是个安全措施，对吧？但实际上，这只是前端HTML代码里的一个maxlength属性限制。对于攻击者来说，绕过它简直不费吹灰之力。你只需要按下F12打开浏览器开发者工具，在Elements（元素）面板里找到那个输入框对应的HTML代码，把 maxlength="10" 改成 maxlength="100" 或者直接删掉，然后就可以输入任意长的内容了。这个操作告诉我们一个重要的道理：永远不要依赖前端来做安全校验，前端的所有限制都只能提升用户体验，不能作为安全防线，因为用户可以完全控制自己浏览器里运行的代码。

弹个窗只是“打招呼”，存储型XSS真正的威力在于它能窃取用户敏感信息。在Low等级下，我们可以构造一个更具危害性的payload来盗取用户的Cookie。Cookie里往往包含了用户的登录会话标识（Session ID），攻击者拿到它，就能在不知道密码的情况下，直接“变成”你登录网站。一个典型的盗取Cookie的payload长这样：