Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 10 of 10
  1. #1
    Regular Coder
    Join Date
    Feb 2007
    Location
    London
    Posts
    225
    Thanks
    16
    Thanked 2 Times in 2 Posts

    Basic security question - URL tampering

    I'm slightly confused by some info I just read that was probably completely wrong, but I've become paranoid now, so I'm hoping someone will put my mind at rest with a simple yes/no answer to the following... :-)

    If I have the code:

    PHP Code:
    $_SESSION['logged_in'] = "no";
    if (
    $logged_in == "yes") {
       
    carry out something sensitive

    and then someone appends to the URL:

    Code:
    ?logged_in=yes
    there's no way that $logged_in could ever return "yes" unless I GET the variable, right?

    I'm anticipating an "Of course, not!", but just wanna be sure I understand this correctly.

    Thanks.
    Last edited by cfructose; 08-05-2007 at 08:46 PM. Reason: typo

  • #2
    New to the CF scene
    Join Date
    Aug 2007
    Posts
    3
    Thanks
    0
    Thanked 0 Times in 0 Posts
    In PHP 3 of earlier, it was possible like this. This was solved somewhere in PHP 4, as far as I know.

  • #3
    Regular Coder croatiankid's Avatar
    Join Date
    Jan 2006
    Posts
    665
    Thanks
    1
    Thanked 12 Times in 12 Posts
    This is (AFAIK) because of register_globals set to on. It's off by default in new php 4.x installations, and you can't turn it on (again, AFAIK) in php 5.x. The solution would be to either use
    PHP Code:
    $_SESSION['logged_in'] = "no";
    if (
    $_SESSION['logged_in'] == "yes") {
       
    carry out something sensitive

    or, what is simpler (especially if your using the variable more than once), creating the variable yourself:
    PHP Code:
    $_SESSION['logged_in']$_SESSION['logged_in'] = "no";
    $logged_in $_SESSION['logged_in']
    #created the variable yourself from the $_SESSION array
    if ($logged_in == "yes") {
       
    carry out something sensitive


  • #4
    Senior Coder CFMaBiSmAd's Avatar
    Join Date
    Oct 2006
    Location
    Denver, Colorado USA
    Posts
    3,092
    Thanks
    2
    Thanked 322 Times in 314 Posts
    When register_globals are enabled, the parameter on the end of the url will cause the $logged_in variable in the program to be set to "yes", which is the whole security problem with register_globals.

    The problem is only present on web servers where register_globals are enabled. You should specifically disable register_globals in php.ini (if this is your server) or a .htaccess file to avoid the possibility of variables having their value changeable from outside of your code.

    Because the session variable shares the same name, it too will overwrite the $logged_in variable in some cases (just verified on my test server) -

    Specifically, if the get parameter is not present on the url on the first visit to the page, the session variable will be created and the register global setting will cause the $logged_in variable to refer to the session variable with the same name. If you then refresh the page with the get parameter on the end of the url, the $logged_in variable will retain the value of the session variable.

    However, if the get parameter is present on the url on the first visit to the page, the $logged_in variable will already have been created and refer to the $_GET variable with the same name and the session variable won't overwrite it on that page visit. If you then refresh the page, with or without the get parameter on the url, the $logged_in variable will again refer to the session variable with that same name.

    Anyone trying this, don't forget to add a session_start() statement to the code in the first post to get the sessions to work.

    Edit:
    Edit: Register_globals are not on by default in PHP5.x. Any documentation or statement to that effect is in error. The whole register_globals setting and any side effect from it have been removed in PHP6 - for security reasons and the problem of having different global variables ($_POST/$_GET/$_COOKIE/$_SESSION) being overwritten by other variables with the same name.
    Last edited by CFMaBiSmAd; 08-05-2007 at 10:03 PM.
    If you are learning PHP, developing PHP code, or debugging PHP code, do yourself a favor and check your web server log for errors and/or turn on full PHP error reporting in php.ini or in a .htaccess file to get PHP to help you.

  • #5
    Regular Coder
    Join Date
    Feb 2007
    Location
    London
    Posts
    225
    Thanks
    16
    Thanked 2 Times in 2 Posts
    Thanks guys,

    So, given that I'm using php5, there's no problem, right? I don't need to take any other precautions (as Croatiankid suggested)?

  • #6
    Senior Coder CFMaBiSmAd's Avatar
    Join Date
    Oct 2006
    Location
    Denver, Colorado USA
    Posts
    3,092
    Thanks
    2
    Thanked 322 Times in 314 Posts
    Check the actual setting for register_globals on your server. If it is a shared host, they likely turned it on to allow older scripts to continue to function.
    If you are learning PHP, developing PHP code, or debugging PHP code, do yourself a favor and check your web server log for errors and/or turn on full PHP error reporting in php.ini or in a .htaccess file to get PHP to help you.

  • #7
    Regular Coder
    Join Date
    Feb 2007
    Location
    London
    Posts
    225
    Thanks
    16
    Thanked 2 Times in 2 Posts
    Blimey! I'm glad I asked again... shared host AAAARGH! That's what I've got.
    OK, I'll check.

  • #8
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    Most decent web hosting services have register_globals disabled on shared hosting because of the security issue. A lot of them will not allow it to be turned on unless certain other criteria is met since enabling two or three other things that introduce security holes at the same time can compromise the entire server.

    Fixing old (pre PHP 4.2) scripts to work with it disabled is trivial so any script that wasn't patched for this several years ago most likely has many other security holes in it as well if the authors can't be bothered to add the extra few lines of code needed to resolve that issue.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #9
    Regular Coder
    Join Date
    Feb 2007
    Location
    London
    Posts
    225
    Thanks
    16
    Thanked 2 Times in 2 Posts
    I'm with HostGator, who, to my surprise, just confirmed that register globals are ON by default.

    Does it make any difference if I turn it off with php.ini or htaccess?
    Is one preferable for some reason?

    If with htaccess, I just add:

    php_flag register_globals off
    right?

    (Incidentally, does it matter where in the htacces file I put it?)
    Last edited by cfructose; 08-05-2007 at 11:34 PM. Reason: Adding more info

  • #10
    Regular Coder meth's Avatar
    Join Date
    Jan 2003
    Posts
    262
    Thanks
    0
    Thanked 9 Times in 9 Posts
    "Fixing old (pre PHP 4.2) scripts to work with it disabled is trivial".

    I wouldn't make such generalisations. Some of the trickiest scripts to convert are ones that were written to work with register_globals off, but developed or modified on systems with it on.

    So in order to catch the undeclared var, you have to load each script in all its modes of operation or have enormous powers of concentration while reading the scripts through. In the past I've come across 2 apps with register_globals holes and were a pain in the 455 to convert. These scripts had many vars whose values were get, post or session values depending on the mode of operation - php torture.
    I do Web Design, Brisbane based.
    More time spent in PHP/MySQL Web Development.
    And Search Engine Optimisation takes up the rest of it.


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •