XSS

slug
series-status
status
summary
date
series
type
password
icon
tags
category

XSS

成因

New Bing

XSS漏洞的成因主要是Web应用程序对用户的输入过滤不足，导致恶意的脚本代码注入到网页之中，当其他用户浏览这些网页时，就会执行其中的恶意代码。
具体来说，XSS漏洞的成因可以分为以下几种情况：
  • 存储型XSS漏洞：恶意代码会被保存在服务器中，导致其它用户（前端）和管理员（前后端）在访问资源时执行了恶意代码​1。这种情况一般是由于服务器端对用户输入的数据没有进行有效的过滤或转义2。
  • 反射型XSS漏洞：恶意代码存在于URL中，当用户点击该链接时，服务器接受该目标用户的请求并进行处理，然后服务器把带有XSS的代码发送给目标用户的浏览器，浏览器解析这段带有XSS代码的恶意脚本后，就会触发XSS漏洞​2。这种情况一般是由于服务器端对用户输入的参数没有进行有效的过滤或转义3。
  • DOM型XSS漏洞：恶意代码存在于客户端脚本中，当用户访问某个页面时，客户端脚本会根据用户输入或其他事件动态修改页面结构或内容，从而导致恶意代码被执行​3。这种情况一般是由于客户端脚本对用户输入或其他来源的数据没有进行有效的过滤或转义4。
  • UXSS漏洞：恶意代码利用浏览器或者浏览器扩展存在的漏洞来制造产生XSS的条件并执行代码​5。这种情况一般是由于浏览器或者浏览器扩展对网页内容或请求没有进行有效的安全检查5。

ChatGPT-4

跨站脚本攻击（XSS, Cross-Site Scripting）是一种常见的网络安全漏洞。它允许攻击者将恶意代码注入到用户浏览的网页中，从而在用户的浏览器上执行。XSS漏洞的成因可以归结为以下几个主要原因：
  1. 输入验证不足：许多Web应用程序在接收用户输入时未进行充分的验证。恶意用户可以利用这种不足，向Web应用程序提供包含恶意脚本的输入，从而导致XSS漏洞。
  1. 输出编码不当：在将用户输入数据呈现给其他用户之前，如果没有对数据进行正确的编码或转义，那么包含恶意脚本的数据可能会在其他用户的浏览器上执行。
  1. 不安全的第三方组件：Web应用程序可能会使用第三方组件，如库、插件或框架。如果这些组件存在安全漏洞，它们可能会被攻击者利用，导致XSS漏洞。
  1. 不安全的设计和配置：Web应用程序的设计和配置错误可能会导致XSS漏洞。例如，允许用户提交HTML代码，或者配置服务器以允许跨域资源共享（CORS）等。
  1. 不正确的内容安全策略（CSP）：CSP是一种安全机制，旨在减轻XSS等攻击的风险。然而，如果CSP设置不正确或过于宽松，攻击者可能仍能利用XSS漏洞。
XSS漏洞主要分为三种类型：存储型XSS、反射型XSS和DOM型XSS。它们各自的成因如下：
  1. 存储型XSS（Stored XSS）：
存储型XSS漏洞是由于Web应用程序接收并存储了包含恶意脚本的用户输入，而在将该数据呈现给其他用户时，未进行正确的编码或转义。当其他用户浏览包含恶意脚本的页面时，脚本将在其浏览器上执行。存储型XSS的成因主要包括：
  • 不足的输入验证：Web应用程序未对用户提交的数据进行严格的验证。
  • 不恰当的输出编码：在将存储的数据输出到页面时，没有进行适当的编码或转义。
  1. 反射型XSS（Reflected XSS）：
反射型XSS漏洞发生在Web应用程序将用户提交的恶意脚本直接插入到响应页面中，而未进行正确的编码或转义。通常，攻击者会通过URL参数或表单数据将恶意脚本发送给服务器。反射型XSS的成因包括：
  • 不足的输入验证：Web应用程序未对用户提交的URL参数或表单数据进行严格的验证。
  • 不恰当的输出编码：在将用户提交的数据插入到响应页面时，没有进行适当的编码或转义。
  1. DOM型XSS（DOM-based XSS）：
