XSS 跨站脚本攻击：特点与防范(图文)

XSS 跨站脚本攻击（Cross-Site Scripting）是一种常见的网络安全漏洞。攻击者利用这个漏洞在目标网站上注入恶意脚本，当用户访问包含恶意脚本的网页时，浏览器会解析并执行这些脚本，从而导致各种安全问题。
常见的攻击场景有很多。例如，在具有用户输入功能的地方，如搜索框、评论区、联系表单等，攻击者可以注入恶意脚本。反射型 XSS 攻击中，攻击者诱使用户点击一个嵌入恶意脚本的链接，用户提交的数据被立即反馈到浏览器，恶意脚本直接嵌入在 URL 中。比如，用户可能会收到一个看似正常的链接，但实际上链接中包含恶意脚本，一旦用户点击，恶意脚本就会在用户的浏览器中执行。
存储型 XSS 攻击则更为危险，攻击者将恶意脚本存储在服务器端，比如存储在数据库中。当其他用户访问相关页面时，恶意脚本就会被执行。想象一下，一个攻击者在论坛上发表一篇带有恶意脚本的文章，所有阅读这篇文章的用户都会受到攻击。
DOM 型 XSS 攻击通过修改页面的 DOM 结构来执行恶意脚本，攻击代码无需经过服务器。例如，攻击者可以利用网页中的 JavaScript 代码漏洞，修改页面的 DOM 元素，插入恶意脚本。
这些攻击场景都可能导致严重的后果，如窃取用户信息，包括用户名、密码、信用卡信息等；破坏网站功能，如修改网站内容、删除数据；传播恶意软件，如病毒、木马等。
总之，XSS 跨站脚本攻击是一个严重的网络安全威胁，需要我们高度重视并采取有效的防范措施。

二、XSS 的类型及特点

（一）反射型 XSS

1. 特点是黑客需诱使用户点击恶意链接，常用于钓鱼网站获取用户重要信息。

反射型 XSS 攻击具有即时性和单次性的特点。攻击者精心构造含有恶意 JavaScript 脚本的链接，一旦用户点击该链接，服务器接收用户请求后，可能会将恶意脚本数据返回给用户浏览器。由于整个过程就像是一次 “客户端 — 服务器 — 客户端” 的反射过程，恶意脚本没有经过服务器的过滤或处理，就被反射回客户端直接执行并显示相应的结果。这种攻击方式通常依赖用户互动，只有在用户点击恶意链接时才会触发，且只执行一次。例如，攻击者可能会发送一封看似正常的电子邮件，其中包含一个诱人的链接，如 “点击查看最新优惠活动”，当用户点击这个链接后，就可能会触发反射型 XSS 攻击，导致用户的敏感信息被窃取。

2. 工作原理是利用网站漏洞，当用户点击恶意链接后，正常网站嵌入恶意脚本。

具体来说，攻击者首先构造含有恶意脚本的数据，这些数据可能通过 URL 参数、表单提交等方式传递到客户端。当用户的浏览器接收到这些数据后，服务器处理用户请求并进行响应，响应由浏览器解析后将 JavaScript 脚本的执行结果显示在页面中。如果网站存在漏洞，没有对用户输入的数据进行充分的过滤和验证，那么恶意脚本就会被嵌入到正常的网页中。比如，一个购物网站的搜索功能可能存在反射型 XSS 漏洞，攻击者构造一个恶意链接，其中包含恶意脚本作为搜索参数，当用户点击该链接进行搜索时，恶意脚本就会在页面中执行，可能会窃取用户的登录凭证或其他敏感信息。

（二）存储型 XSS

1. 黑客在博客等网站发表恶意代码内容，被保存后所有访问用户都会执行恶意代码。

存储型 XSS 攻击具有持久性和广泛性的特点。攻击者在发帖的过程中，将恶意脚本连同正常信息一起注入帖子的内容中，随着帖子被服务器存储下来，恶意脚本也永久地被存放在服务器的后端数据库中。当其他用户浏览这个被注入了恶意脚本的帖子时，恶意脚本会在他们的浏览器中得到触发。这种攻击方式常见于用户留言、评论、用户昵称、用户信息等位置。例如，在一个论坛上，攻击者发表一篇带有恶意脚本的帖子，所有浏览这篇帖子的用户都会受到攻击，无论何时何地，只要用户访问该帖子，恶意脚本就会被执行。

