A login check that ran the page anyway
一个在重定向之后仍继续执行的登录校验
This note describes a business-logic flaw found in an administrative backend belonging to a large web portal, reported as the kind of authentication gap that is easy to introduce and easy to miss in testing.
The intended check
The backend's authentication logic was meant to work in the obvious way: if a request arrived without a valid session, the server would issue an HTTP redirect back to the login page, and anyone without a session would simply never see the protected content.
Where the logic broke
The server-side code correctly detected the missing session and issued the redirect header, but it did not stop executing the rest of the page afterwards. In several web frameworks of that era, sending a redirect header only queues it for the response; the script keeps running unless it is explicitly told to stop. Because that stop instruction was missing, the server went on to render the full protected page content into the same response that also carried the redirect header.
Why that is exploitable
A normal browser follows the redirect immediately and never displays the page content that came with it, which is why the bug stayed hidden during ordinary use and casual testing. An attacker controlling the request, however, can simply suppress that one response header, using an intercepting proxy, and keep the rest of the response as rendered by the server. With the redirect header removed, the browser renders the protected page body in full, because the server already produced it.
The general pattern
This flaw sits in a well-known category: an authentication check that produces the correct instruction (redirect) without enforcing it (halting execution). It differs from a missing authentication check entirely, which is usually caught quickly; a check that fires but does not block is subtler, because the application behaves correctly for every normal user and only fails for someone deliberately manipulating the response.
Takeaway for builders
An authentication gate must halt processing immediately once it decides to deny access, never merely queue a redirect and continue. Treat "redirect, then keep running" as a code smell worth searching for specifically in any legacy codebase, and verify access control by testing with a proxy that can suppress a response header, not just by clicking through the application.
Key takeaways
- The backend issued a login redirect but kept executing and rendering the protected page in the same response.
- A normal browser following the redirect masked the bug; an intercepting proxy that drops one header exposed it.
- A check that fires without halting execution is a distinct and subtler bug class from a missing check altogether.
- Access-control testing should include suppressing redirect headers with a proxy, not only normal click-through testing.
中文摘要
本文分析了一个大型网站后台管理系统中的业务逻辑漏洞：服务器在未认证时发出跳转指令后并未终止脚本执行，导致受保护页面内容仍随响应一并返回，只要拦截并移除跳转头即可绕过身份验证查看后台。
This note has been rewritten and checked for this edition; it is not a copy of the original post.