How a PHP escaping feature undermined a browser XSS filter
PHP魔术引号如何影响IE XSS过滤器的判断
This note looks at a documented interaction between a now-removed PHP feature, magic_quotes_gpc, and a browser's built-in reflected-XSS filter, as an example of how two separate security mechanisms can undermine each other.
What magic_quotes_gpc did
When enabled, this PHP setting automatically escaped certain characters in incoming request data, inserting a backslash before quotes and the NUL character wherever they appeared. The feature was meant to make raw database queries slightly safer by default, before parameterised queries became the universal standard, and PHP later removed it entirely because it caused more confusion than protection.
Where the filter's assumptions broke down
A browser's reflected-XSS filter works by inspecting the request for patterns that look like a script injection and then adjusting the response if it finds one. Because magic_quotes_gpc transformed certain bytes in the request before the application ever saw them, the pattern the filter expected to see did not always match what ended up in the page. A NUL byte inserted by the escaping feature behaved differently in the browser's parser than in the filter's pattern matcher, so a script tag broken up around that byte could still execute even though it no longer matched the filter's signature.
Why this is a server-plus-client problem, not just one bug
Neither the PHP feature nor the browser filter was solely at fault. The escaping feature was never a substitute for proper output encoding and was deprecated for that reason. The browser filter, meanwhile, was a heuristic working on raw bytes with an incomplete model of how the rest of the stack would interpret them. The combination of two partial mitigations allowed a gap neither would show on its own.
Takeaway for builders
This is a useful reminder that layered mitigations need to be tested together, not just individually. A fix that escapes or filters data at one point in the pipeline can change the very signal that a later filter relies on. The durable answer, then and now, is correct, context-aware output encoding at the point content is rendered, plus a strict Content Security Policy, rather than input-side escaping tricks or browser heuristics.
Key takeaways
- magic_quotes_gpc escaped quotes and NUL bytes in PHP requests but was never a substitute for output encoding.
- A browser's reflected-XSS filter worked from byte patterns that assumed a different request shape than the escaped data produced.
- Two partial mitigations layered together can leave a gap that neither covers alone.
- Context-aware output encoding and CSP remain the durable fix, not input-side escaping or browser heuristics.
中文摘要
本文说明PHP的magic_quotes_gpc转义特性如何改变请求数据，使其与IE内置XSS过滤器的模式匹配假设不一致，从而让有害输入绕过过滤器，并指出可靠的防护仍是上下文相关的输出编码。
This note has been rewritten and checked for this edition; it is not a copy of the original post.