# PHP 5.2.0 release with "broken" input filters - Thread: https://externals.io/message/26171 - Original archive: https://news-web.php.net/php.internals/26171 - Started by Stefan Esser on 2006-10-23T08:48:56+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #26171 — Stefan Esser — 2006-10-23T08:48:56+00:00 URL: https://externals.io/message/26171#26171 Hi, I just wanted to remind you that PHP 5.2.0 will be released with broken and inconsistent input filtering. Right now _SERVER is only passed through the input filter for apache 1 SAPI. All other SAPIs do not pass _SERVER variables through the filter. This will be a major headache for people using ext/filter etc... Stefan --- ## #26174 — Pierre — 2006-10-23T10:18:13+00:00 URL: https://externals.io/message/26171#26174 · In reply to: #26171 Hello Stefan, > Hi, > > I just wanted to remind you that PHP 5.2.0 will be released with broken > and inconsistent input filtering. > > Right now _SERVER is only passed through the input filter for apache 1 > SAPI. All other SAPIs do not pass _SERVER variables through the filter. While discussing a couple bugs related to SERVER and ENV with Ilia (empty value, leaks and JIT problems in other SAPI or CLI), we decided to disable them if no soloution has been found for these two inputs. They are still present for now, during the RC phase. The problem is to keep JIT working even when a default filter is defined, it makes little sense to initialize and duplicate these variable during the sapi filtering step. > This will be a major headache for people using ext/filter etc... etc...? --Pierre --- ## #26182 — Ilia Alshanetsky — 2006-10-23T15:18:55+00:00 URL: https://externals.io/message/26171#26182 · In reply to: #26171 > Hi, > > I just wanted to remind you that PHP 5.2.0 will be released with > broken > and inconsistent input filtering. > > Right now _SERVER is only passed through the input filter for apache 1 > SAPI. All other SAPIs do not pass _SERVER variables through the > filter. > This will be a major headache for people using ext/filter etc... In some SAPIs such as CLI it makes little sense to filter $_SERVER in majority of cases. As a whole I do not believe $_SERVER in its entirety needs to be filtered, given that at least 1/2 the data there is not based on user-input. My suggestion is that people use `filter_var()` function to filter components of the $_SERVER super- global that they are using. That said, in future release there are plans to extend support to Apache 2 and cgi/fcgi sapis as well as add handling for $_REQUEST. Ilia Alshanetsky --- ## #26184 — Pierre — 2006-10-23T15:28:17+00:00 URL: https://externals.io/message/26171#26184 · In reply to: #26182 Hello, > > > > > […] > > In some SAPIs such as CLI it makes little sense to filter $_SERVER in > majority of cases. As a whole I do not believe $_SERVER in its > entirety needs to be filtered, given that at least 1/2 the data there > is not based on user-input. My suggestion is that people use > `filter_var()` function to filter components of the $_SERVER super- > global that they are using. > > That said, in future release there are plans to extend support to > Apache 2 and cgi/fcgi sapis as well as add handling for $_REQUEST. Yes, and more generally as soon as we fix the leaks and the other troubles we spoted recently. I still like to disable ENV/SERVER support in 5.2.0 (just like _REQUEST), we can restore it later. --Pierre --- ## #26189 — Pierre — 2006-10-23T16:12:07+00:00 URL: https://externals.io/message/26171#26189 · In reply to: #26184 Hello, > Hello, > > > > […] > > Yes, and more generally as soon as we fix the leaks and the other > troubles we spoted recently. I still like to disable ENV/SERVER > support in 5.2.0 (just like _REQUEST), we can restore it later. I just discussed with Ilia about this problem. 5.2.0 will be kept as it is now, only the apache1 sapi will be supported. Other sapi will be introduced for 5.2.1. Ilia already have a patch for apache2 sapi support, it will be commited in HEAD as soon as possible, other will follow. Thanks for the head up, --Pierre --- ## #26190 — Rasmus Lerdorf — 2006-10-23T17:38:31+00:00 URL: https://externals.io/message/26171#26190 · In reply to: #26182 Ilia Alshanetsky wrote: > > > > > […] > > In some SAPIs such as CLI it makes little sense to filter $_SERVER in > majority of cases. As a whole I do not believe $_SERVER in its entirety > needs to be filtered, given that at least 1/2 the data there is not > based on user-input. My suggestion is that people use `filter_var()` > function to filter components of the $_SERVER super-global that they are > using. I had left out SERVER filtering in the initial version for much the same reasoning, but it turns out that a good chunk of holes were due to the fact that people used $_SERVER['REQUEST_URI'] unfiltered. Trying to teach people which SERVER vars are safe and which aren't isn't a fun task and the whole point of the filter extension is to take away the guessing game. -Rasmus --- ## #26204 — Richard Lynch — 2006-10-23T19:54:40+00:00 URL: https://externals.io/message/26171#26204 · In reply to: #26190 > I had left out SERVER filtering in the initial version for much the > same > reasoning, but it turns out that a good chunk of holes were due to the > fact that people used $_SERVER['REQUEST_URI'] unfiltered. Trying to > teach people which SERVER vars are safe and which aren't isn't a fun > task and the whole point of the filter extension is to take away the > guessing game. Perhaps in 6.0 one could consider having: $_SERVER $_SERVER_DIRTY or some similar scheme so that people *know* there is something "wrong" with just blindly using that data... Or rename it, so it's not "SERVER" for user-supplied data... I mean, you've labeled it "SERVER" so I figure it comes from the SERVER, right? Not from the USER... I know, that's a stupid way to look at things, but there it is. PS Digging the Yahoo! Maps API :-) -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --- ## #26211 — Peter Brodersen — 2006-10-23T23:11:25+00:00 URL: https://externals.io/message/26171#26211 · In reply to: #26190 On Mon, 23 Oct 2006 10:38:31 -0700, in php.internals rasmus@lerdorf.com (Rasmus Lerdorf) wrote: >I had left out SERVER filtering in the initial version for much the same >reasoning, but it turns out that a good chunk of holes were due to the >fact that people used $_SERVER['REQUEST_URI'] unfiltered. Trying to >teach people which SERVER vars are safe and which aren't isn't a fun >task and the whole point of the filter extension is to take away the >guessing game. More well-known, the same goes for the HTTP headers populated in _SERVER as well, even though some might be less obvious than other. HTTP_HOST could be tainted as well in some cases where a DNS entry and ServerAlias of *.example.com exists. An attacker could trick a user into visiting www.%22%3EXSS.example.com which at least IE6 would accept as a valid URL. -- - Peter Brodersen --- ## #26212 — Rasmus Lerdorf — 2006-10-23T23:26:57+00:00 URL: https://externals.io/message/26171#26212 · In reply to: #26211 Peter Brodersen wrote: > On Mon, 23 Oct 2006 10:38:31 -0700, in php.internals > rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > > > […] > > More well-known, the same goes for the HTTP headers populated in > _SERVER as well, even though some might be less obvious than other. > > HTTP_HOST could be tainted as well in some cases where a DNS entry and > ServerAlias of *.example.com exists. Actually, by using the Flash hack, you don't need wildcard DNS to exploit that one. As anybody who has seen my ranting lately can attest to, name-based virtual hosting is completely broken until we get everyone onto Flash9. -Rasmus --- ## #26257 — Richard Lynch — 2006-10-25T22:21:01+00:00 URL: https://externals.io/message/26171#26257 · In reply to: #26212 > Peter Brodersen wrote: > > […] > > Actually, by using the Flash hack, you don't need wildcard DNS to > exploit that one. As anybody who has seen my ranting lately can > attest > to, name-based virtual hosting is completely broken until we get > everyone onto Flash9. Haven't read the rant (yet) but, errrr, have they released Flash anything in this millenium for Linux?... Cuz it seems like I never can manage to get to download anything higher than Flash Player 6 for my Linux box desktop at home. Which is ancient hardware/OS, so maybe that's the issue... -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --- ## #26258 — Pierre — 2006-10-25T22:41:10+00:00 URL: https://externals.io/message/26171#26258 · In reply to: #26257 Hello, > Haven't read the rant (yet) but, errrr, have they released Flash > anything in this millenium for Linux?... > > Cuz it seems like I never can manage to get to download anything > higher than Flash Player 6 for my Linux box desktop at home. Which is > ancient hardware/OS, so maybe that's the issue... Besides the fact that it is off topic, yes, they've released flash for linux. The flash 9 beta has been released a couple of weeks ago. --Pierre