[PLUG] Preventing Probes Like This

Rogan Creswick creswick at gmail.com
Mon Aug 25 17:25:33 UTC 2008


On Mon, Aug 25, 2008 at 10:02 AM, Bill Thoen <bthoen at gisnet.com> wrote:
> Oh well, I suppose it's just one more brick in the wall... I guess I'll
> amend that redirect trick and block any attempt at using index.php with
> a '?' after it.

Er... that's not the right solution.  You're trying to fix a leaky
boat by drinking the water -- your feet may be dry now, but it's not
going to end well.

If you are writing the php app, then you should make it so that such
an attack *is not possible*.  The application itself should deny this
sort of thing -- by *never* trusting anything that you cannot
guarantee came from your server. (URLs, form fields, user names,
passwords, etc... these are all very, very dangerous places to get
inputs.)

Please, please, please, don't write another app that is only remotely
safe if you follow a laundry list of steps that set up a "secure"
environment.  You will invariably miss something (it happens to us
all) and the next person to install your app will also miss something,
or type a regular expression into their .htaccess file wrong, or need
to modify it so that requests to their wordpress blog still work...
etc.  (and that person may be you -- you are going to do a full
reinstall when your box gets rooted, right?)

If you are not the application author, then use a different
application and report the bug!

--Rogan

>
> Thanks for the tip!
> - Bill Thoen
>
> Tim wrote:
>>>> Anyone have any ideas on how to prevent probe attempts like this one
>>>> from succeeding?
>>>>
>>>> From 66.40.56.32:
>>>>
>>>> /index.php?url=../../../../../../../../../../../../../etc/passwd%00 HTTP Response 200
>>>>
>>> If index.php will never take any arguments, and assuming you're
>>> running Apache, this will work:
>>>
>>>    RedirectMatch  gone  ^/index\.php\?.*$
>>>
>>> The "gone" returns an HTTP 410 error, "indicated that the resource has
>>> been permanently removed." You can, however, return any numeric status
>>> code you want.
>>>
>>
>>
>> Why bother?  The key here is to have secure handling of the url
>> parameter.  Here are some approaches you should consider, in order, to
>> avoid path traversal issues:
>>
>> 1. Don't include any user-supplied values in filesystem paths.  If a
>>    dynamic path is needed on the backend, use an array as a lookup table
>>    and have the page accept only specific keys into that table.
>>
>> 2. If you *have* to include user-supplied values in filesystem paths
>>    (which is actually very rare, you should reconsider), then take the
>>    value, normalize it as a path using built-in path routines (don't
>>    remember what PHP has for this) and only then concatenate it with
>>    your path prefix.
>>
>>
>> If your concern here is about a third-party PHP app that you've
>> installed and aren't sure how it works under the hood... well you should
>> think about trying something else.  I make a living out of breaking into
>> websites and something about the PHP platform encourages insecure coding
>> practicies.  There are so many incredibly insecure open source PHP apps
>> out there that you'd have to spend a lot of time and effort vetting it.
>> Filtering URLs for specific types of evil on specific pages is a lost
>> cause.  Perhaps try a Python, Ruby or J2EE app.
>>
>>
>> good luck,
>> tim
>> _______________________________________________
>> PLUG mailing list
>> PLUG at lists.pdxlinux.org
>> http://lists.pdxlinux.org/mailman/listinfo/plug
>>
>>
>
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>



More information about the PLUG mailing list