Virtual Server vulnerability through URL parameters?

[Bernhard Sturm]

Hi Group
I don't know if it's the right place to ask, but I'll try it:

I have set up a site using PHP includes for the content parts of a page:

I have one index.php that uses different includes for menu, navigation,
footer and header. the content is included through this part of the code:

<div id="middle" align="left">
<?php // content einbinden
include($content);
?>
<br />
</div>

via URL parameter content the content is fed to the index.php. Like this:
http://cellntec/sandbox/index.php?content=contact/index.php

Where the content is kept in content/index.php e.g.:

<p>Using novel progenitor cell-targeted isolation techniques and culture
media, xxxx
Advanced Cell Systems has developed a range of epithelial in vitro
systems with
a striking suite of features. These include</p>

now my host has shut down the site because he says that this will put a
threat to all his virtual servers on the same server... I have no clue
(and maybe my PHP knowledge is too limited...) Is there a known exploit
for URL parameters?

thanks for any reply


bernhard

 

[rf]

Hi Group
I don't know if it's the right place to ask, but I'll try it:

Probably not, especially since you multiposted exactly the same thing over
in alt.php, where the subject *is* on topic.

Where do you want your answer?

 

[Bernhard Sturm]

On 1/6/2005 2:59 PM rf spoke thusly

Probably not, especially since you multiposted exactly the same thing over
in alt.php, where the subject *is* on topic.

i posted it first here... and later in alt.php. as it is a server
related issue I am not even sure, if it fits into alt.php... so I hoped
that someone here had the same problem before (as I am more in alt.html
than alt.php)... yeah I know lame excuse, but since I asked, I hoped for
an answer.

Where do you want your answer?

anywhere
multiposting is not allowed in NG? (I did not cross-post).

bernhard

 

[rf]

On 1/6/2005 2:59 PM rf spoke thusly

i posted it first here... and later in alt.php. as it is a server
related issue I am not even sure, if it fits into alt.php... so I hoped
that someone here had the same problem before (as I am more in alt.html
than alt.php)... yeah I know lame excuse, but since I asked, I hoped for
an answer.

Hmmm. A group dealing with hosting stuff may be better. alt.www.webmaster?
One of the comp hieratchy?

anywhere

OK, from an HTML point of view there is no answer as it is not an HTML
issue. HTML is client side, not server side.

That said, nothing, repeat, nothing that comes from client side should be
used in PHP without first being sanity tested. This is to stop "insertion"
of bad things. For example, if you have a database that accepts a query
string from client side then the user can terminate that query string with a
' and follow it with some SQL to delete your entire database. You have to
check for this.

Your case is a bit milder but what, for example, if I were to plug in
"content="../../../../whatever". I just might get to the root of you hosts
server, if said host has not set up the server correctly, and access the
password file.

Why this should be an issue is really strange, assuming your host has the
server set up correctly. However, your host has made a statement so either
fix it or, preferably, get a better host.

Of course you will probably get much better answers over at alt.php.

multiposting is not allowed in NG? (I did not cross-post).

Crossposting to appropriate newsgroups is recommended. Multiposting is
frowned upon, it splits the conversation into two or more disparate groups.
Those who work hard on an answer here may find that the same answer has
already been posted elsewhere. With crossposting everybody sees all the
answers in all groups.

 

[SpaceGirl]

Hmmm. A group dealing with hosting stuff may be better. alt.www.webmaster?
One of the comp hieratchy?




OK, from an HTML point of view there is no answer as it is not an HTML
issue. HTML is client side, not server side.

Not truuuueeeeeee....

XHTML also has server side implications, especially if you are doing a
lot of translations (XSLT). It may only be DISPLAYED client site, but
that doesn't mean it's only processed client side

--


x theSpaceGirl (miranda)

# lead designer @ http://www.dhnewmedia.com #
# remove NO SPAM to email, or use form on website #

 

[Bernhard Sturm]

On 1/6/2005 3:26 PM rf spoke thusly

Hmmm. A group dealing with hosting stuff may be better. alt.www.webmaster?
One of the comp hieratchy?




OK, from an HTML point of view there is no answer as it is not an HTML
issue. HTML is client side, not server side.

okay.. i have found an answer.. it's a pretty serious issue as it deals
with a known vulnerability of include() published recently in the german
c't magazin... since it's not of interest here I will post the answer in
alt.php...

cheers for your help

Crossposting to appropriate newsgroups is recommended. Multiposting is
frowned upon, it splits the conversation into two or more disparate groups.
Those who work hard on an answer here may find that the same answer has
already been posted elsewhere. With crossposting everybody sees all the
answers in all groups.

okay.. thanks.. I always thought cross-posting was frowned upon (I did
it once, and got flamed...)


bernhard

 

[Neal]

okay.. thanks.. I always thought cross-posting was frowned upon (I
did it once, and got flamed...)

Crossposting is annoying when the post is not on topic for all
newsgroups. That may be what happened.

