Posted by Ian Hobson on 09/29/07 21:21

Peter wrote:
> Addionally,
>
> I figure this piece of code needs to be mentioned as well (placed before the
> earlier mentioned code) :
>
> if($_SERVER['QUERY_STRING']!="")
> $special_char='?';
> else $special_char="";
>
> Followed by earlier mentioned piece of code:
>
> $link =
> explode('/',$_SERVER['PHP_SELF'].$special_char.$_SERVER['QUERY_STRING']);
> $from = $link[sizeof($link)-1];
>
> Further investigating also shows (not hundred % sure, but it looks like it)
> that the problem only occurs on pages where parameters can be passed.
>
> e.g. page1?item=1
> etc.
>
>
Your problem is that $_SERVER['QUERY_STRING']); comes from the
user/script kiddie, and is not to be trusted. It is used unchecked.
The code needs to test it very carefully to stop what are called
injection attacks.

Your code works on the path the visitor typed - lets say it was
http://domain.com/path/path2/file.php?parm=value#param2=anothervalue

The first part reassembles the
"path/path2/file.php?parm=value#param2=anothervalue" part. If there is
no query string, it get just "path/path2/file.php".

Then explode, splits this into pieces at every "/".

And the last line takes the last entry - here
"file.php?parm=value#param2=anothervalue" (or just file.php).

But if the user typed a / in the value of param2 things go strange.

path/path2/file.php?parm=value#param2=an/injectionattack.php" will
result in the value of $link being "injectionattack.php".

I would let the interpreter parse the query string into the $_POST or
$_GET variable, and then take just the parameters expected
($_GET['parm'] and $_GET['param2']) and test those have sane values. For
example, contain only letters.

However, don't worry over much about injection attacks creating (bad?)
links to files on your web site - those will be served if the user
simply types their name anyway. What is much more dangerous is when the
data is sent to a database as part of a query.

Hope that helps.

Ian

[Back to original message]