- 撰稿｜谢泳
- 编辑｜王聪丽、虞珍妮
- 信息收集｜谢泳
1. 前言
上一篇介绍了跨域脚本攻击中的“反射型XSS”，列举和解释了恶意脚本注入的一些主要方式以及规避方法。事实上，除了直接注入JavaScript之外，还可以通过第三方比如flash、Java applet等进行攻击。 这些第三方工具有自己的运行环境，例如flash中使用ActionScript作为脚本，可以实现丰富灵活的功能，也为XSS提供了可乘之机，所以要避免加载用户自定义的flash；Java applet可以通过Java API获取本地机器的信息。针对第三方工具的XSS防御也需要引起重视。
2. 什么是存储型XSS
存储型XSS是一种将恶意代码保存到服务器端的攻击方式，每当有用户访问包含恶意代码的页面时，就会触发代码的执行，从而达到攻击目的。 有别于反射型XSS编写一次代码只能进行一次攻击的特点，存储型XSS的恶意脚本一旦存储到服务器端，就能多次被使用，称之为“持久型XSS”。
视频介绍链接：https://mp.weixin.qq.com/s/6c2D7wZDLtl78uiXfwvfrg
3. 攻击原理
如图1所示，存储型XSS的攻击原理是，攻击者在交互页面输入恶意代码，然后提交到web程序，如果web程序对输入内容没有做XSS的防范，就会将恶意代码存储到数据库中。接下来只要有用户去访问和查看攻击者提交的内容，当web应用响应用户请求时，恶意代码就会从服务端读取出来并执行。 因此，存储在服务端的恶意代码可以多次攻击不同的用户。例如，有一个发表动态的网站，攻击者可以在发表动态的表单中提交恶意代码，其他用户去查看攻击者的这条动态消息的时候，这些恶意脚本从服务端加载下来，被浏览器所解析和执行。
存储型XSS的payload与反射型XSS没有太多不同，也是在HTML中注入代码的道理。所以，当我们讨论存储型XSS时，关注的是如何利用web应用的XSS漏洞，向服务器提交恶意代码，也即是图1中的黑色箭头。一个重要条件是，web应用中的用户之间有一定的交互， 而非各玩各的。比方说，博客、论坛等，这种互相访问的系统才是存储型XSS生长的土壤。其次，在web系统中要找到可以存储到数据库的输入位置， 诸如表单、文本框之类的元素，在这些元素中进行正常的操作，让恶意脚本被当成普通输入数据存入数据库。当然，要使用web应用没有过滤的标签、事件， 否则输入数据被过滤之后，能够引起XSS的代码就被破坏了。
举个栗子，攻击者“小黑”在一个存在存储型XSS漏洞的论坛上输入了图2的内容，并且发表到论坛上，这段代码被服务器不加处理地保存到数据库。受害者“小锅”逛这个论坛的时候，点进去小黑发表的内容，这段代码在响应内容中返回到小锅的客户端，被浏览器加入DOM树并解析。由于src指向的内容不存在，因此触发onerror事件，恶意脚本执行，小锅看到弹窗消息显示“1”，如图3所示。小黑还可以在自己昵称、简介等输入框中输入恶意代码，当其他人点开小黑的个人信息页的时候，都会受到恶意代码攻击。
4. 防御方式
存储型XSS比反射型XSS的危害更大，在于它不需要构造特殊的URL，用户访问的是一个正常的URL也可以被攻击；另一方面，它持久化在服务端，影响的范围可以比反射型XSS更广。防御存储型XSS的方法与反射型XSS类似，对输出输入进行检查和编码，尽可能地减少数据包含代码的可能性。
