好的，我现在需要帮用户总结一篇文章的内容，控制在100字以内。用户给了一段英文的文章，内容是关于一个安全测试的过程和发现的漏洞。 首先，我得通读整篇文章，理解主要情节。作者花了四天时间测试网站，发现了异常行为：网站有时很慢，有时很快。在慢的时候进行暴力破解登录测试，发现五个错误密码都能成功登录，得到有效的token。这其实是一个TOCTOU竞态条件漏洞，导致验证和令牌发放不同步。 接下来，我需要提炼关键点：测试时间、异常行为、暴力破解结果、漏洞类型以及原因。然后用简洁的语言把这些点连贯起来。 注意用户要求不要以“文章内容总结”这样的开头，直接写描述。还要控制在100字以内，所以要精炼每个部分。 可能的结构是：测试过程、发现问题、结果、漏洞解释。这样逻辑清晰。 最后检查字数是否符合要求，并确保没有遗漏重要信息。 </think> 作者花费四天时间测试网站安全漏洞，在不同时间段发现网站速度异常波动。在服务器负载过高的时段进行暴力破解登录时，发现五个错误密码均能成功获取有效令牌。这是由于TOCTOU竞态条件导致身份验证与令牌发放不同步所致。 2025-11-9 09:20:19 Author: infosecwriteups.com(查看原文) 阅读量:27 收藏
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