How an oversized-cookie error page turned into an httponly bypass
Apache httpOnly Cookie 泄露的利用原理分析
This note looks past the headline of CVE-2012-0053 and at the mechanics that made it exploitable in practice: the attack never read a protected cookie directly, it manufactured the conditions for the server to leak it instead.
The httponly protection it worked around
Cookies marked httponly cannot be read by client-side JavaScript through document.cookie, which closes the most direct route from a cross-site scripting bug to session-cookie theft. Many sites of that era relied on httponly as their main defence against exactly that scenario.
The missing piece: a size threshold, not a read
The affected Apache versions responded to a request whose total header size, cookies included, exceeded a configured limit with a 400 error page that echoed the request's headers back in full, for diagnostic purposes. A cookie an attacker could not read directly was still present in that echoed output, because the server itself, not the browser's script sandbox, was emitting it.
Why a second, weaker flaw was still required
Reaching that error state needed the total cookie payload to cross the server's size threshold, and ordinary legitimate cookies rarely reached it on their own. The documented exploitation path used a separate, unrelated XSS bug on the same origin, not to read the protected cookie, but only to append additional throwaway cookie values of the attacker's choosing until the combined size crossed the limit. A follow-up request then triggered the oversized-header error, and the resulting error page, not any script execution, is what exposed the original httponly cookie in its output. A script on the page could then parse that error page's body as ordinary HTML and extract the cookie value from it.
The general lesson
This chain is a useful reminder that a security control can be technically intact and still be worked around by changing the conditions around it rather than attacking it head-on. httponly correctly blocked every attempt to read the cookie through document.cookie; the attack simply never needed that read, because the server was willing to print the same value somewhere else under the right conditions.
Takeaway for defenders
Audit error pages and diagnostic responses for sensitive data just as carefully as application pages, and set conservative limits on what a server will echo back about a request it has rejected.
Key takeaways
- The attack did not read the httponly cookie via script; it exploited a server-side echo in an oversized-request error page.
- A separate, weaker XSS flaw was still needed, used only to pad the cookie jar past the server's size limit.
- httponly worked exactly as designed against the client-side read path; the bypass went around it entirely, not through it.
- Diagnostic and error responses deserve the same sensitive-data review as normal application pages.
中文摘要
本文说明 CVE-2012-0053 的实际利用方式：攻击并非直接读取受 httponly 保护的 Cookie，而是借助另一个较弱的XSS漏洞填充无关Cookie使总长度超过服务器限制，触发400错误页面将Cookie原样回显，从而间接泄露。
This note has been rewritten and checked for this edition; it is not a copy of the original post.