- XSS 是什么（举例说明）
- 如何预防 XSS
XSS 是什么？
Cross-Site Scripting（跨站脚本攻击）简称 XSS，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息如 Cookie、SessionID 等，进而危害数据安全。
为了和 CSS 区分，这里把攻击的第一个字母改成了 X，于是叫做 XSS。
XSS 的本质是：恶意代码未经过滤，与网站正常的代码混在一起；浏览器无法分辨哪些脚本是可信的，导致恶意脚本被执行。
而由于直接在用户的终端执行，恶意代码能够直接获取用户的信息，或者利用这些信息冒充用户向网站发起攻击者定义的请求。
在部分情况下，由于输入的限制，注入的恶意脚本比较短。但可以通过引入外部的脚本，并由浏览器执行，来完成比较复杂的攻击策略。
这里有一个问题：用户是通过哪种方法“注入”恶意脚本的呢？
不仅仅是业务上的“用户的 UGC 内容”可以进行注入，包括 URL 上的参数等都可以是攻击的来源。在处理输入时，以下内容都不可信：
- 来自用户的 UGC 信息
- 来自第三方的链接
- URL 参数
- POST 参数
- Referer （可能来自不可信的来源）
- Cookie （可能来自其他子域注入）
简单来说
1. 正常用户 A 提交正常内容，显示在另一个用户 B 的网页上，没有问题。
2. 恶意用户 H 提交恶意内容，显示在另一个用户 B 的网页上，对 B 的网页随意篡改。
造成 XSS 有几个要点：
1. 恶意用户可以提交内容
2. 提交的内容可以显示在另一个用户的页面上
3. 这些内容未经过滤，直接运行在另一个用户的页面上
举例说明
假设我们有一个评论系统。
用户 A 提交评论「小谷你好」到服务器，然后用户 B 来访问网站，看到了 A 的评论「小谷你好」，这里没有 XSS。
恶意用户 H 提交评论「<script>console.log(document.cookie)</script>」，然后用户 B 来访问网站，这段脚本在 B 的浏览器直接执行，恶意用户 H 的脚本就可以任意操作 B 的 cookie，而 B 对此毫无察觉。有了 cookie，恶意用户 H 就可以伪造 B 的登录信息，随意访问 B 的隐私了。而 B 始终被蒙在鼓里。
XSS 的成因以及如何避免
继续上面例子，之所以恶意脚本能直接执行，有两个可能
1. 后台模板问题
<p>
评论内容：<?php echo $content; ?>
</p>$content 的内容，没有经过任何过滤，原样输出。
要解决这个原因，只需要后台输出的时候，将可疑的符号 < 符号变成 < （HTML实体）就行。
2. 前端代码问题
$p.html(content)或者
$p = $('<p>'+ content +'</p>')content 内容又被原样输出了。解决办法就是不要自己拼 HTML，尽量使用 text 方法。如果一定要使用 HTML，就把可疑符号变成 HTML 实体。
XSS 攻击小游戏
以下是几个 XSS 攻击小游戏，开发者在网站上故意留下了一些常见的 XSS 漏洞。玩家在网页上提交相应的输入，完成 XSS 攻击即可通关。