[lug] Safely Parsing PHP Parameters
George Sexton
gsexton at mhsoftware.com
Wed Oct 10 20:33:06 MDT 2007
Yuck. I looked at PHP again today after not having looked at it for a
long time. What a childish mess.
I need to write an application proxy, and I thought I would use a
singleton pattern. The only thing I need is semaphores for
synchronization. Great, there's a semaphore package. No, wait, the
Semaphore stuff isn't universal.
You can't depend upon CURL being there. At least it's not there on my
server. You can't depend upon allow_url_fopen being turned on. It is on
my server, but may not be on shared hosts.
In Java Servlets, by spec, you're guaranteed a working directory you can
write to. PHP doesn't guarantee a writable working directory.
Gross. Even IIS/ASP.NET is better than this schlock.
I remember looking at the Horde/IMP project and being amazed at the lack
of forward progress. There's really no wonder. PHP is just a pitiful
excuse for an application development platform.
Lee Woodworth wrote:
> Zan Lynx wrote:
>> On Wed, 2007-10-10 at 14:13 -0600, Bill Thoen wrote:
>>> Zan Lynx wrote:
>>>> And I think forcing the conversion to int will make your code safe
>>>> enough. As long as no one can do a ?essay=../../../../../etc/passwd or
>>>> anything like it.
>>>>
>>> That's exactly the sort of thing I'm worried about. How in the world
>>> would a hacker get anything useful with a trick like this? I never
>>> display the parameter value (except as an integer, and only if it's in
>>> the correct range). Does shoving the contents of the passwd file turn it
>>> into global variables or something?
>> No, but lets say you had code later on that did something like:
>> output("$ESSAY_PATH/$essay/$page");
> Don't know PHP, but IIRC, in perl:
--
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL: http://www.mhsoftware.com/
More information about the LUG
mailing list