Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1553 Wiki : URL case-hacking goes back to global permissions

v1.8.3
closed-fixed
mose
Security (29)
7
2004-07-16
2004-07-13
Ben Breslauer
No

It is possible to view tiki pages for which someone is
denied view permissions by going to the address bar and
changing the case of any letter in the page name. For
example, if there is a page

http://www.somewhere.com/tiki/tiki-index.php?page=PermissionTest

for which a user is not allowed to view, per the
permissions set on the page via tiki, they can still
view the page by typing

http://www.somewhere.com/tiki/tiki-index.php?page=permissionTest

or by changing the case on any of the letters in the
page name.

Discussion

  • Ben Breslauer
    Ben Breslauer
    2004-07-13

    • priority: 5 --> 7
     
    • milestone: --> v1.8.3
    • summary: Some Permissions can be overridden --> Wiki : Some Permissions can be overridden
    • status: open --> open-accepted
     
  • Logged In: YES
    user_id=738765

    Dooh...I'll hopefully fix that soon.

     
  • mose
    mose
    2004-07-16

    • assigned_to: nobody --> mose
    • status: open-accepted --> closed-fixed
     
  • mose
    mose
    2004-07-16

    Logged In: YES
    user_id=8021

    Thanks for reporting, I fixed it. Now wiki page names are
    case-senstive to avoid such surprises. Next 1.8 version will
    include that change.

    quick patch : line 3453 in lib/tikilib.php
    change
    $query = "select * from `tiki_pages` where `pageName`=?";
    by
    $query = "select * from `tiki_pages` where
    ".$this->convert_binary()." `pageName`=?";
    that make it case sensitive.

    mose

     
    • assigned_to: mose --> nobody
    • summary: Wiki : Some Permissions can be overridden --> Wiki : URL case-hacking goes back to global permissions
    • status: closed-fixed --> open-accepted
     
  • Logged In: YES
    user_id=738765

    Fortunately, the severity is much lower than what I
    initially feared, but it's still an important Wiki bug.
    What this too simple trick allows to do is to go back to
    global permissions. Two cases appear. In one, the user is
    denied access to a more permissive page if the link has the
    wrong case. The more problematic case is the one you spotted.

    I started working on a fix but still need to check more stuff.
    The basic fix is to put
    $info = $tikilib->get_page_info($page);
    and
    $page = $info['pageName'];
    BEFORE
    require_once('tiki-pagesetup.php');
    in tiki-index.php...and a number of other places. I am
    currently checking some of those other places, there are
    many. They can be easily found using
    grep tiki-pagesetup.php tiki/*

    A more robust fix would just require a change to
    tiki-pagesetup.php to make it lowercase all pages before a
    check is done. The get_page_info query works
    case-insensitive because the SQL field for name is, but the
    problem is that in tiki-pagesetup.php
    object_has_one_permission() there is a md5 of the page's
    name and object type which makes the final DB value
    case-sensitive. Although fixing the bug for new installs is
    easy, fixing for existing installs requires to modify a md5,
    which I think can't be done without running a PHP or at
    least SQL patch.

     
  • Logged In: YES
    user_id=738765

    Oops...a problem with mose's solution is that all links to
    the page that don't match case will be broken.

    Less severe problems are left, as the possibility for
    someone with global tiki_p_remove to remove a protected page
    through tiki-removepage.php.

     
  • Logged In: YES
    user_id=738765

    (Restoring bug characteristics changes)

     
    • assigned_to: nobody --> mose
    • status: open-accepted --> closed-fixed
     
  • Logged In: YES
    user_id=738765

    I applied what I did despite mose's fix, but he says
    case-insensitivity is a 1.8 bug (due to DB abstraction)
    anyway, so it shouldn't be necessary.