从表面上看，由于它采用编码字符并由页面代码处理，因此被归类为 XSS 漏洞。这并不意味着它是您网站的 XSS 漏洞，但它是可疑的。

至于确定是否存在风险的过程，您需要进行一些模糊测试以查看您的站点如何响应。XSS 模糊测试选项随处可见。

就其本身而言，仅在 URL 中%32%35解码25既不是错误也不是漏洞的迹象。事实上，这就是RFC 3986 第 2.3 节所说的应该发生的事情（强调我的）：

2.3. 无保留字符

URI 中允许但没有保留用途的字符称为未保留字符。这些包括大写和小写字母、十进制数字、连字符、句点、下划线和波浪号。

unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

在用相应的百分比编码的 US-ASCII 八位字节替换未保留字符方面不同的 URI 是等效的：它们标识相同的资源。然而，URI 比较实现并不总是在比较之前执行规范化（参见第 6 节）。为了保持一致性，在 ALPHA（%41-%5A 和 %61-%7A）、DIGIT (%30-%39)、连字符 (%2D)、句点 (%2E)、下划线 (% 5F) 或波浪号 (%7E) 不应由 URI 生产者创建，并且当在 URI 中找到时，应由 URI 规范器将其解码为相应的未保留字符。

事实上，很有可能根本不是您的应用程序在解码这些字符，而是您的网络服务器，它会在将接收到的 URL 传递给您的应用程序之前尝试对其进行规范化。

要判断您的应用程序（或网络服务器）是否解码过多，您应该使用实际上不应该根据标准解码的字符进行测试，这可能会对 URL 或 HTML 的解析产生实际影响它嵌入其中。此类字符的示例包括：

• 一般的 URL 分隔符（gen-delims在 RFC 3986，第 2.2 节中），尤其是字符?( %3F) 和#( %23) — 这些不应在 URL 的路径部分中以未转义的形式出现。

• URL 中根本不允许使用的字符，例如换行符 ( %0A)、空格 ( %20)、"( %22)、<( %3C)、>( %3E)、\( %5C)、^( %5E)、`( %60)、{( %7B)、|( %7C) 和}( %7D)。

• HTML 元字符，例如&( %26)、'( %27)、"( %22)、<( %3C) 和>( %3E) — 对这些元字符进行不当解码（并且没有被相应的 HTML 字符实体替换）可能会破坏 HTML 标记并可能造成 HTML 注入/XSS 漏洞。

  请注意，其中几个（"和<）>在上面的禁止 URL 字符列表中，因此应始终采用百分比编码；其他 (&和') 可能并且在某些情况下必须出现在没有百分比编码的 URL 中，但在这种情况下，它们（尤其是&）必须被编码为相应的 HTML 字符实体（例如&for &）。

• 编码为的文字%符号%25永远不应在 URL 中解码为其文字形式；如果是，它会使 URL 无效，或者更糟的是，形成一个有效但意外的百分比转义序列，其后有字符。虽然这不太可能允许直接 XSS 攻击，但它肯定是一个错误，并且可能通过允许恶意输入通过验证来打开其他漏洞。

特别是，您观察到%22被 HTML 实体替换的测试"表明 a) 存在一些不适当的解码（或不充分的重新编码），但是 b) 虽然严格来说是无效的，但 URL正在正确地进行 HTML 转义，这应该可以防止它以允许 XSS 攻击的方式破坏 HTML 标记。