2. 危害较大，可窃取用户 cookie，甚至获取管理员权限登陆网站后台。

存储型 XSS 攻击的危害非常严重。一方面，攻击者可以在恶意脚本中编写代码，以获取用户的账号、密码、银行卡号等敏感信息。另一方面，攻击者可以通过恶意脚本代码窃取用户的会话信息，并以此来冒充用户进行非法操作。甚至，攻击者可以利用存储型 XSS 漏洞获取管理员权限，登陆网站后台，对网站进行破坏。据统计，大约有 [X]% 的网站安全事件是由存储型 XSS 攻击引起的。例如，攻击者在一个博客网站发表一篇带有恶意脚本的文章，当管理员浏览这篇文章时，恶意脚本可能会窃取管理员的 cookie，攻击者利用窃取到的 cookie 就可以冒充管理员登陆网站后台，进行恶意操作。

（三）DOM 型 XSS

1. 特殊类型的反射型 XSS，基于 DOM 文档对象模型的漏洞。

DOM 型 XSS 是一种特殊类型的反射型 XSS，它是基于 DOM 文档对象模型的一种漏洞。HTML 的标签都是节点，而这些节点组成了 DOM 的整体结构 —— 节点树。通过 HTML DOM，树中的所有结点均可通过 JavaScript 进行访问。所有 HTML 元素（节点）均可被修改，也可以创建或删除节点。这就为 DOM 型 XSS 攻击提供了可能。与传统的反射型 XSS 攻击不同，DOM 型 XSS 完全在客户端执行，不涉及服务器端的任何改变。攻击发生在客户端，通过 JavaScript 操作 DOM，直接在浏览器中注入恶意代码。

2. 特点是不需要服务器解析，触发靠浏览器端 DOM 解析。

DOM 型 XSS 攻击的特点是恶意代码通常不会经过服务器，而是通过客户端脚本处理数据时注入。攻击的触发依赖于浏览器环境，受到浏览器版本和插件等客户端环境的影响。例如，一个 Web 应用程序允许用户通过 URL 参数搜索内容，并且使用 JavaScript 来更新页面内容。如果攻击者将恶意脚本作为查询参数，当页面加载时，DOM 操作解析该参数并执行恶意脚本。这种攻击方式具有隐蔽性，因为服务器端的日志可能不会记录任何异常，这使得检测和追踪变得更加困难。

三、XSS 攻击的表现平台

（一）知乎平台

1. 老问题导致的 XSS 漏洞，利用 JavaScript: 伪协议执行 js 代码。

• • 在知乎中，如看到 https://link.zhihu.com/?target=http://www.baidu.com 这个链接的源码，将输入的信息传入 URI 参数，解码以后赋值与 location.href，明显可以利用 JavaScript: 伪协议执行 js 代码。例如，https://link.zhihu.com/?target=javascript:alert(1)，会弹出一个警告框，展示了 XSS 漏洞的存在形式。

2. 知乎的 CSRF 防御机制及 Tornado 对 Cookie 的处理特点。

• • 知乎检查 CSRF 漏洞的方式是为用户设置一个随机 Cookie 叫_xsrf，用户填写表单时，表单里会自动插入一个隐藏的项目也叫_xsrf。后端会将表单里的_xsrf 和 cookie 中所带的_xsrf 进行比对，若二者相同，则说明为合法表单。Tornado 中利用 python 自带的 Cookie 库处理 Cookie，解析 HEADER 中的 Cookie 后一个个赋值在 self 中，若存在同名 Cookie，后者将覆盖前者。

3. 覆盖_xsrf 进行刷粉的方法及 POC 代码。

