From b70ce1223a6e0328c1d8c28c108ce5c183877122 Mon Sep 17 00:00:00 2001 From: Philip Olson Date: Fri, 16 May 2003 21:45:36 +0000 Subject: [PATCH] A complete rewrite of security.registerglobals to contain more information and not make register_globals look so bad :) git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@127357 c90b9560-bf6c-de11-be94-00142212c4b1 --- chapters/security.xml | 136 ++++++++++++++++++++++++++++++------------ security/index.xml | 136 ++++++++++++++++++++++++++++++------------ 2 files changed, 194 insertions(+), 78 deletions(-) diff --git a/chapters/security.xml b/chapters/security.xml index 24bb489348..fc367ec38f 100644 --- a/chapters/security.xml +++ b/chapters/security.xml @@ -1,5 +1,5 @@ - + Security @@ -1023,80 +1023,138 @@ if ($good_login == 1) { // If above test fails, not initialized or checked befor Using Register Globals - One feature of PHP that can be used to enhance security is configuring PHP with - register_globals = off. - By turning off the ability for any user-submitted variable to be injected - into PHP code, you can reduce the amount of variable - poisoning a potential attacker may inflict. They will have - to take the additional time to forge submissions, and your - internal variables are effectively isolated from user - submitted data. + Perhaps the most controversial change in PHP is when the default value + for the PHP directive + register_globals went from ON to OFF in PHP + 4.2.0. Reliance on this + directive was quite common and many people didn't even know it existed + and assumed it's just how PHP works. This page will explain how one can + write insecure code with this directive but keep in mind that the + directive itself isn't insecure but rather it's the misuse of it. + + + When on, register_globals will inject (poison) your scripts will all + sorts of variables, like request variables from html forms. This + coupled with the fact that PHP doesn't require variable initializion + means writing insecure code is that much easier. It was a difficult + decision but the PHP community decided to disable this directive by + default. When on, people use variables yet really don't know for sure + where they come from and can only assume. Internal variables that are + defined in the script itself get mixed up with request data sent by + users and disabling register_globals changes this. Let's demonstrate + with an example misuse of register_globals: - While it does slightly increase the amount of effort required - to work with PHP, it has been argued that the benefits far - outweigh the effort. - Working with register_globals=on + Example misuse with register_globals = on ]]> + + + When register_globals = on, our logic above may be compromised. When + off, $authorized can't be set via request so it'll + be okay although it really is good general programming practice to + initialize variables first. For example, in our example above we might + have first done $authorized = false. Doing this + first means our above code would work with register_globals on or off as + users by default would be unauthorized. + + + Another example is that of sessions. + When register_globals = on, we could also use + $username in our example below but again you must + realize that $username could also come from other + means, such as GET (through the URL). + + - Working with register_globals = off + Example use of sessions with register_globals on or off {$_SESSION['username']}"; + +} else { + + echo "Hello Guest
"; + echo "Would you like to login?"; + } ?> ]]> - By using this wisely, it's even possible to take preventative - measures to warn when forging is being attempted. If you know - ahead of time exactly where a variable should be coming from, - you can check to see if submitted data is coming from an - inappropriate kind of submission. While it doesn't guarantee - that data has not been forged, it does require an attacker - to guess the right kind of forging. + + + It's even possible to take preventative measures to warn when forging is + being attempted. If you know ahead of time exactly where a variable + should be coming from, you can check to see if the submitted data is + coming from an inappropriate kind of submission. While it doesn't + guarantee that data has not been forged, it does require an attacker to + guess the right kind of forging. If you don't care where the request + data comes from, you can use $_REQUEST as it contains + a mix of GET, POST and COOKIE data. See also the manual section on + using variables from outside + of PHP. + + Detecting simple variable poisoning ]]> - Of course, simply turning off register_globals does not mean code - is secure. For every piece of data that is submitted, it - should also be checked in other ways. + + Of course, simply turning off register_globals does not mean your code + is secure. For every piece of data that is submitted, it should also be + checked in other ways. Always validate your user data and initialize + your variables! To check for unitialized variables you may turn up + error_reporting to show + E_NOTICE level errors. + + + ¬e.superglobals; + diff --git a/security/index.xml b/security/index.xml index 24bb489348..fc367ec38f 100644 --- a/security/index.xml +++ b/security/index.xml @@ -1,5 +1,5 @@ - + Security @@ -1023,80 +1023,138 @@ if ($good_login == 1) { // If above test fails, not initialized or checked befor Using Register Globals - One feature of PHP that can be used to enhance security is configuring PHP with - register_globals = off. - By turning off the ability for any user-submitted variable to be injected - into PHP code, you can reduce the amount of variable - poisoning a potential attacker may inflict. They will have - to take the additional time to forge submissions, and your - internal variables are effectively isolated from user - submitted data. + Perhaps the most controversial change in PHP is when the default value + for the PHP directive + register_globals went from ON to OFF in PHP + 4.2.0. Reliance on this + directive was quite common and many people didn't even know it existed + and assumed it's just how PHP works. This page will explain how one can + write insecure code with this directive but keep in mind that the + directive itself isn't insecure but rather it's the misuse of it. + + + When on, register_globals will inject (poison) your scripts will all + sorts of variables, like request variables from html forms. This + coupled with the fact that PHP doesn't require variable initializion + means writing insecure code is that much easier. It was a difficult + decision but the PHP community decided to disable this directive by + default. When on, people use variables yet really don't know for sure + where they come from and can only assume. Internal variables that are + defined in the script itself get mixed up with request data sent by + users and disabling register_globals changes this. Let's demonstrate + with an example misuse of register_globals: - While it does slightly increase the amount of effort required - to work with PHP, it has been argued that the benefits far - outweigh the effort. - Working with register_globals=on + Example misuse with register_globals = on ]]> + + + When register_globals = on, our logic above may be compromised. When + off, $authorized can't be set via request so it'll + be okay although it really is good general programming practice to + initialize variables first. For example, in our example above we might + have first done $authorized = false. Doing this + first means our above code would work with register_globals on or off as + users by default would be unauthorized. + + + Another example is that of sessions. + When register_globals = on, we could also use + $username in our example below but again you must + realize that $username could also come from other + means, such as GET (through the URL). + + - Working with register_globals = off + Example use of sessions with register_globals on or off {$_SESSION['username']}"; + +} else { + + echo "Hello Guest
"; + echo "Would you like to login?"; + } ?> ]]> - By using this wisely, it's even possible to take preventative - measures to warn when forging is being attempted. If you know - ahead of time exactly where a variable should be coming from, - you can check to see if submitted data is coming from an - inappropriate kind of submission. While it doesn't guarantee - that data has not been forged, it does require an attacker - to guess the right kind of forging. + + + It's even possible to take preventative measures to warn when forging is + being attempted. If you know ahead of time exactly where a variable + should be coming from, you can check to see if the submitted data is + coming from an inappropriate kind of submission. While it doesn't + guarantee that data has not been forged, it does require an attacker to + guess the right kind of forging. If you don't care where the request + data comes from, you can use $_REQUEST as it contains + a mix of GET, POST and COOKIE data. See also the manual section on + using variables from outside + of PHP. + + Detecting simple variable poisoning ]]> - Of course, simply turning off register_globals does not mean code - is secure. For every piece of data that is submitted, it - should also be checked in other ways. + + Of course, simply turning off register_globals does not mean your code + is secure. For every piece of data that is submitted, it should also be + checked in other ways. Always validate your user data and initialize + your variables! To check for unitialized variables you may turn up + error_reporting to show + E_NOTICE level errors. + + + ¬e.superglobals; +