Hacked? How does appending a filename allow access to data on site... see example

Solution 1:

In the includes/application_top which gets included by all the scripts in /admin you'll find this little gem (I have thrown some uninteresting parts out):

// redirect to login page if administrator is not yet logged in
if (!tep_session_is_registered('admin')) {
    $redirect = false;

    $current_page = basename($PHP_SELF);

    if ($current_page != FILENAME_LOGIN) {
        // session stuf blabla
        $redirect = true;
    }

    if ($redirect == true) {
        tep_redirect(tep_href_link(FILENAME_LOGIN));
    }

    unset($redirect);
}

This code gets only executed when you are not logged in. What it basically does is check if the basename of $PHP_SELF is login.php. If it is login.php then it proceeds rendering the page, otherwise you will be redirected.

If you make this request:

http://mysite.com/admin/configuration.php/login.php

Then the PHP_SELF will be

/admin/configuration.php/login.php

And basename($PHP_SELF) will of course be login.php thus the rendering continues and no redirect is executed. But it is of course not login.php which gets rendered but configuration.php. The rest of the URL "/login.php" is "ignored" and just supplied to PHP in $_SERVER['PATH_INFO'].

Edit: I like to add that this "bug" affects only oscommerce or any other software that uses a solution like that to "secure" the administration login (I think there aren't that many which suffer from this). It is not a bug which affects all PHP-software.

Solution 2:

This is simply a vulnerability in the configuration.php file - the 'fake directory' thing with a php file as part of the path is an intentional feature and something that you'll see often - how the stuff after the slash is handled is up to the php file in the path. (mediawiki comes to mind as a good example)

Solution 3:

I have tried this on a windows box, to use a double url as indicated - it says page not found. But the server is set not to allow directory transversals and OSCommerce is set to check user agent and prevent spider sessions as well as use a sessions directory - possibly this is why it is secure and does not allow appending a url. Additionally, the server treats the /login.php as part of the first filename, does not allow driectory transversals and does not allow dot in a filename - hence it refuses the url entirely. Therfore secure because the server is secure regardless of what the catalog software tries to do.