DOM型XSS漏洞是由于Web应用程序在客户端（浏览器）对用户输入的处理不当。在这种情况下，恶意脚本并不是直接从服务器发送给浏览器的，而是通过浏览器端的脚本（如JavaScript）操作DOM来插入恶意代码。DOM型XSS的成因包括：
  • 客户端脚本不足的输入验证：浏览器端脚本未对用户提交的数据进行严格的验证。
  • 不安全的客户端脚本操作：使用了不安全的DOM API，如innerHTML​​、document.write​​等，而没有进行适当的编码或转义。
针对这些成因，可以采取一定的安全措施来降低XSS漏洞的风险，如进行严格的输入验证、输出编码、使用安全的客户端脚本操作以及实施内容安全策略（CSP）等。

常见漏洞点

New Bing

比较容易出现XSS漏洞的场景有以下几种：
  • 网页中直接输出用户输入的内容，没有进行任何过滤或转义​6。例如，一个留言板网站允许用户在表单中输入自己的昵称和留言内容，然后直接将这些内容显示在网页上。如果攻击者在昵称或留言内容中插入了恶意代码，那么其他访问该网页的用户就会执行这些代码。
  • 网页中使用了不安全的HTML属性或标签来输出用户输入的内容​2。例如，一个搜索引擎网站允许用户在表单中输入关键词，然后将关键词作为一个链接显示在网页上。如果攻击者在关键词中插入了恶意代码，并利用了HTML属性如href、src、onmouseover等来触发这些代码，那么其他点击该链接或鼠标移动到该链接上的用户就会执行这些代码。
  • 网页中使用了不安全的JavaScript函数或方法来处理用户输入的内容​2。例如，一个社交网络网站允许用户在表单中输入自己的个人简介，并使用eval()函数来解析并显示这些内容。如果攻击者在个人简介中插入了恶意代码，并利用了JavaScript语法如分号、括号等来绕过eval()函数的限制，那么其他查看该个人简介的用户就会执行这些代码。
  • 网页中使用了不安全的DOM操作来处理用户输入的内容​1。例如，一个网站允许用户在表单中输入自己的姓名，并使用document.write()函数来显示这些内容。如果攻击者在姓名中插入了恶意代码，并利用了JavaScript语法如分号、括号等来绕过document.write()函数的限制，那么其他查看该姓名的用户就会执行这些代码。
  • 网页中使用了不安全的HTML标签或属性来输出用户输入的内容​2。例如，一个网站允许用户在表单中输入自己的个人主页地址，并使用iframe标签或srcdoc属性来显示这些内容。如果攻击者在个人主页地址中插入了恶意代码，并利用了HTML语法如双引号、单引号等来绕过iframe标签或srcdoc属性的限制，那么其他查看该个人主页的用户就会执行这些代码。
  • 网页中使用了不安全的JavaScript注释来处理用户输入的内容​3。例如，一个网站允许用户在表单中输入自己喜欢的电影，并使用//符号来注释掉这些内容。如果攻击者在电影名中插入了恶意代码，并利用了JavaScript语法如换行符、分号等来终止注释符号，那么其他查看该电影名的用户就会执行这些代码。

ChatGPT-4

以下是一些容易出现XSS漏洞的场景和原因：
  1. 评论和留言功能：网站和应用程序的评论和留言功能通常允许用户输入文本。如果开发人员未对这些输入进行严格的验证和编码，攻击者可以在评论或留言中插入恶意脚本，导致其他用户在浏览这些内容时遭受攻击。
  1. 搜索框：许多Web应用程序提供搜索功能，允许用户输入关键字进行搜索。如果开发人员未对搜索关键字进行适当的验证和编码，攻击者可以通过在搜索框中输入包含恶意脚本的关键字来发起XSS攻击。
  1. 用户个人信息：用户个人信息页面（如个人资料、昵称、签名等）可能会显示用户输入的数据。如果未对这些数据进行适当的验证和编码，攻击者可以在个人信息中插入恶意脚本，导致其他访问该页面的用户受到攻击。
  1. URL参数：许多Web应用程序使用URL参数来传递数据。攻击者可以通过修改URL参数中的值，并将包含恶意脚本的URL发送给受害者。当受害者点击这个URL时，恶意脚本将在其浏览器上执行。
  1. 错误信息页面：当Web应用程序发生错误时，可能会显示错误信息页面。如果开发人员未对错误信息进行适当的编码，攻击者可以利用这一点，将包含恶意脚本的错误信息发送给受害者。
  1. 社交分享功能：许多网站提供社交分享功能，允许用户将内容分享到社交平台。如果分享功能未对分享的内容进行适当的验证和编码，攻击者可以通过分享包含恶意脚本的内容来发起XSS攻击。
  1. 富文本编辑器：许多Web应用程序使用富文本编辑器来实现富文本输入功能。如果富文本编辑器未对用户输入的数据进行严格的验证和清理，攻击者可以在富文本中插入恶意脚本。
