Virtual Server vulnerability through URL parameters?

Discussion in 'HTML' started by Bernhard Sturm, Jan 6, 2005.

  1. 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
    --
    www.daszeichen.ch
    remove nixspam to reply
     
    Bernhard Sturm, Jan 6, 2005
    #1
    1. Advertising

  2. Bernhard Sturm

    rf Guest

    "Bernhard Sturm" <> wrote

    > 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?

    --
    Cheers
    Richard.
     
    rf, Jan 6, 2005
    #2
    1. Advertising

  3. On 1/6/2005 2:59 PM rf spoke thusly
    > "Bernhard Sturm" <> wrote
    >
    >
    >>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.


    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
    --
    www.daszeichen.ch
    remove nixspam to reply
     
    Bernhard Sturm, Jan 6, 2005
    #3
  4. Bernhard Sturm

    rf Guest

    "Bernhard Sturm" <> wrote

    > On 1/6/2005 2:59 PM rf spoke thusly
    > > "Bernhard Sturm" <> wrote
    > >
    > >>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.

    >
    > 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?

    > > Where do you want your answer?

    >
    > 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.

    --
    Cheers
    Richard.
     
    rf, Jan 6, 2005
    #4
  5. Bernhard Sturm

    SpaceGirl Guest

    rf wrote:
    > "Bernhard Sturm" <> wrote
    >
    >
    >>On 1/6/2005 2:59 PM rf spoke thusly
    >>
    >>>"Bernhard Sturm" <> wrote
    >>>
    >>>
    >>>>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.

    >>
    >>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?
    >
    >
    >>>Where do you want your answer?

    >>
    >>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.


    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 :p

    --


    x theSpaceGirl (miranda)

    # lead designer @ http://www.dhnewmedia.com #
    # remove NO SPAM to email, or use form on website #
     
    SpaceGirl, Jan 6, 2005
    #5
  6. On 1/6/2005 3:26 PM rf spoke thusly
    > "Bernhard Sturm" <> wrote
    >
    >
    >>On 1/6/2005 2:59 PM rf spoke thusly
    >>
    >>>"Bernhard Sturm" <> wrote
    >>>
    >>>
    >>>>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.

    >>
    >>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?
    >
    >
    >>>Where do you want your answer?

    >>
    >>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.


    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
    --
    www.daszeichen.ch
    remove nixspam to reply
     
    Bernhard Sturm, Jan 6, 2005
    #6
  7. Bernhard Sturm

    Neal Guest

    Bernhard Sturm <> wrote:


    > 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.
     
    Neal, Jan 6, 2005
    #7
  8. On 1/6/2005 3:54 PM Neal spoke thusly
    > Bernhard Sturm <> wrote:
    >
    >
    >> 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.


    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
    --
    www.daszeichen.ch
    remove nixspam to reply
     
    Bernhard Sturm, Jan 6, 2005
    #8
  9. On Thu, 06 Jan 2005 14:50:07 +0100, Bernhard Sturm wrote:

    > 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.

    --
    Jeffrey D. Silverman |
    Website | http://www.newtnotes.com

    Drop "PANTS" to reply by email
     
    Jeffrey Silverman, Jan 6, 2005
    #9
  10. On 1/6/2005 4:24 PM Jeffrey Silverman spoke thusly
    > On Thu, 06 Jan 2005 14:50:07 +0100, Bernhard Sturm wrote:
    >
    >
    >>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.


    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
    --
    www.daszeichen.ch
    remove nixspam to reply
     
    Bernhard Sturm, Jan 6, 2005
    #10
  11. Bernhard Sturm

    Richard Guest

    On Thu, 06 Jan 2005 14:50:07 +0100 Bernhard Sturm wrote:

    > 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.:


    <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


    "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.
     
    Richard, Jan 6, 2005
    #11
  12. 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
    --
    www.daszeichen.ch
    remove nixspam to reply
     
    Bernhard Sturm, Jan 6, 2005
    #12
  13. In article <>, Anonymous@127.001 says...
    > 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.

    --
    Hywel http://kibo.org.uk/
    I do not eat quiche.
     
    Hywel Jenkins, Jan 6, 2005
    #13
  14. Bernhard Sturm

    Andy Dingley Guest

    On Thu, 06 Jan 2005 22:58:52 +0100, Bernhard Sturm
    <> wrote:

    >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.
    --
    Die Gotterspammerung - Junkmail of the Gods
     
    Andy Dingley, Jan 6, 2005
    #14
  15. On 1/7/2005 12:12 AM Andy Dingley spoke thusly
    > On Thu, 06 Jan 2005 22:58:52 +0100, Bernhard Sturm
    > <> wrote:
    >
    >
    >>humm to what exactly are you refering to?

    >
    >
    > 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
    --
    www.daszeichen.ch
    remove nixspam to reply
     
    Bernhard Sturm, Jan 7, 2005
    #15
  16. Bernhard Sturm

    Andy Dingley Guest

    On Fri, 07 Jan 2005 12:08:55 +0100, Bernhard Sturm
    <> wrote:

    >> 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.


    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.
     
    Andy Dingley, Jan 7, 2005
    #16
  17. On 1/7/2005 1:24 PM Andy Dingley spoke thusly
    > On Fri, 07 Jan 2005 12:08:55 +0100, Bernhard Sturm
    > <> wrote:
    >
    >
    >>>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.

    >
    >
    > 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
    --
    www.daszeichen.ch
    remove nixspam to reply
     
    Bernhard Sturm, Jan 7, 2005
    #17
  18. Bernhard Sturm

    Andy Dingley Guest

    On Fri, 07 Jan 2005 14:10:01 +0100, Bernhard Sturm
    <> wrote:

    >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.

    --
    Smert' spamionam
     
    Andy Dingley, Jan 7, 2005
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jon paugh
    Replies:
    1
    Views:
    758
  2. =?Utf-8?B?R3JlZyBIdXJsbWFu?=

    Massive ASP.Net Forms Authentication vulnerability

    =?Utf-8?B?R3JlZyBIdXJsbWFu?=, Sep 30, 2004, in forum: ASP .Net
    Replies:
    12
    Views:
    755
    Tom Kaminski [MVP]
    Oct 6, 2004
  3. Ken Dopierala Jr.
    Replies:
    0
    Views:
    365
    Ken Dopierala Jr.
    Oct 1, 2004
  4. Andrea

    GREAT VULNERABILITY in MY SERVER

    Andrea, Dec 9, 2013, in forum: ASP .Net
    Replies:
    0
    Views:
    373
    Andrea
    Dec 9, 2013
  5. Andrea

    GREAT VULNERABILITY in MY SERVER

    Andrea, Dec 9, 2013, in forum: ASP .Net Security
    Replies:
    0
    Views:
    427
    Andrea
    Dec 9, 2013
Loading...

Share This Page