[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