好的，我现在需要帮用户总结一篇文章的内容，控制在100字以内。用户的要求很明确，不需要以“文章内容总结”或“这篇文章”这样的开头，直接写描述即可。 首先，我得通读整篇文章，理解其主要内容。文章讲述的是作者在四天内测试一个网站时发现的漏洞。测试包括XSS、SQL注入、扫描、原型污染等常规测试以及暴力破解实验。作者观察到网站有时非常慢甚至无响应，而其他时候则运行正常。 在慢的时候，作者进行了暴力破解测试，发现即使密码错误，也会返回200状态码和有效令牌。这表明存在某种漏洞。经过分析，发现这是一个TOCTOU（时间顺序条件竞争）问题。具体来说，验证登录是否允许的函数和颁发令牌的部分没有同步。当验证函数较慢时，多个请求可以绕过检查，在系统更新状态之前生成令牌。 接下来，我需要将这些关键点浓缩到100字以内。重点包括：四天测试、网站异常行为（快慢交替）、暴力破解发现多个错误密码有效、原因分析为TOCTOU漏洞导致同步问题。 现在开始组织语言：描述测试过程、异常现象、暴力破解结果、漏洞原因和影响。确保语言简洁明了，不超过字数限制。 最后检查是否符合用户的所有要求：中文总结、控制字数、直接描述内容。 </think> 作者在四天内对网站进行安全测试时发现异常行为：网站有时快速响应，有时严重滞后。在滞后期间进行暴力破解测试时，发现多个错误密码返回有效令牌。原因是TOCTOU漏洞导致身份验证检查与令牌颁发不同步，在高负载下多个请求绕过验证并生成令牌。 2025-11-9 09:20:19 Author: infosecwriteups.com(查看原文) 阅读量:26 收藏
Finding
I spent four days for just hoping i got the vulnerability, i test the site with regular testing(like xss, sqli, scanning, prototype pollution, etc.) and brute force experiments.
During four days of testing I observed anomalous behavior, the website was extremely slow and unresponsive at certain times, and the other times it was perfectly fast.
Seeing those two behaviours, I ran login brute force tests during the slow periods and again during the fast periods.
- At normal times everything behaved, wrong passwords got 401s, right password got 200 and a token
- But at certain times of day the site would crawl. Not “a little slow” full-on lag when doing login or register.
and then i figured it was the server being overloaded.
So I tried brute force again during both the fast windows and the slow windows.
- During fast windows it was boring and expected: everything rejected except the correct password.
- During slow windows something weird happened. I found five different passwords that all returned 200 and gave me valid tokens, none of those passwords were the real password.
Press enter or click to view image in full size
At first I thought I was seeing things, but I validated the tokens against protected endpoints and they worked.
After finding out, it wasn’t magic. It was a TOCTOU race condition. In plain short the function that checks whether a login is allowed and the part that actually issues the token aren’t synchronized. If the auth function is slower than the incoming requests, multiple requests can slip past the check before the system updates state, so several different wrong passwords can all look “valid” because requests overtake the function’s internal timing.
What’s actually happening
Press enter or click to view image in full size
Imagine the login flow as two streets:
- the “check” street
and
- the “use” street
The code first walks down the check street and says “cool, this account looks allowed right now,” then walks down the use street and says “okay, I’ll create a session/token.”
If these two steps happen back to back, everything works perfectly.
But if the check step is slow (heavy CPU, slow DB, blocked I/O, overloaded server), multiple incoming requests line up behind it. They all get told “cross” by the initial check before the token-creation step finishes.
The result several requests reach the token-generation step even though the password validation should’ve failed.
In short:
when the auth function is slower than the incoming request rate, requests can overtake internal state and produce inconsistent results.
如有侵权请联系:admin#unsafe.sh