SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    SitePoint Enthusiast
    Join Date
    Jun 2011
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Is it a security risk if webusers know the name of a variable or array?

    For example, if one of your variables is $address. I don't know what the risk is here. I would prefer my code be readable (for my own sake) and that variable names be as simple as possible.

  2. #2
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Generally no - while obscurity (in this case making hard to guess variable names) can be used as an additional hurdle for potential attacker, one should not rely on it as a means of security protection.
    In context of variable naming - the benefits of having readable code far outweigh the benefits of obscurity.

  3. #3
    SitePoint Enthusiast
    Join Date
    Jun 2011
    Posts
    38
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks

  4. #4
    SitePoint Enthusiast
    Join Date
    May 2011
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Exclamation

    Quote Originally Posted by Aleksejs View Post
    Generally no - while obscurity (in this case making hard to guess variable names) can be used as an additional hurdle for potential attacker, one should not rely on it as a means of security protection.
    In context of variable naming - the benefits of having readable code far outweigh the benefits of obscurity.
    Yes, I agree with you. Knowing the name of the variable does not lead to any security issues. But knowing the database information such table names, field names and so on, are dangerous can be injected easily(SQL Injection) if you coding is not secure.

  5. #5
    From Italy with love silver trophybronze trophy
    guido2004's Avatar
    Join Date
    Sep 2004
    Posts
    9,506
    Mentioned
    163 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by SPMuthu View Post
    Yes, I agree with you. Knowing the name of the variable does not lead to any security issues.
    It could if you have register_globals ON. But of course you shouldn't, so if you do, set it to OFF.

  6. #6
    SitePoint Enthusiast
    Join Date
    May 2011
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by guido2004 View Post
    It could if you have register_globals ON. But of course you shouldn't, so if you do, set it to OFF.
    Sorry, I cannot understand what you mean. Can you please explain in detail.
    You mean possibility of security issues is high because of making the register_globals ON. Please explain.

  7. #7
    From Italy with love silver trophybronze trophy
    guido2004's Avatar
    Join Date
    Sep 2004
    Posts
    9,506
    Mentioned
    163 Post(s)
    Tagged
    4 Thread(s)
    Did you read the page I linked to? It's explained there.

  8. #8
    SitePoint Enthusiast
    Join Date
    May 2011
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Yes, I did visit, But i cannot understand and it is first time that i'm hearing register_globals. Actually i'm new to php and started to learn just 2 months before. I don't have deep knowledge on it. I think i've to refer more to understand that. At present what i understand from that is, it is like a global variable that can be ON or OFF. Thanks anyway. I'll try to understand by referring more. If you can tell in simple words, then yes you can.
    Thanks in advance.

  9. #9
    secure webapps for all Aleksejs's Avatar
    Join Date
    Apr 2008
    Location
    Riga, Latvia
    Posts
    755
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    in simple words:
    if register_globals is on, then accessing page page.php?variable=value
    automatically creates $variable as well as $_GET['variable'] and $_REQUEST['variable']
    on other hand, if register_globals is off the same would only generate:
    $_GET['variable'] $_REQUEST['variable']

    so if your code were:
    Code:
    if($authenticated){//$authenticated gets set at some point by access control code.
    //do authenticated stuff
    }
    then this logic could be exploited by person specifying page.php?authenticated=true

    Also - good points on register_globals and table/field names - however it certainly would be poor coding if knowing them would mean that something could be exploited. Obscurity buys you time and rings warning bells (by appearing of unsuccessful guesswork tries in log files) and should not be overlooked, but taken to advantage.

    In summary: Your security should not rely on these things being unknown, however it also means that you should not be "advertising" all your variable/file/table/field names to world.

  10. #10
    From Italy with love silver trophybronze trophy
    guido2004's Avatar
    Join Date
    Sep 2004
    Posts
    9,506
    Mentioned
    163 Post(s)
    Tagged
    4 Thread(s)
    Let's take the first example from the page I linked to:
    PHP Code:
    <?php
    // define $authorized = true only if user is authenticated
    if (authenticated_user()) {
        
    $authorized true;
    }

    // Because we didn't first initialize $authorized as false, this might be
    // defined through register_globals, like from GET auth.php?authorized=1
    // So, anyone can be seen as authenticated!
    if ($authorized) {
        include 
    "/highly/sensitive/data.php";
    }
    ?>
    Now I could go use the query string to send a variable $authorized to your script:
    Code:
    http://www.yoursite.com/index.php?authorized=1
    With register_globals OFF, that would have no effect, because the value I put in the query string would be only accessible through $_GET['authorized'].
    With register_globals ON, php automatically creates a variable called $authorized with value 1. Which means that even if I didn't authenticate, $authorized still has value 1, which means it will enter the second if and display the highly sensitive info.

  11. #11
    SitePoint Enthusiast
    Join Date
    May 2011
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Fine, Got some idea. Thanks Aleksejs and guido

  12. #12
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,184
    Mentioned
    17 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by guido2004
    With register_globals OFF, that would have no effect, because the value I put in the query string would be only accessible through $_GET['authorized'].
    With register_globals ON, php automatically creates a variable called $authorized with value 1. Which means that even if I didn't authenticate, $authorized still has value 1, which means it will enter the second if and display the highly sensitive info.
    People should be initializing their variables properly in the first place and it would be a none issue, but that said I agree – register globals is evil!

    PHP Code:

    <?php
    $authorized 
    false// always assume person is not authorized

    // define $authorized = true only if user is authenticated

    if (authenticated_user()) {

        
    $authorized true;

    }



    // Because we didn't first initialize $authorized as false, this might be

    // defined through register_globals, like from GET auth.php?authorized=1

    // So, anyone can be seen as authenticated!

    if ($authorized) {

        include 
    "/highly/sensitive/data.php";

    }

    ?>
    The only code I hate more than my own is everyone else's.

  13. #13
    From Italy with love silver trophybronze trophy
    guido2004's Avatar
    Join Date
    Sep 2004
    Posts
    9,506
    Mentioned
    163 Post(s)
    Tagged
    4 Thread(s)
    Quote Originally Posted by oddz View Post
    People should be initializing their variables properly in the first place and it would be a none issue,
    Of course. But without register globals its a none issue even if you forget to initialise one (which could happen since PHP doesn't force you to).
    but that said I agree register globals is evil!
    Indeed

  14. #14
    SitePoint Zealot LinuxFreelancer's Avatar
    Join Date
    Jun 2011
    Location
    Boston, Ma, Usa
    Posts
    116
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    As long as you intitialize, validate and clean you are good. Don't worry learning about register globals, just initialize right like so:

    PHP Code:
    if (empty($_POST['foobar'])) {
     die(
    'Go back and get some foobar!');
    } else {
     
    $foobar trim(htmlspecialchars(strip_tags($_POST['foobar'])));
    }
    echo 
    $foobar
    If that varaible is being used with a SQL query be sure to use at minimum, mysql_real_escape_string(). Don't use addslashes().... ever.

    Also see: http://php.net/manual/en/book.filter.php

  15. #15
    I solve practical problems. bronze trophy
    Michael Morris's Avatar
    Join Date
    Jan 2008
    Location
    Knoxville TN
    Posts
    2,053
    Mentioned
    66 Post(s)
    Tagged
    0 Thread(s)
    If you don't know about register globals it's likely turned off on your server. PHP 5.4 will be removing the functionality for good.

  16. #16
    SitePoint Wizard bronze trophy Immerse's Avatar
    Join Date
    Mar 2006
    Location
    Netherlands
    Posts
    1,661
    Mentioned
    7 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Michael Morris View Post
    PHP 5.4 will be removing the functionality for good.
    Off Topic:


    Standing ovation for PHP 5.4!


Bookmarks

Posting Permissions

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