这些场景中，XSS漏洞的主要原因在于开发人员未对用户输入进行严格的验证、过滤和编码。为了降低这些场景中出现XSS漏洞的风险，应采取一定的安全措施，如进行严格的输入验证、输出编码、过滤非法字符和实施内容安全策略（CSP）等。
除了上述提到的场景之外，还有其他容易出现XSS漏洞的场景：
  1. 用户上传的文件：如果Web应用程序允许用户上传文件，且未对文件内容进行适当的验证，攻击者可以上传包含恶意脚本的文件。当其他用户查看或下载这些文件时，恶意脚本可能会在其浏览器上执行。
  1. 第三方广告和插件：许多网站会嵌入第三方广告和插件。如果这些广告和插件存在XSS漏洞，攻击者可以利用这些漏洞来发起攻击。为了降低风险，应尽量使用可信赖的广告和插件来源。
  1. 论坛和博客文章：类似于评论和留言功能，论坛和博客文章也可能显示用户输入的数据。如果开发人员未对这些数据进行适当的验证和编码，攻击者可以在文章内容中插入恶意脚本。
  1. 私信和聊天功能：许多Web应用程序提供私信和聊天功能。如果开发人员未对用户输入的文本进行适当的验证和编码，攻击者可以通过发送包含恶意脚本的消息来发起XSS攻击。
  1. Web应用程序中的AJAX请求：Web应用程序可能使用AJAX请求从服务器获取数据。如果开发人员未对请求的数据进行适当的验证和编码，攻击者可以利用这一点，通过修改请求的参数来插入恶意脚本。
总之，任何处理用户输入数据的场景都有可能出现XSS漏洞。为了防范XSS漏洞，开发人员需要在处理用户输入数据时采取一系列安全措施，如实施严格的输入验证、输出编码、过滤非法字符以及实施内容安全策略（CSP）。同时，使用可信赖的第三方组件和插件，以降低由不安全的组件导致的XSS漏洞风险。

修复方案

New Bing

针对XSS漏洞，有一些常用的修复方案，主要是对用户输入的内容进行安全过滤和转义，避免输出到页面上的内容包含恶意代码。具体的方法有以下几种：
  • 使用PHP的htmlentities()或htmlspecialchars()函数，Python的cgi.escape()函数等，对用户输入的内容进行HTML实体编码​1。这样可以防止用户输入的内容被当作HTML标签或属性解析。
  • 使用JavaScript的encodeURI()或encodeURIComponent()函数，对用户输入的内容进行URL编码​2。这样可以防止用户输入的内容被当作JavaScript代码执行。
  • 使用白名单过滤法，只允许用户输入一些安全的字符或标签​2。这样可以防止用户输入一些危险的字符或标签，如<、>、"、'等。
  • 使用正则表达式或其他方法，对用户输入的内容进行特殊字符替换​3。这样可以防止用户输入的内容中包含一些攻击特征，如分号、括号等。
  • 对HTTP响应头进1行加固，启用浏览器的XSS filter​1。这样可以防止浏览器执行一些不安全的脚本。
  • 对Cookie设置HttpOnly​1，防止XSS偷取Cookie2。这样可以保护用户的身份和隐私。
  • 使用ESAPI​1等安全库，对用户输入参数进行编码3。这样可以避免用户输入参数中包含一些特殊符号或关键字。
  • 根据业务逻辑限定参数的范围和类型，进行白名单判断​1。这样可以避免用户输入一些无关或恶意的参数。

ChatGPT-4