Better to choose only one group, but if it really is on topic for
both, crosspost.

 

[Bernhard Sturm]

okay.. thanks.. I always thought cross-posting was frowned upon (I did
it once, and got flamed...)

Crossposting is annoying when the post is not on topic for all
newsgroups. That may be what happened.

Better to choose only one group, but if it really is on topic for both,
crosspost.[/QUOTE]

so it was okay not to crosspost in this case, as I was really not sure,
if it's of concern for alt.html. And it turned out, that my multipost
was frowned upon, but the crosspost would have been as well.. sigh..
it's hard to post these days.. but anyway I was able to find a solution
to my problem..

bernhard

 

[Jeffrey Silverman]

Hi Group
I don't know if it's the right place to ask, but I'll try it:

I have set up a site using PHP includes for the content parts of a page:

I have one index.php that uses different includes for menu, navigation,
footer and header. the content is included through this part of the code:

<div id="middle" align="left">
<?php // content einbinden
include($content);
?>
<br />
</div>

via URL parameter content the content is fed to the index.php. Like this:
http://cellntec/sandbox/index.php?content=contact/index.php

Where the content is kept in content/index.php e.g.:

<p>Using novel progenitor cell-targeted isolation techniques and culture
media, xxxx
Advanced Cell Systems has developed a range of epithelial in vitro
systems with
a striking suite of features. These include</p>

now my host has shut down the site because he says that this will put a
threat to all his virtual servers on the same server... I have no clue
(and maybe my PHP knowledge is too limited...) Is there a known exploit
for URL parameters?

thanks for any reply


bernhard

I don't think there is an exploit, per se, for URL parameters. But what
you are trying looks dangerous! At the very least, sanitize the code with
some checking of the variable before you include() it!

if (is_file($content)){
include($content);
}

I am probably missing something important but this is a start at least.

 

[Bernhard Sturm]

Hi Group
I don't know if it's the right place to ask, but I'll try it:

I have set up a site using PHP includes for the content parts of a page:

I have one index.php that uses different includes for menu, navigation,
footer and header. the content is included through this part of the code:

<div id="middle" align="left">
<?php // content einbinden
include($content);
?>
<br />
</div>

via URL parameter content the content is fed to the index.php. Like this:
http://cellntec/sandbox/index.php?content=contact/index.php

Where the content is kept in content/index.php e.g.:

<p>Using novel progenitor cell-targeted isolation techniques and culture
media, xxxx
Advanced Cell Systems has developed a range of epithelial in vitro
systems with
a striking suite of features. These include</p>

now my host has shut down the site because he says that this will put a
threat to all his virtual servers on the same server... I have no clue
(and maybe my PHP knowledge is too limited...) Is there a known exploit
for URL parameters?

thanks for any reply


bernhard

I don't think there is an exploit, per se, for URL parameters. But what
you are trying looks dangerous! At the very least, sanitize the code with
some checking of the variable before you include() it!

if (is_file($content)){
include($content);
}

I am probably missing something important but this is a start at least.[/QUOTE]

you are right. is_file would be one solution. I have choosen the
solution to ensure, that only files within a certain directory hierarchy
are allowed to be processed by the script. so no '../../etc/passwd' can
be read ou (which would still be possible with is_file...) but anyway,
it's OT here.


bernhard

 

[Richard]

Hi Group
I don't know if it's the right place to ask, but I'll try it:

I have set up a site using PHP includes for the content parts of a
page:

I have one index.php that uses different includes for menu, navigation,
footer and header. the content is included through this part of the
code:

<div id="middle" align="left">
<?php // content einbinden
include($content);

<br />

via URL parameter content the content is fed to the index.php. Like
this:
http://cellntec/sandbox/index.php?content=contact/index.php

Where the content is kept in content/index.php e.g.:

media, xxxx
Advanced Cell Systems has developed a range of epithelial in vitro
systems with
a striking suite of features. These include</p>

now my host has shut down the site because he says that this will put a
threat to all his virtual servers on the same server... I have no clue
(and maybe my PHP knowledge is too limited...) Is there a known exploit
for URL parameters?

thanks for any reply

"You can have any color you want as long as it's black."
Henry Ford.

Ok. So you write that huge site for 800x600 and those of us who have
1024x768 whine about why is there so much space not being used?
Any more, the vast majority of surfers are of the latter size.
So why cater to a minority?
Using css, and either javascript or php, there are ways to circumvent the
user's screen size.
My pet gripe with most websites is the font type used.
Usually way to small.
But they go overboard in making sure their ad's get seen.

Oh and those poor poor web tv users can't surf because they have no
horizontal scrolling?
Not their fault.
So you design YOUR site, the way you want it to look.

Learn how to use css properly and fix those overlapping text problems.

 

[Bernhard Sturm]

On 1/6/2005 9:47 PM Richard spoke thusly

"You can have any color you want as long as it's black."
Henry Ford.

