Index: [Article Count Order] [Thread]

Date:  Mon, 30 Jul 2007 09:54:22 -0500
From:  Brent Epp <brent (at mark) pdcweb.net>
Subject:  [coba-e:10493] Re: Php script vulnerabilities
To:  coba-e (at mark) bluequartz.org
Message-Id:  <634ejo$1d1br6 (at mark) wnpgmb01-c600f.mts.net>
In-Reply-To:  <46ADDC5C.8040908 (at mark) theanchoragesylvania.com>
References:  <46AC07A4.7000106 (at mark) theanchoragesylvania.com> <634ejo$1cta4k (at mark) wnpgmb01-c600f.mts.net> <46AD5046.2090305 (at mark) theanchoragesylvania.com> <46ADDC5C.8040908 (at mark) theanchoragesylvania.com>
X-Mail-Count: 10493

While this will help, the occurrence of '://' being the ultimate 
exploit is not necessarily the case.  An injection attack can still 
be very effective by exploiting any user variable ($_GET or $_POST) 
that hasn't been validated properly.

eg.:

<?php
shell_exec('ls ' . $_GET['pictures_match'] . '.jpg');
?>

$_GET['pictures_match'] could be: '*; rm -rf /; ls *';  This is, of 
course, the obligatory "delete all your files" example.  Claerly, you 
can see why this is bad where a user variable does not contain any 
sort of URL.  And, obviously, an attacker would have to know your 
application, but that's not too far fetched if these are open source 
apps we're talking about.

  - Brent

At 2007-07-30 07:41, you wrote:
>How can we protect ourselves? What is the common pattern here? It 
>seems that any occurrence of "://" in a http query string is 
>required for all of these attacks. What I would like to do (if it is 
>possible) is to block this from being passed to ANY php script in 
>the query string or POST variables etc.


Brent Epp
mailto:brent (at mark) pdcweb.net