一、前言
2 月份的 1.2 亿条用户地址信息泄露再次给各大公司敲响了警钟，数据安全的重要性更加凸显，这也更加动摇了咱们推广平安测试常态化的信心。随着测试组平安测试常态化的推动，有更多的共事对逻辑破绽产生了趣味，本系列文章旨在揭秘逻辑破绽的范畴、原理及预防措施，逐渐晋升大家的安全意识。作为开篇第一章，本文选取了广为熟知的 XSS 逻辑破绽进行介绍。
二、XSS 破绽介绍
1.XSS 破绽的定义
跨站脚本（Cross Site Script）, 为了不和层叠样式表 (Cascading Style Sheets,CSS) 的缩写混同，故将跨站脚本缩写为 XSS。跨站脚本（以下简称 XSS）通常产生在客户端，攻击者在 Web 页面中插入歹意 JavaScript 代码（也包含 VBScript 和 ActionScript 代码等），用户浏览此页面时，会执行这些恶意代码，从而使用户受到攻打。
2.XSS 次要攻打模式
- 存储型跨站脚本攻打
攻击者利用应用程序提供的增加、批改数据性能，将歹意数据存储到服务器中，当其余用户浏览展现该数据的页面时，浏览器会执行页面嵌入的歹意脚本，从而达到歹意攻打的目标，这种攻打是长久化的。
- 反射型跨站脚本攻打
攻击者发送一个 URL 给用户并诱导其拜访，浏览器会执行页面嵌入的歹意脚本，从而达到歹意攻打的目标，这种攻打只执行一次，是非长久化的。
- DOM 跨站脚本攻打
在 Html 页面中，未通过标准 JavaScript 间接操作用户输出的数据，当攻击者插入一段恶意代码，在页面最终展示会执行歹意脚本，从而达到歹意攻打的目标。
3.XSS 破绽危害
- 信息窃取（如盗取用户 cookie，伪造用户身份登录）
- 钓鱼欺诈
- 蠕虫攻打
三、XSS 破绽原理剖析
四、XSS 破绽实例剖析
1. 存储型 XSS
- 破绽地位其实为两处，此处相似 iframe 嵌⼊，原 url 为 test.jd.com，所以间接影响两个站
- 破绽证实：发送如下数据包，即可插⼊存储型 XSS
2. 反射型 XSS
- 输出万能语句 <script>alert()</script> 后并没有弹窗，查看源码可见 <> 被本义了
- 在 input 标签的 value 处，没有将咱们输出的内容进行严格过滤，所以手动闭合 value，再执行脚本 “><script>alert()</script>
五、XSS 破绽防备意见
1. 存储型和反射型 XSS
存储型和反射型 XSS 都是在服务端取出恶意代码后，插入到响应 HTML 里的，攻击者刻意编写的“数据”被内嵌到“代码”中，被浏览器所执行。预防这两种破绽，有两种常见做法：
1）改成纯前端渲染，把代码和数据分隔开
对 HTML 做充沛本义。浏览器先加载一个动态 HTML，此 HTML 中不蕴含任何跟业务相干的数据。而后浏览器执行 HTML 中的 JavaScript。JavaScript 通过 Ajax 加载业务数据，调用 DOM API 更新到页面上。在纯前端渲染中，咱们会明确的通知浏览器：上面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是款式（.style）等等。浏览器不会被轻易的被坑骗，执行预期外的代码了。
但纯前端渲染还需注意防止 DOM 型 XSS 破绽（例如 onload 事件和 href 中的 javascript:xxx 等，请参考下文”预防 DOM 型 XSS 攻打“局部）。在很多外部、管理系统中，采纳纯前端渲染是十分适合的。但对于性能要求高，或有 SEO 需要的页面，咱们依然要面对拼接 HTML 的问题。
2）本义 HTML
如果拼接 HTML 是必要的，就须要采纳适合的本义库，对 HTML 模板各处插入点进行充沛的本义。
罕用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 本义通常只有一个规定，就是把 & < >
”’/ 这几个字符本义掉.
2. 预防 DOM 型 XSS 攻打
DOM 型 XSS 攻打，实际上就是网站前端 JavaScript 代码自身不够谨严，把不可信的数据当作代码执行了。
在应用 .innerHTML、.outerHTML、document.write() 时要特地小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量应用 .textContent、.setAttribute() 等。
如果用 Vue/React 技术栈，并且不应用 v-html/dangerouslySetInnerHTML 性能，就在前端 render 阶段防止 innerHTML、outerHTML 的 XSS 隐患。
DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，a 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必防止。
3. 其余 XSS 防范措施
尽管在渲染页面和执行 JavaScript 时，通过审慎的本义能够避免 XSS 的产生，但齐全依附开发的审慎依然是不够的。以下介绍一些通用的计划，能够升高 XSS 带来的危险和结果。
1）Content Security Policy
严格的 CSP 在 XSS 的防备中能够起到以下的作用：
禁止加载外域代码，避免简单的攻打逻辑。
禁止外域提交，网站被攻打后，用户的数据不会泄露到外域。
禁止内联脚本执行（规定较严格，目前发现 GitHub 应用）。
禁止未受权的脚本执行（新个性，Google Map 挪动版在应用）。
正当应用上报能够及时发现 XSS，利于尽快修复问题。
对于 CSP 的详情，请关注前端平安系列后续的文章。
2）输出内容长度管制
对于不受信赖的输出，都应该限定一个正当的长度。尽管无奈齐全避免 XSS 产生，但能够减少 XSS 攻打的难度。
3）其余安全措施
HTTP-only Cookie: 禁止 JavaScript 读取某些敏感 Cookie，攻击者实现 XSS 注入后也无奈窃取此 Cookie。
作者：京东物流 范文君
起源：京东云开发者社区 自猿其说 Tech 转载请注明起源