[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Anton Channing wrote:
>
> I suspected that might be also be possible
> but that really stretched my knowledge about
> cookies!
Which is also why good PHP installs encrypt their cookies.
I'm becoming more disillusioned with PHP security everyday.
Debian doesn't help with it's "insecure by default" stance on the
Apache{2} "php.ini".
This week saw the release of the PHP version that closes some of the
issues from the PHP month of bugs.
But I'm now convinced that PHP is now far more complex to do right than
Perl, since you have to handle all the historical ways PHP got their
security wrong. I mean how many PHP programmers follow the advice to
handle both the cases of "magic quotes" being on and off?
Attempts to tighten PHP security at a certain local ISP almost
completely failed, there is just too much code out there that relies on
long deprecated, and insecure features of the language. Sure you can get
the memory overflow, and the resource exhaustion checks in easily, but
blocking suspect include methods, obsoleted system variables and the
like, just isn't going to happen here any time soon. Even encrypting
cookies can break a surprising amount of code (and I don't just mean for
people who don't delete the old unencrypted cookies).
If you start with a properly secured PHP server, modern version, and
wrote your code accordingly, you might get away with it, but I'd be much
more convinced of a new users ability to enable "Taint" in Perl CGI, and
produce vaguely secure code.
Simon
--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html