• • 利用 link.zhihu.com 的 XSS 漏洞，设置 cookie: _xsrf=aaaaaa; domain=.zhihu.com，设置表单中的_xsrf=aaaaaa，POST 数据包关注目标用户，即可实现覆盖_xsrf 进行刷粉。POC 代码中，利用函数 love，通过设置 cookie 和表单中的_xsrf 值相等，实现特定操作。

（二）公众号平台

1. 文章标题未转义导致留言页面出现安全漏洞。

• • 在公众号中，发一篇文章标题中包含 <input onfocus="alert('1')">，用户打开文章后，在留言页面中标题未被转义被渲染成 HTML，用户点击被渲染出来的输入框后执行代码，这暴露了公众号在文本转义处理上的漏洞。

2. 存储型 XSS 攻击在公众号的表现及防范策略。

• • 在公众号中，存储型 XSS 攻击常见于发表文章或评论场景等保存用户编辑数据的地方。攻击者将恶意代码提交至服务器并保存在数据库中，用户访问该页面触发攻击行为。防范策略是不相信一切用户提交的信息，对评论、文章等进行字符串转义，在显示富文本场景下考虑采用白名单过滤办法。

（三）头条平台

1. 根据 HackerOne 数据，XSS 是 Web 应用最常见漏洞类型之一。

• • 据 HackerOne 数据显示，当前 Web 应用程序上最常见的漏洞类型是跨站点脚本 (XSS)。在 HackerOne 支付的 5500 万美元的漏洞赏金中，有 800 万美元用于发现公司 Web 应用程序中的 XSS 漏洞，这突显了 XSS 漏洞的普遍性。

2. CSRF 和 XSS 攻击在头条网络安全面试中的浅析。

• • 在头条网络安全面试中，浅析了 CSRF（Cross-site request forgery 跨站请求伪造）和 XSS（跨站脚本攻击）的原理、起源和防范。CSRF 是攻击者盗用用户身份以用户名义发送恶意请求，可能导致个人隐私泄露及财产安全等问题。XSS 则是恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览该页时，嵌入其中的 html 代码会被执行，从而达到恶意攻击用户的目的。

3. 利用网站漏洞搞网络攻击被网警抓的案例及对 “XSS” 的解释。

• • 虽然目前没有明确的头条平台上利用网站漏洞搞网络攻击被网警抓的案例，但可以明确的是，XSS 攻击是一种严重的网络安全问题。XSS 攻击即恶意攻击者往 Web 页面里插入恶意 html 代码，当用户浏览页面时，恶意代码被执行，可能导致用户信息被窃取、网站功能被破坏等后果。

四、XSS 的构造技巧与防御

（一）构造技巧

1. 利用字符编码，如 GBK/GB2312 编码可造成 XSS 攻击。

如果用户变量中有特殊字符，系统会用 “\” 进行转义。比如输入 “;alert (/XSS/), 会被系统转义成:var redirectUrl = ";alert (/XSS/);"，这样参数就是一个字符串。但如果页面是 GBK/GB2312 编码，“% c1\” 这两个字符组合在一起就是一个 Unicode 字符，所以如果传递 % c1”;alert (/XSS/), 那么转义后为：var redirectUrl = "% c1;alert (/XSS/)"，% c1 会将转义字符 “\” 给吃掉，从而造成 XSS 攻击。

2. 绕过长度限制，通过标签自带 onclick 事件或打通文本框输入恶意脚本。

一些网站可能会对有可能产生 XSS 的地方设置变量长度限制，但攻击者可以不插入 javascript 脚本，而是通过标签自带的 onclick 事件配合隐藏在 location.hash 的恶意脚本进行攻击。另一种方式则是通过注释带有长度限制的文本框，打通两个文本框来输入较长字数的 javascript 脚本。

3. 使用标签劫持当前页面相对路径标签。

<base>标签用于定义页面上所有使用相对路径标签的 hosting 地址。攻击者如果在页面插入<base>标签，就可以通过在远程服务器上伪造图片、链接或者脚本，劫持当前页面中所有使用相对路径的标签。

4. 利用 window.name 对象实现跨域跨页面传递数据。

对当前窗口的 window.name 对象赋值，没有特殊字符的限制，因为 window 对象是浏览器窗口，而并非 document 对象，因此很多时候 window 对象不受同源策略的限制，攻击者利用这个对象可以实现跨域，跨页面传递数据。

