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
     
    Bernhard Sturm, Jan 6, 2005
    #1
    1. Advertisements

  2. Bernhard Sturm

    rf Guest

    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?
     
    rf, Jan 6, 2005
    #2
    1. Advertisements

  3. 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.
    anywhere :)
    multiposting is not allowed in NG? (I did not cross-post).

    bernhard
     
    Bernhard Sturm, Jan 6, 2005
    #3
  4. Bernhard Sturm

    rf Guest

    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.

    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.
    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.
     
    rf, Jan 6, 2005
    #4
  5. Bernhard Sturm

    SpaceGirl Guest

    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
    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
    okay.. thanks.. I always thought cross-posting was frowned upon (I did
    it once, and got flamed...)


    bernhard
     
    Bernhard Sturm, Jan 6, 2005
    #6
  7. Bernhard Sturm

    Neal Guest

    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. 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
     
    Bernhard Sturm, Jan 6, 2005
    #8

  9. 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 Silverman, Jan 6, 2005
    #9

  10. 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
     
    Bernhard Sturm, Jan 6, 2005
    #10
  11. Bernhard Sturm

    Richard Guest

    "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
    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
     
    Bernhard Sturm, Jan 6, 2005
    #12
  13. 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 Jenkins, Jan 6, 2005
    #13
  14. Bernhard Sturm

    Andy Dingley Guest

    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.
     
    Andy Dingley, Jan 6, 2005
    #14
  15. On 1/7/2005 12:12 AM Andy Dingley spoke thusly
    ok.. thanks for that :)
    hmm it's not per se dangerous... I just ignored some basic facts about
    securing the handling of parameter values.
    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
    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.
    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
     
    Bernhard Sturm, Jan 7, 2005
    #15
  16. Bernhard Sturm

    Andy Dingley Guest

    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
    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
     
    Bernhard Sturm, Jan 7, 2005
    #17
  18. Bernhard Sturm

    Andy Dingley Guest

    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.
     
    Andy Dingley, Jan 7, 2005
    #18
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.