针对XSS漏洞，以下是一些常用的修复方案：
  1. 输入验证：对用户输入的数据进行严格的验证，以确保数据符合预期的格式和内容。可以使用正则表达式、白名单等方法进行验证。需要注意的是，输入验证不能完全防止XSS攻击，因为攻击者可能会利用各种编码和转义方式绕过验证。
  1. 输出编码：在将用户输入的数据输出到页面时，对数据进行适当的编码或转义。针对HTML、属性、URL、JavaScript等不同的上下文，采用相应的编码方法。例如，对HTML内容进行HTML实体编码，对JavaScript中的数据进行JavaScript编码等。
  1. 过滤非法字符：在处理用户输入数据时，过滤或替换可能导致XSS漏洞的非法字符。例如，过滤或替换尖括号（<和>）、单双引号（'和"）等。
  1. 特殊字符转译（对2的补充） ：对特殊字符进行转义（或编码）是指将具有特殊含义的字符（如HTML标签、JavaScript代码中的字符等）替换为相应的实体编码，以防止浏览器将它们解释为可执行的代码。例如，在HTML中，“<”和“>”分别可以转义为&lt​和&gt​。通过对用户输入的数据进行适当的转义，可以确保这些数据在插入到HTML、JavaScript或其他上下文中时不会被误解释为可执行代码，从而降低XSS攻击的风险。** **需要注意的是，仅仅对特殊字符进行转义并不能完全防止XSS漏洞。在实际开发中，防范XSS攻击需要综合运用多种安全措施，包括输入验证、输出编码、使用安全的编程模式和框架等。请根据您的应用程序的具体需求和场景选择合适的方法，并持续关注Web安全领域的最新发展和最佳实践。
  1. 安全的客户端脚本操作：使用安全的DOM API和方法，避免使用易受攻击的方法，如innerHTML​、document.write​等。改用textContent​、innerText​或安全的模板引擎等替代方案。
  1. 内容安全策略（CSP） ：实施内容安全策略，限制浏览器加载和执行来自非可信来源的脚本。CSP可以通过HTTP响应头或<meta>​标签实现。设置合适的CSP策略，如限制外部脚本来源、禁用内联脚本等，有助于降低XSS攻击的风险。
  1. 使用安全的HTTPOnly Cookie：为敏感Cookie设置HTTPOnly标志，使得JavaScript无法访问这些Cookie。这样，即使XSS攻击发生，攻击者也无法通过脚本获取敏感的Cookie信息。
  1. 审查第三方组件和插件：使用可信赖的第三方组件和插件，并定期对其进行安全审查。确保组件和插件的版本是最新的，并及时修复已知的安全漏洞。
  1. 安全编程实践：遵循安全编程实践，培训开发人员了解XSS漏洞的原理和防范方法。进行代码审查，以确保代码中不存在潜在的XSS漏洞。
  1. 使用Web应用程序防火墙（WAF） ：WAF可以帮助检测和阻止潜在的XSS攻击。虽然WAF不能完全替代安全编程实践，但它可以作为防范XSS攻击的一个辅助手段。
  1. 实施安全的文件上传策略：对用户上传的文件进行严格的验证，确保文件类型、内容和大小符合预期。限制可执行文件的上传，以减少由恶意文件引起的XSS风险。
  1. 限制用户可输入的字符集：在某些场景下，限制用户可输入的字符集可能有助于防止XSS攻击。例如，如果一个字段仅需要纯数字，那么限制输入的字符集为数字字符可以降低XSS风险。
  1. 避免使用不安全的编程模式：某些编程模式可能导致XSS漏洞。例如，PHP中的“register_globals”功能可能导致不安全的变量使用，从而引发XSS问题。在编程时，避免使用这些不安全的模式有助于降低XSS风险。
  1. 对敏感操作实施双重验证：对于可能受到XSS攻击影响的敏感操作，实施双重验证（如验证码、短信验证等），可以在一定程度上防止攻击者利用XSS漏洞实施恶意操作。
  1. 使用安全框架和库：使用一些安全性较高的框架和库，如React、Angular、Vue等，它们内置了一些防范XSS攻击的措施。在开发过程中，利用这些框架和库的安全特性，遵循官方推荐的安全实践。
  1. 定期进行安全审计：定期对Web应用程序进行安全审计和渗透测试，以发现和修复潜在的XSS漏洞。采用自动化安全扫描工具和人工审查相结合的方式，确保应用程序的安全性。
  1. 使用安全的开发生命周期：将安全作为软件开发生命周期的一部分，确保从需求分析、设计、编码到测试和部署阶段都考虑安全因素。这有助于提高整个应用程序的安全性，包括防范XSS漏洞。
  1. 启用X-Content-Type-Options响应头：在服务器响应头中启用X-Content-Type-Options，设置其值为“nosniff”。这样可以防止浏览器将响应内容解释为不同的MIME类型，从而降低XSS攻击的风险。
  1. 使用安全的跨域策略：对于需要跨域资源共享（CORS）的Web应用程序，设置合适的CORS策略以限制允许访问资源的域。过于宽松的跨域策略可能导致XSS攻击。
  1. 及时修补漏洞：关注业界关于XSS漏洞的信息披露，并针对已知的漏洞及时进行修补。这包括更新和修复应用程序所使用的第三方库、插件和框架。
  1. 使用Feature-Policy响应头：Feature-Policy允许您控制哪些浏览器功能和API可以在您的Web应用程序中使用。通过设置合适的Feature-Policy，可以限制某些可能导致XSS漏洞的功能，如内联脚本执行等。
  1. 使用安全的URL设计：避免在URL中传递敏感信息，如会话ID、令牌等。攻击者可能会利用XSS漏洞获取URL中的敏感信息。同时，确保Web应用程序中的URL参数在使用前经过严格验证和编码。
  1. 避免在页面中使用可执行的数据格式：例如，避免在页面中使用JSONP，因为它可能导致XSS攻击。使用更安全的数据格式，如JSON，并确保对数据进行正确的编码和处理。
  1. 使用最新的浏览器安全特性：现代浏览器包含了许多用于防范XSS攻击的安全特性。确保您的Web应用程序兼容并使用这些特性，如CSP、X-Content-Type-Options、Feature-Policy等。鼓励用户使用最新的浏览器，以便受益于这些安全特性。
