第 12期：存储型 XSS

聚焦源代码安全，网罗国内外最新资讯！

*声明:《缺陷周话》栏目系列文章由360代码卫士团队原创出品。未经许可，禁止转载。

代码审计是使用静态分析发现源代码中安全缺陷的方法，能够辅助开发或测试人员在软件上线前较为全面地了解其安全问题，防患于未然，因此一直以来都是学术界和产业界研究的热点，并且已经成为安全开发生命周期SDL和DevSecOps等保障体系的重要技术手段。

360代码卫士团队基于自主研发的国内首款源代码安全检测商用工具，以及十余年漏洞技术研究的积累，推出“缺陷周话”系列栏目。每周针对CWE、OWASP等标准中的一类缺陷，结合实例和工具使用进行详细介绍，旨在为广大开发和安全人员提供代码审计的基础性标准化教程。

缺陷周话 • 第12期

存储型 XSS

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条漏洞信息与其相关。部分漏洞如下：

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行将结果集赋值给。在第108行仅过滤了标签并输出给页面。事实上来自于数据库的数据被认为是不安全的，程序与用户交互时产生危险数据未经验证或绕过安全验证存入数据库，再从数据库中获取数据时，这些危险数据有可能导致信息泄露，页面劫持等安全威胁。当查询的用户名为时，仅仅过滤标签不足以解决其他标签，向页面输出查询结果时会泄露用户 Cookie。

使用360代码卫士对上述示例代码进行检测，可以检出“存储型XSS”缺陷，显示等级为高。从跟踪路径中可以分析出数据的污染源以及数据流向，在代码行第108行报出缺陷，如图1所示：

图1：存储型 XSS 检测示例

3.2 修复代码

在上述修复代码中，第56行使用 ESAPI（ESAPI 是 OWASP 提供的一套 API 级别的开源 WEB 应用解决方案，可以帮助开发者编写更加安全的代码）中的方法对查询到的用户名进行编码，当出现敏感字符时，将使用替代字符编码敏感字符。

使用360代码卫士对修复后的代码进行检测，可以看到已不存在“存储型XSS”缺陷。如图2：

图2：修复后检测结果

4 、如何避免存储型 XSS

要避免存储型 XSS，需要注意以下几点：

（1）对用户的输入进行合理验证，对特殊字符（如、'、"等）以及、等进行过滤。

（2）采用 OWASP ESAPI 对数据输出 HTML 上下文中不同位置（HTML 标签、HTML 属性、JavaScript 脚本、CSS、URL）进行恰当的输出编码。

（3）设置属性，避免攻击者利用跨站脚本漏洞进行 Cookie 劫持攻击。在 Java EE 中，给 Cookie 添加的代码如下：