1. XSS 是什么(举例说明)
  2. 如何预防 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 的内容,没有经过任何过滤,原样输出。

要解决这个原因,只需要后台输出的时候,将可疑的符号 < 符号变成 &lt; (HTML实体)就行。

2. 前端代码问题

$p.html(content)

或者

$p = $('<p>'+ content +'</p>')

content 内容又被原样输出了。解决办法就是不要自己拼 HTML,尽量使用 text 方法。如果一定要使用 HTML,就把可疑符号变成 HTML 实体。

XSS 攻击小游戏

以下是几个 XSS 攻击小游戏,开发者在网站上故意留下了一些常见的 XSS 漏洞。玩家在网页上提交相应的输入,完成 XSS 攻击即可通关。

alert(1) to win prompt(1) to win XSS game

参考文献:https://tech.meituan.com/2018/09/27/fe-security.html