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
[EMAIL PROTECTED], 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.
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