5. Anehta 的回旋镖思路，结合不同域的 XSS 进行攻击。

因为浏览器同源策略的原因，XSS 也受到同源策略的限制，发生在 A 域的 XSS 很难影响到 B 域的用户。回旋镖的思路就是：如果 B 域上存在一个反射型 XSS_B，A 域上有一个存储型 XSS_A，当用户访问 A 域上的 XSS_A 时，同时嵌入 B 域的 XSS_B，即浏览 A 网页时，触发 A 脚本，脚本会跳转到 B 网站触发 B 脚本，然后再跳回来，虽然说时间可能很短，但是地址栏可以明显感知到变化。

（二）防御方法

1. 利用 HttpOnly 属性，禁止 JavaScript 访问带有该属性的 cookie。

浏览器将禁止页面的 JavaScript 访问带有 HttpOnly 属性的 cookie，在 setcookie 的时候可以将 cookie 设置成 HttpOnly，设置后 JavaScript 就无法获取该数据。XSS 攻击自然无法奏效了。

2. 输入检查，使用 XSS Filter 但要注意语境理解问题。

XSS Filter 在用户提交数据时获取变量，并进行 XSS 检查；但此时用户数据没有结合渲染页面的 HTML 代码，可能对语境理解并不完整。比如<script src = "$var"></script>，用户只需提交一个恶意脚本的地址就可实施 XSS 攻击，但是 URL 在此处本来就是合法用户数据，所以无法判断有没有问题。如果输入 1+1<3，如果 XSS Filter 不够智能有可能将‘<’过滤掉，这样改变了用户原本的意思。输入的数据还可能展示在多个地方，每个地方的语境可能不同，使用单一替换操作，也有可能出现问题，比如用户输入 “我是‘天才’”，Filter 对其转义为 $name = ' 我是 \"天才 \"'，在 html 代码中展示为：<div>我是 \\\"天才 \\\"</div>，在 JavaScript 中能正常展示。

3. 输出检查，针对 HTML 和 JavaScript 采用不同编码或转义方式防御 XSS 攻击。

除了富文本的输出外，在变量输出到 HTML 界面时，可以使用编码或转义方式来防御 XSS 攻击。针对 HTML 代码的编码方式是 HtmlEncode，针对 JavaScript 的则是 JavaScriptEncode (后面简称 JE)。JE 需要使用 “\” 对特殊字符进行转义，在对抗 XSS 时，还要求输出的变量必须在引号内部。在正确的地方使用正确的编码方式，例如 onclick = "alert (' var = htmlencode ("');alert ('2")，那么预期是解决了 XSS 注入问题，但仍需谨慎处理各种复杂情况。
 

墨者安全 防护盾

墨者安全作为专业级别安全防护专家，在应对 Webshell 风险隐患方面展现出了卓越的能力。其拥有全面的检测机制，能够精准识别 Webshell 的各种类型和变体，无论是复杂的大马，还是隐蔽的内存马，都难逃其敏锐的监测。
墨者安全防护盾具备强大的实时监控功能，对服务器的各项活动进行 7*24 小时不间断的监视。一旦发现任何可疑的 Webshell 活动迹象，立即发出警报，并迅速采取隔离和清除措施，将风险扼杀在萌芽状态。
在防护策略上，墨者安全防护盾采用了多层次的防御体系。不仅能够在网络层面阻挡外部的恶意访问和攻击，还能深入系统内部，对服务器的文件系统、进程等进行深度检查和保护，确保 Webshell 无法植入和运行。
同时，墨者安全防护盾拥有快速的应急响应能力。当 Webshell 攻击事件发生时，专业的安全团队能够迅速介入，进行深入的分析和处理，最大程度减少攻击带来的损失，并帮助用户快速恢复服务器的正常运行。
墨者安全防护盾还注重用户教育和培训，为用户提供关于 Webshell 防范的专业知识和最佳实践，帮助用户提升自身的安全意识和防范能力，共同构建坚实的网络安全防线。