1、存储型 XSS
存储型XSS 是指应用程序通过Web请求获取不可信赖的数据，在未检验数据是否存在XSS代码的情况下，便将其存入数据库。当下一次从数据库中获取该数据时程序也未对其进行过滤，页面再次执行XSS代码，存储型XSS可以持续攻击用户。存储型XSS漏洞大多出现在留言板、评论区，用户提交了包含XSS代码的留言到数据库。当目标用户查询留言时，那些留言的内容会从服务器解析之后加载出来。浏览器发现有XSS代码，就当做正常的HTML和JS解析执行，存储型XSS就发生了。本篇文章以JAVA语言源代码为例，分析CWE ID 80：ImproperNeutralization of Script-Related HTML Tags in a Web Page (Basic XSS)（http://cwe.mitre.org/data/definitions/80.html）样本存储型XSS漏洞产生的原因以及修复方法。 详见：
- CWE ID 79: ImproperNeutralization of Input During Web Page Generation (‘Cross-site Scripting’) (http://cwe.mitre.org/data/definitions/79.html)
- CWE ID 80: Improper Neutralization ofScript-Related HTML Tags in a Web Page (Basic XSS)(http://cwe.mitre.org/data/definitions/80.html)
- CWE ID 81: Improper Neutralization of Scriptin an Error Message Web Page (http://cwe.mitre.org/data/definitions/81.html)
- CWE ID 82: Improper Neutralization of Scriptin Attributes of IMG Tags in a Web Page (http://cwe.mitre.org/data/definitions/82.html)
- CWE ID 83: Improper Neutralization of Scriptin Attributes in a Web Page (http://cwe.mitre.org/data/definitions/83.html)
2、 存储型 XSS 的危害
存储型XSS攻击方式主要是嵌入一段远程或者第三方域上的JS代码，并在目标域执行这些代码。存储型XSS会造成Cookie泄露，破坏页面正常的结构与样式，重定向访问恶意网站等。从2018年1月至11月，CVE中共有215条漏洞信息与其相关。部分漏洞如下：
| CVE | 漏洞概述 |
|---|---|
| CVE-2018-19178 | 在JEESNS 1.3中，com / lxinet / jeesns / core / utils /XssHttpServletRequestWrapper.java允许通过 HTML EMBED 元素进行存储型XSS攻击。 |
| CVE-2018-19170 | JPress，一个 wordpress 的 java 代替版本，使用 JFinal 开发，支持类似 wordpress 的几乎所有功能。在 JPress v1.0-rc.5 中，通过前面三个输入字段，可进行存储型XSS攻击 starter-tomcat-1.0 / admin / setting URI。 |
| CVE-2018-19089 | Tianti是基于 Java 的轻量级 CMS 解决方案，tianti 2.3 通过 tianti-module-admin / user /ajax / save_role name 参数在用户列表模块存在存储型XSS漏洞，该参数在 tianti-module-admin src main webapp WEB-INF views user user_list.jsp。 |
| CVE-2018-17369 | Java EasyCms 是一个开源 cms 系统。发表文章时， EasyCMS 1.3 存在存储型XSS漏洞; 四个字段受到影响：标题，关键字，摘要和内容，如 /admin/index/index.html#listarticleURI所示。 |
3、示例代码
示例源于 SamateJuliet Test Suite for Java v1.3 (https://samate.nist.gov/SARD/testsuite.php)，源文件名：CWE80_XSS__CWE182_Servlet_database_01.java。
3.1缺陷代码
上述示例代码操作是获取用户姓名输出到页面。在第46行获取数据库连接对象，第49行创建查询语句查询id等于0的用户姓名，在第55行将结果集赋值给 data。在第108行仅过滤了 <script> 标签并输出给页面。事实上来自于数据库的数据被认为是不安全的，程序与用户交互时产生危险数据未经验证或绕过安全验证存入数据库，再从数据库中获取数据时，这些危险数据有可能导致信息泄露，页面劫持等安全威胁。当查询的用户名为 alert(“document.cookie”) 时，仅仅过滤 <script> 标签不足以解决其他 html 标签，向页面输出查询结果时会泄露用户 Cookie。
使用360代码卫士对上述示例代码进行检测，可以检出“存储型XSS”缺陷，显示等级为高。从跟踪路径中可以分析出数据的污染源以及数据流向，在代码行第108行报出缺陷，如图1所示：
图1：存储型 XSS 检测示例
3.2 修复代码
在上述修复代码中，第56行使用 ESAPI（ESAPI 是 OWASP 提供的一套 API 级别的开源 WEB 应用解决方案，可以帮助开发者编写更加安全的代码）中的 encodeForHTML() 方法对查询到的用户名进行 HTML 编码，当出现敏感字符时，将使用替代字符编码敏感字符。
使用360代码卫士对修复后的代码进行检测，可以看到已不存在“存储型XSS”缺陷。如图2：
图2：修复后检测结果
4 、如何避免存储型 XSS
要避免存储型 XSS，需要注意以下几点：
（1）对用户的输入进行合理验证，对特殊字符（如<、>、’、”等）以及 <script>、 javascript 等进行过滤。
（2）采用 OWASP ESAPI 对数据输出 HTML 上下文中不同位置（HTML 标签、HTML 属性、JavaScript 脚本、CSS、URL）进行恰当的输出编码。
（3）设置 HttpOnly 属性，避免攻击者利用跨站脚本漏洞进行 Cookie 劫持攻击。在 Java EE 中，给 Cookie 添加 HttpOnly 的代码如下：
