HackerNews中文版HackerNews CN
GitHubTwitter

关闭 –> 跟踪 –> 关闭：一家科技巨头是否因HTTP/2 200 OK绕过而感到恐慌？

1 分•作者: CorporationHit•3 个月前•原帖
[免责声明]：此内容仅供教育目的，并作为安全社区的案例研究。我旨在讨论安全响应系统的逻辑，而不是针对任何个人或专有数据。 案例： 我希望社区对一个技术分歧提供看法。当提供了手动绕过的证明，但响应逻辑仍然不一致时，责任在谁？ 时间线与逻辑差距： 报告：我报告了一个与支付相关的子域中的逻辑缺陷。该报告最初被审查并标记为“已分类”。 驳回：不久之后，报告被标记为“关闭（信息性）”。没有提供技术解释说明为何分类被撤回。 手动证明：我提供了一个使用 Admin-Token: true 头的手动绕过，结果得到了成功的 HTTP/2 200 OK 响应（在终端日志中验证）。 循环：在提供了这一证据后，报告经历了一个“已分类-已关闭”的循环。尽管有手动证明的 200 OK 状态，但该案例仍然关闭且没有补丁。 责任在哪里？ 是公司的错吗？因为驳回了手动证明的 200 OK 绕过，并依赖自动关闭逻辑而没有验证漏洞的影响。 是研究者的错吗？因为提供了与“信息性”状态相矛盾的证据，并期待对关闭的技术解释。 证据（截图）： 手动证明（HTTP/2 200 OK 绕过）：https://i.ibb.co/kgMjSBBK/Whats-App-Image-2026-02-13-at-1-40-12-PM.jpg 报告状态历史（循环）：https://i.ibb.co/5gsLnyJJ/Whats-App-Image-2026-02-13-at-1-43-58-PM.jpg 初始分类确认：https://i.ibb.co/K3ZCQ48/Whats-App-Image-2026-02-13-at-1-38-17-PM.jpg 48小时通知邮件：https://i.ibb.co/Df8GwCH0/Whats-App-Image-2026-02-13-at-1-54-37-PM.jpg 完整沟通记录：https://i.ibb.co/zTbNRFQy/Whats-App-Image-2026-02-13-at-1-38-27-PM.jpg 我对开发者和研究者的问题： 当研究者用 200 OK 响应证明了一个绕过，但公司仍将报告保持“关闭”状态时，这是一种行业标准做法，还是安全响应逻辑中的一个缺口？Google VRP
查看原文
[DISCLAIMER]: This is shared strictly for educational purposes and as a case study for the security community. My goal is to discuss the logic of security response systems, not to target any individual or proprietary data. The Case: I am seeking the community's perspective on a technical disagreement. Who is at fault when a manual proof of a bypass is provided, yet the response logic remains inconsistent? The Timeline & Logic Gap: The Report: I reported a logic flaw in a payments-related sub-domain. It was initially reviewed and marked as "Triaged". The Dismissal: Shortly after, the report was marked as "Closed (Informative)". No technical explanation was provided for why the triage was reversed. The Manual Proof: I provided a manual bypass using an Admin-Token: true header, which resulted in a successful HTTP/2 200 OK response (verified in terminal logs). The Loop: Following this evidence, the report went through a "Triaged-Closed" loop. Despite the manual proof of a 200 OK status, the case remains closed without a patch. Where is the Fault? Is it the Company's fault? For dismissing a manual proof of a 200 OK bypass and relying on automated closure logic instead of verifying the vulnerability's impact. Is it the Researcher's fault? For providing evidence that contradicts the "Informative" status and expecting a technical justification for the closure. The Evidence (Screenshots): Manual Proof (HTTP/2 200 OK Bypass): https://i.ibb.co/kgMjSBBK/Whats-App-Image-2026-02-13-at-1-40-12-PM.jpg Report Status History (The Loop): https://i.ibb.co/5gsLnyJJ/Whats-App-Image-2026-02-13-at-1-43-58-PM.jpg Initial Triage Confirmation: https://i.ibb.co/K3ZCQ48/Whats-App-Image-2026-02-13-at-1-38-17-PM.jpg 48-Hour Notice Email: https://i.ibb.co/Df8GwCH0/Whats-App-Image-2026-02-13-at-1-54-37-PM.jpg Full Communication Logs: https://i.ibb.co/zTbNRFQy/Whats-App-Image-2026-02-13-at-1-38-27-PM.jpg My Question to Developers & Researchers: When a researcher proves a bypass with a 200 OK response, but the company keeps the report "Closed," is this a standard industry practice or a gap in the security response logic? Google VRP