#1
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2007
    Posts
    233
    Rep Power
    8

    Restrict all users in backend from direct typing


    How can I restrict all users in de backend (even super-admin) from typing the id of any user to display their info.

    For example:

    In de backend I (super-admin) edit my own data, in the address bar my own id is visible, when I type in the id of any other user, their info gets displayed, this is something I want to restrict (display a message).

    I use $_session['level'] (this is a database user defined level) to grand or restrict certain areas on the backend, but the direct typing doesn't stop it.

    How can I do this?

    Thanks
  2. #2
  3. Jealous Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,302
    Rep Power
    9400
    In case you were thinking it, you don't prevent them from going to the page. From playing with the URL. You can't stop that.

    But you can simply not show the information. Current user X isn't allowed to see information for user Y? Then don't show it. A simple "access denied" message might even be enough.
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2007
    Posts
    233
    Rep Power
    8
    Originally Posted by requinix
    In case you were thinking it, you don't prevent them from going to the page. From playing with the URL. You can't stop that.

    But you can simply not show the information. Current user X isn't allowed to see information for user Y? Then don't show it. A simple "access denied" message might even be enough.
    Well I actually thought of that, but then I need to store (I think) the user id into a session and match that with the id in the url, but I thought that storing the id into a session is not recommended even if it's safer than a cookie.

    If I am wrong, please correct me about this?
  6. #4
  7. Jealous Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,302
    Rep Power
    9400
    For a basic login system to work you need to put some information about the user in the session. Typically that's the username or ID. It's perfectly fine to store that.

    If the user is only allowed to view their own info then why are you putting the ID in the URL to begin with? It should be a simple page like "/profile.php" which displays the information for the user viewing the page. No ID.
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2007
    Posts
    233
    Rep Power
    8
    Originally Posted by requinix
    If the user is only allowed to view their own info then why are you putting the ID in the URL to begin with? It should be a simple page like "/profile.php" which displays the information for the user viewing the page. No ID.
    Let me explain a little here:
    The website I work on has a backend on where the super-admin and moderator have a part that they can add, edit or delete users.
    For them all the users are visible in a table, when they click on a user, they can view their details and that is where the id comes in. Then with $_GET, I use it to display the users details with a query. I know that $_POST does exists and that that is used to "hide" or not show in the url, but that works only in a form, right?

    BTW, the view details link (when clicked on a user) contains the userid.

    If there is another solution, please share.
  10. #6
  11. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Hi,

    what requinix said is this: When any user is only allowed to view his/her own details, then it's useless to explicitly pass the user ID to the details page. Because there's only one valid ID, namely the ID of the current user (stored in the session).

    What's the point of letting the user run into restricted pages all the time? Simply remove the URL parameter and fetch the ID from the session.

    So, yes, store the user ID in the session. Why do you think this is more dangerous than storing the level? I mean, when the session gets "stolen", it's equally bad in both cases.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2007
    Posts
    233
    Rep Power
    8
    Originally Posted by Jacques1
    What's the point of letting the user run into restricted pages all the time? Simply remove the URL parameter and fetch the ID from the session.
    Ok, I will use the session to store the id, but then I still have the problem that when I am logged in as super-admin, and I display the page containing all the users, how can I edit a user when I don't use the userid as variable in the url, that id is not stored in a session, it's just displayed in a table on the page?
  14. #8
  15. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    I'm a bit confused ...

    So admins/moderators are not supposed to see the details of other users, but they can still edit those users? How does that work? Are the user details and the editing logic on the same page?
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2007
    Posts
    233
    Rep Power
    8
    Originally Posted by Jacques1
    I'm a bit confused ...

    So admins/moderators are not supposed to see the details of other users, but they can still edit those users? How does that work? Are the user details and the editing logic on the same page?
    Let me explain:

    The admins/moderators can see the user details and edit them if needed, but the moderators cannot display/edit the admin details, the other way around, the admins can display/edit the moderators details.

    I have a page (users.php), which shows a table containing all the users. That table also contains a column with edit buttons (each per row). When I click on a edit button, the url looks like this:
    edit_user.php?userid=3

    Now the point is when a admin is logged in, all the users are visible in the table, but when a moderator is logged in, all users EXCEPT the admin(s) are visible.
    When clicked on the edit button, the moderator can still (if known) change the userid in the url to the id of an admin.
    Eventhough the admin was not visible for the moderator in the table, he/she can still get the info by simply changing the userid in the url.

    My quess is, that I need to check if a moderator is logged in, that the userid is not of an admin. If so a message is display, if not he/she can continue.

    Hope I make some sense now.
  18. #10
  19. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    OK, you didn't say that only admins should be excluded when the current user is a moderator.

    In this case, you have to keep the URL parameter, of course. Then you check for this:
    Code:
    if target_user.role != 'admin' or current_user.role == 'admin':
    	// display user details
    No user except an admin can view admins.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  20. #11
  21. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2007
    Posts
    233
    Rep Power
    8
    Originally Posted by Jacques1
    OK, you didn't say that only admins should be excluded when the current user is a moderator.

    In this case, you have to keep the URL parameter, of course. Then you check for this:
    Code:
    if target_user.role != 'admin' or current_user.role == 'admin':
    	// display user details
    No user except an admin can view admins.
    Sorry I didn't said it, my mistake.

    Here is how I solved it, as far as I can see it works (the code is almost at the top of the edit_user.php page):
    PHP Code:
    $CheckPerm false;
    $result $users->adminid('Super-Admin');
    if (
    $_GET['user'] === $result->id) {
        if (
    $_SESSION['level'] !== 'Super-admin') {
            
    $message "U heeft niet de juiste rechten voor deze handeling!";
            
    $CheckPerm false;
        }else{
            
    $CheckPerm true;
        }
    }else{
        
    $CheckPerm true;

    This row:
    PHP Code:
    $result $users->adminid('Super-Admin'); 
    and especially the adminid is a function that checks the id for the Super-Admin, if that id is identical to the $_GET id, it than checks if the current user is the moderator, if so, that the variable $CheckPerm is set to false (by default also), if not it's set to true.

    Now in the html code above the form (where the details should be placed), I placed the following code:
    PHP Code:
    <?php if($CheckPerm == true){ ?>

    <?php } else {} ?>
    This works for me.
  22. #12
  23. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    The code is correct as far as I can tell.

    However, you can make it a lot simpler if you use the check I suggested:
    PHP Code:
    $sadmin_id $users->adminid('Super-Admin')->id;
    $CheckPerm $_GET['user'] !== $sadmin_id || $_SESSION['level'] === 'Super-admin';    // Super Admin can only be seen by Super Admin himself 
    And the "== true" in "if ($CheckPerm == true)" is useless. It does nothing more than "if ($CheckPerm)". A boolean already is either true or false, it doesn't get "truer" or "falser" by comparing it.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".
  24. #13
  25. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Mar 2007
    Posts
    233
    Rep Power
    8
    Originally Posted by Jacques1
    However, you can make it a lot simpler if you use the check I suggested:
    PHP Code:
    $sadmin_id $users->adminid('Super-Admin')->id;
    $CheckPerm $_GET['user'] !== $sadmin_id || $_SESSION['level'] === 'Super-admin';    // Super Admin can only be seen by Super Admin himself 
    And the "== true" in "if ($CheckPerm == true)" is useless. It does nothing more than "if ($CheckPerm)". A boolean already is either true or false, it doesn't get "truer" or "falser" by comparing it.
    Thanks worked like a charm.

IMN logo majestic logo threadwatch logo seochat tools logo