Ok. So you write that huge site for 800x600 and those of us who have
1024x768 whine about why is there so much space not being used?
Any more, the vast majority of surfers are of the latter size.
So why cater to a minority?
Using css, and either javascript or php, there are ways to circumvent the
user's screen size.
My pet gripe with most websites is the font type used.
Usually way to small.
But they go overboard in making sure their ad's get seen.

Oh and those poor poor web tv users can't surf because they have no
horizontal scrolling?
Not their fault.
So you design YOUR site, the way you want it to look.

Learn how to use css properly and fix those overlapping text problems.

humm to what exactly are you refering to? I have not submited a URL to
my problem... and the thread had nothing to do with screen resolution.
please clarify...


bernhard

 

[Hywel Jenkins]

Ok. So you write that huge site for 800x600 and those of us who have
1024x768 whine about why is there so much space not being used?
Any more, the vast majority of surfers are of the latter size.
So why cater to a minority?
Using css, and either javascript or php, there are ways to circumvent the
user's screen size.

There's no way at all to circumvent the user's screen size. There's
absolutely nothing *you* as a developer can do to get around the fact
that I have a 17" monitor.

You're in the wrong thread, too, RtS.

 

[Andy Dingley]

humm to what exactly are you refering to?

Richard is our local pet idiot. Just ignore him.

As for a parameterised include(), then it's _very_ dangerous. I'm not
a PHP geek, or even a Unix/Apache guru, so my surprise that it's
hazardous to _other_ virtual users might be unwarranted. It's
certainly hazardous to _your_ site though, so avoid it anyway.

Don't do it. Dynamic stuff like this bumps up the server load
massively and doesn't add any useful benefit. If you're serving static
content, then leave it static. If you need to include shared menus
etc., include the static portion from within the varying content
pages, don't try to put the varying part in the static, as you're
doing here. A simple SSI mechanism is also simpler and more efficient
thatn PHP's.

Don't do "cute stuff" in general. If it was useful, we'd all be doing
it. There just aren't many reasons to do things in a non-standard way
on the web -- we've solved the big problems for the run-of-the-mill
stuff. Unless you really are doing something novel, stick with the
mainstream.

 

[Bernhard Sturm]

On 1/7/2005 12:12 AM Andy Dingley spoke thusly

Richard is our local pet idiot. Just ignore him.

ok.. thanks for that

As for a parameterised include(), then it's _very_ dangerous. I'm not
a PHP geek, or even a Unix/Apache guru, so my surprise that it's
hazardous to _other_ virtual users might be unwarranted. It's
certainly hazardous to _your_ site though, so avoid it anyway.

hmm it's not per se dangerous... I just ignored some basic facts about
securing the handling of parameter values.

Don't do it. Dynamic stuff like this bumps up the server load
massively and doesn't add any useful benefit.

why is that? it doesn't put any load to my server here as it's just a
parameter handed over via URL. something very common.

If you're serving static

content, then leave it static. If you need to include shared menus
etc., include the static portion from within the varying content
pages, don't try to put the varying part in the static, as you're
doing here.

it helped a lot keeping the maintanance of the site on a very low
profile. the advantage is: you have just one index.php file handling
everything, and the customer can add any content to his site he wants
without having to deal with menu, navigation and layout issues... the
only file he has to touch is the content file, which is just a simple
text file he can upload via FTP. no big deal and he likes this approach
very much. formatting is then done via PHP. take it as some sort of a
very reduced CMS.

Don't do "cute stuff" in general. If it was useful, we'd all be doing
it.

include() or better fopen() aren't 'cute stuff'. these are just quite
common functions and help to minimise bandwith and server load, as file
handling is reduced on the server side.


bernhard

 

[Andy Dingley]

why is that? it doesn't put any load to my server here as it's just a
parameter handed over via URL. something very common.

It screws up any attempt by the server (or the network) to cache
pages. If you use the server's own SSI it can generally integrate
this to its cache.

 

[Bernhard Sturm]

On 1/7/2005 1:24 PM Andy Dingley spoke thusly

It screws up any attempt by the server (or the network) to cache
pages. If you use the server's own SSI it can generally integrate
this to its cache.

but that's rhe case with almost every dynamically generated site so
nothing new.
look at the site as content is being fed from a flatfile db... here you go.

bernhard

 

[Andy Dingley]

but that's rhe case with almost every dynamically generated site

True, but unnecessary - it's bad coding, not necessity.

Dynamically generated pages should set their headers to indicate the
acceptability of caching, as appropriate. "Dynamically generated"
doesn't always mean "dynamic content". If the content is stable and
deterministic for a given URL and set of parameters, then the results
are cacheable, even if they're generated by a script. A catalogue
page with parameters may be stable, a view-shopping-basket page might
vary on almost every request, despite not even taking parameters.

In the caase of static includes like this, then the pages are very
stable and should be cacheable. If you use the server's own include
mechanism it can track this and cache the merged version in a very
efficient manner.