请注意，防范XSS攻击需要多层次的安全措施，而不是依赖单一的解决方案。在实际开发中，需要根据具体场景选择合适的修复方案。

补充

  1. 针对特殊字符进行转译为什么不能完全避免XSS漏洞的产生？
虽然对特殊字符进行转义是防止XSS漏洞的一种有效方法，但它并不能完全避免XSS漏洞的产生，原因如下：
  1. 转义上下文的差异：在不同的上下文中，需要转义的特殊字符可能有所不同。例如，HTML中的特殊字符转义与JavaScript中的转义方法有所区别。如果在错误的上下文中进行转义，可能导致不完全的转义，从而产生XSS漏洞。
  1. 编码和解码不一致：在多层嵌套的数据传输过程中，可能会出现编码和解码不一致的情况。攻击者可能利用这种不一致性绕过转义限制，构造出有效的XSS攻击载荷。
  1. 可绕过的转义机制：在某些情况下，攻击者可能找到一种方法来绕过转义机制。例如，攻击者可能利用浏览器对特殊字符编码的容错性，构造出一种特殊的编码形式，使浏览器仍然将其解释为可执行代码。
  1. 未转义的字符：在某些场景下，开发者可能遗漏对某些特殊字符的转义，导致XSS漏洞的产生。
  1. 第三方库和插件的安全性：Web应用程序可能依赖许多第三方库和插件。这些库和插件中的安全漏洞（包括XSS漏洞）可能导致整个Web应用程序的安全性降低，即使对特殊字符进行了转义。
因此，虽然对特殊字符进行转义是防止XSS漏洞的关键措施之一，但在实际开发中，还需要采用多种安全措施来确保应用程序的安全性。这些措施包括输入验证、使用安全的编程模式和框架、采用内容安全策略（CSP）等。请根据您的应用程序的具体需求和场景选择合适的方法，并持续关注Web安全领域的最新发展和最佳实践。
接下来，我将对以上几种情况出现的原因分别进行详细的介绍：
  • 转译上下文的差异
