Re: Security Issues

On Wednesday, July 25, 2001, at 11:31 PM, Sebastian Bergmann wrote:

PHP wrote:

On Wed, Jul 25, 2001, Sebastian Bergmann wrote:

Andy wrote:

If register_globals = off is highly recommended, why does the default php.ini have register_globals=on

For backward compatibility reasons. We intend to break this, and other things, with either PHP 4.1 or PHP 5.

Ah, you must be a PHP core developer! So good to meet you!

No, not really. I'll fwd this to php-dev.

Where it'll be discussed, ad nauseam, by developers working in/on/around the core, as well as the core..... :-)

%foo // this is a different foo, it is read only and came in via a POST or GET or otherwise.

Here's why this entire *concept* is silly: I'll make a file... ---------------------Badpage.html <form method="post" action="attacktarget?foo=badfoo"> <input type="hidden" name="foo" value="badfoo"> </form> ------------------------------------- Oh, and I should edit my cookies too.... just in case they're using sessions or other cookies....and now I've now rendered all of the HTTP_*_VARS features moot for variable "protection". Every single one can be forged. GET, POST, COOKIES, SESSIONS, FILES. Developers need to learn that user submitted vars, regardless of namespace, are always potentially bad. Period. Turning register_globals one way or another does absolutely *nothing* to fix it. Prepending get or post submissions with special tokens does not fix it. Simply using the variable order controls does not fix it. Any illusion of security, in this case, is purely aesthetic. What *might* fix it? 1. Heavy duty random encryption of every variable. Which would make PHP amazingly slow. 2. Wise coding. (+1 on E_ALL as the default error level). 3. Coding for vars coming from bad places (POST that should be GET) resulting in server lockout (if somebody's hacking your vars, deny access, but pointless and damaging for proxy-based users like, oh, AOL.com) I'm really lost on the point of the entire "no-globals" approach, other than using method #3., which is non-functional for large sites... but I code with #2, and check variables heavily. If you want to protect your own vars, PHP already has those tools, in some manner (maybe a perl-like "taint" would help new developers? Anybody who lives and breathes perl might want to point out how it differs from E_ALL warnings and functionality, as I'm not fluent in taint usage and features...). -Ron --2D426F70|759328624|00101101010000100110111101110000 ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ The opinions expressed in this email are not necessarily those of myself, my employers, or any of the other little voices in my head.