By comparison, PHP actually prevents you from using \r\n in your header() calls to inadvertently make multiple headers or break off into the body. It spits out a
Warning: Header may not contain more than a single header, new line detected.
PHP has a reputation for insecurity, but it also has a lot of built-in features that help you build secure web apps if used correctly. Some of PHP's earlier experiments were disasterous, (I'm talking about you, magic quotes!) but recent fixes like this actually seem to be pretty well thought out. PHP itself can be seen almost a lightweight web framework, albeit a particularly ugly one.
Other languages, such as Python, were not designed specifically with web apps in mind. So a web developer using such a language must make sure he's doing all the web-specific stuff properly. Which is tedious and error-prone, and that's one reason why nobody should use Python on the web without a decent framework.
Yup. That change dates back to PHP 4.4.2, which was released back in January 2006. It's listed at http://php.net/ChangeLog-4.php as "Prevent header injection by limiting each header to a single line."
I'm actually curious about a recent feature addition, in 5.3.4:
"Paths with NULL in them (foo\0bar.txt) are now considered as invalid. (Rasmus)"
If that's really the case, it seems like Rasmus has eliminated a large swath of null byte vulnerabilities in PHP applications (at least those null byte vulnerabilities involving the filesystem, which are the kind I'm used to seeing). I've been meaning to compile 5.3.3 and 5.3.4 locally to test out the different behaviors.
> If that's really the case, it seems like Rasmus has eliminated a large swath of null byte vulnerabilities in PHP applications.
Yes -- this specific change mitigates a lot of simple local file inclusion vulnerabilities. It's not a cure-all, but it does at least prevent many common antipatterns (e.g, include("languages/$_COOKIE['lang'].php")) from being trivially exploited.