当我们提到“转义上下文的差异”时，是指在不同的编程语言或数据格式中，需要转义的特殊字符及其转义方法可能会有所不同。如果在错误的上下文中进行转义，可能会导致不完全或错误的转义，从而使得转义对XSS漏洞的防御能力失效。
举个例子来说明这个问题。假设您在Web应用程序中使用了HTML和JavaScript。在HTML中，需要转义的特殊字符包括​<​、>​、&​、"​和'​，它们分别对应的转义字符为&lt​、&gt​、&amp​、&quot​和&apos​。而在JavaScript中，需要转义的特殊字符包括\\​、'​、"​和换行符（\\n​）等。在这种情况下，如果我们仅将HTML上下文中的转义方法应用于JavaScript代码中的字符串，就可能导致错误的转义，从而产生XSS漏洞。
例如，以下代码片段在HTML上下文中对用户输入进行了转义，但在JavaScript上下文中没有进行适当的转义：
在这种情况下，如果用户输入包含JavaScript中的特殊字符（如换行符或反斜杠），这些字符将不会被正确转义，从而可能导致XSS漏洞。
因此，在进行特殊字符转义时，需要根据不同的上下文选择合适的转义方法。同时，还需要采用其他安全措施（如输入验证、内容安全策略等）来进一步加强对XSS漏洞的防御。
以下是一个具体的例子，说明如何在错误的上下文中进行转义可能导致XSS漏洞。
假设有一个Web应用程序，允许用户输入评论并在页面上显示：
在这个示例中，当页面加载时，我们插入一个包含​onclick​事件处理程序的<button>​。用户的设置值（在这个例子中，我们使用了一个恶意的字符串）被转义并包含在事件处理程序中。然而，在这种情况下，我们需要在JavaScript上下文中进行转义，而不是HTML上下文。因为我们使用了错误的转义方法，所以当用户点击按钮时，浏览器会弹出一个警告框，显示“XSS”。
请尝试在浏览器中运行此示例并点击按钮。您应该能看到弹出的警告框。请注意，这个示例仅用于演示目的。在实际项目中，请使用成熟的库或框架来处理转义，以确保安全。
为了解决这个问题，我们应该使用适合JavaScript上下文的转义方法，例如：
然后，将escapeHTML​​替换为escapeJavaScript​​，以确保在JavaScript上下文中对用户昵称进行正确的转义。
  • 编码和解码不一致
  • 可绕过的转义机制
  • 未转义的字符
  • 第三方库和插件的安全性
  1. 为什么会存在PDF文件上传导致的XSS漏洞？
  1. 还有什么类似PDF文件上传导致XSS漏洞类似的导致XSS漏洞的情况么？
  1. 有哪些安全的客户端脚本操作可以避免XSS漏洞的产生？
  1. 内容安全策略（CSP）是什么？
  1. 使用HTTP-Only一定可以避免XSS漏洞获取cookie信息么？
您好，这是Bing。根据网上的信息，如果您对这个cookie设置了http-only，那么攻击者一般没有办法通过XSS漏洞获取这个cookie，因为http-only属性可以禁止javascript读取cookie​1​2。但是，有些情况下，攻击者可能还是能够绕过http-only属性获取cookie，例如利用一些服务器端的漏洞1​3，或者利用一些客户端的API3​4。因此，设置http-only属性并不能完全保证cookie的安全性，还需要结合其他的防御措施。
结论：是的，但是http-only只能防止XSS漏洞盗取cookie，不能防止XSS漏洞的产生，XSS的危害远不止获取cookie这么简单
  1. X-Content-Type-Options响应头为什么可以避免XSS漏洞？
  1. Feature-Policy响应头为什么可以避免XSS漏洞？
  1. 可执行的数据格式有哪些，为什么他们是“可执行的”？
  1. 使用最新的浏览器安全特性会不会导致兼容性问题，如果会应该怎么平衡二者？

xss 常见绕过

编码绕过

浏览器对 XSS 代码的解析顺序为：HTML解码 —— URL解码 —— JS解码(只支持UNICODE)。

0x01. html 实体编码

当可控点为单个标签属性时，可以使用 html 实体编码。
Payload
十进制
十六进制
可以不带分号
可以填充0

0x02. url 编码

当注入点存在 href 或者 src 属性时，可以使用 url 编码。
Payload
注：url 解析过程中，不能对协议类型进行任何的编码操作，所以 javascript: 协议头需要保留。
可以二次编码

