It may not be insecure, but it is bloody annoying
on
A Decade of PHP
·
· Score: 1
I maintain a website built around an interesting collection of commercial, open-source and homebrew code. Recently, we had one bug where one part of the site would stop displaying any data, seemingly randomly.
The only bit of information I had in the bug report was that occasionally that particular section of the site would die horribly, and it would only happen in Firefox. There was no browser-specific code, nor anything obvious that'd cause it.
After about a month of on-and-off head-scratching, I figured it out - and the problem was partially caused by REGISTER_GLOBALS. Another part of the site (built with a different product) was setting a cookie with a paramater name used by the first. The cookie took precedence over the empty querystring, and the first piece of code ended up using a random session ID as a search string.
Why the Firefox red herring? The component setting the session ID cookie was only used by the site staff, and we all use Firefox. When we dropped into IE, we'd only look at the public areas of the site, and so never recieved the session cookie from the staff areas.
Yes, this could have been fixed by code changes in one or both of the applications (and in the end, that's what I did - my initial knee-jerk reaction was to turn off REGISTER_GLOBALS entirely, but yet another package on the site depended upon it). But, REGISTER_GLOBALS encourages action at a distance - in this case, logging onto one part of the site affected an entirely different part. There should not have been any coupling whatsoever between the two components - but thanks to PHP's "helpfulness", a link was created.
Eventually, I hope to get rid of dependencies on things like REGISTER_GLOBALS in the things I maintain. For preference, I'd do that by switching to Perl or Python, but I don't have the time to do that. Instead, I'm stuck in PHP, and cursing some of its more interesting misfeatures...
Slashdot Mirror
I maintain a website built around an interesting collection of commercial, open-source and homebrew code. Recently, we had one bug where one part of the site would stop displaying any data, seemingly randomly.
The only bit of information I had in the bug report was that occasionally that particular section of the site would die horribly, and it would only happen in Firefox. There was no browser-specific code, nor anything obvious that'd cause it.
After about a month of on-and-off head-scratching, I figured it out - and the problem was partially caused by REGISTER_GLOBALS. Another part of the site (built with a different product) was setting a cookie with a paramater name used by the first. The cookie took precedence over the empty querystring, and the first piece of code ended up using a random session ID as a search string.
Why the Firefox red herring? The component setting the session ID cookie was only used by the site staff, and we all use Firefox. When we dropped into IE, we'd only look at the public areas of the site, and so never recieved the session cookie from the staff areas.
Yes, this could have been fixed by code changes in one or both of the applications (and in the end, that's what I did - my initial knee-jerk reaction was to turn off REGISTER_GLOBALS entirely, but yet another package on the site depended upon it). But, REGISTER_GLOBALS encourages action at a distance - in this case, logging onto one part of the site affected an entirely different part. There should not have been any coupling whatsoever between the two components - but thanks to PHP's "helpfulness", a link was created.
Eventually, I hope to get rid of dependencies on things like REGISTER_GLOBALS in the things I maintain. For preference, I'd do that by switching to Perl or Python, but I don't have the time to do that. Instead, I'm stuck in PHP, and cursing some of its more interesting misfeatures...