0x03. js 编码

解析的时候字符或者字符串仅会被解码为字符串文本或者标识符名称，例如 js 解析器工作的时候将\\u0061\\u006c\\u0065\\u0072\\u0074​​进行解码后为alert​​，而alert​​是一个有效的标识符名称，它是能被正常解析的。但是像圆括号、双引号、单引号等等这些字符就只能被当作普通的文本，从而导致无法执行。
由于 js 是最后进行解析的，所以如果混合编码，需要先使用 js 编码再进行 url 编码或者 html 实体编码。
js 编码策略：
  1. " " 加上三个八进制数字，如果个数不够，前面补0，例如 "<" 编码为 "\074"
  1. "\x" 加上两个十六进制数字，如果个数不够，前面补0，例如 "<" 编码为 "\x3c"
  1. "\u" 加上四个十六进制数字，如果个数不够，前面补0，例如 "<" 编码为 "\u003c"
  1. 对于一些控制字符，使用特殊的 C 类型的转义风格（例如 \n 和 \r）
Payload
Unicode 编码
注：
Unicode 编码时，只能对有效的标识符进行编码，否则非标识符解码后不能解析执行。例如 javascript:alert(1) ，进行 Unicode 编码时，只能对 alert 和 "1" 进行编码，框号编码后会被当成文本字符，不能执行。ascii 八进制和十六进制编码使用时需要 eval、setTimeout等函数传递变量，并且可以对整个传递参数进行编码。例如 eval("alert(1)")，可以对 "alert(1)" 整个进行八进制、十六进制或者 Unicode 编码(双引号不参与)。
八进制和十六进制
setTimeout() 是属于 window 的方法，该方法用于在指定的毫秒数后调用函数或计算表达式。
语法：setTimeout(要执行的代码, 等待的毫秒数)​​

0x04. 混合编码

Payload
html 编码
Unicode 编码
注：Unicode 编码不能对括号使用
url 编码
由于浏览器对 xss 代码的解析过程是：html解析 —— url解析 —— js解析，所以可以编码方式进行组合绕过。
注：href、src等加载url的属性可以使用三种混合编码，on事件可以使用html实体编码和js编码混合，但url编码在on事件中不会解析。

0x05. base64 编码

base64 编码通常需要使用到 data 伪协议。
data 协议使用方法：data:资源类型;编码,内容​​
base64编码内容为
通常与 base64 编码配合 data 协议的标签有 <object>、<a>、<iframe>​
atob 函数
atob() 方法用于解码使用 base-64 编码的字符串。
  • *语法：**​window.atob(encodedStr)​(encodedStr: 必需，是一个通过 btoa() 方法编码的字符串)

0x06. ascii 编码

ascii 编码一般配合​String.fromCharCode​使用。
十进制
十六进制

空格过滤绕过

A位置可填充 /，/123/，%09，%0A，%0C，%0D，%20 B位置可填充 %09，%0A，%0C，%0D，%20 C位置可填充 %0B，/**/，如果加了双引号，则可以填充 %09，%0A，%0C，%0D，%20 D位置可填充 %09，%0A，%0C，%0D，%20，//，>

圆括号过滤绕过

0x01. 反引号替换

0x02. throw 绕过

单引号过滤绕过

0x01. 斜杠替换

0x02. 反引号替换

alert 过滤绕过

0x01. prompt 替换

0x02. confirm 替换

0x03. console.log 替换

0x04. document.write 替换

0x05. base64 绕过

关键词置空绕过

0x01. 大小写绕过

可以转换为

0x02. 嵌套绕过

嵌套<script>和</script>突破
可以转换为

函数拼接

0x01. eval

0x02. top

0x03. window

0x04. self

0x05. parent

0x06. frames

0x07. 常用函数

赋值拼接

火狐IE专属

拆分法

当 Web 应用程序对目标用户的输入长度进行了限制时，这时无法注入较长的xss攻击向量，但是特定情况下，这种限制可以通过拆分法注入的方式进行绕过。
通过上面的拆分法可以拼凑出下面完整的攻击向量：
Loading...
尚未开始
更新中
近期核心
已完结
已弃更

© River 2021-2026