Thread: Ha ha ha

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

    Join Date
    Dec 2005
    Location
    Vancouver, WA, USA
    Posts
    397
    Rep Power
    189

    Ha ha ha


    Actually it's not that funny, because this is how people learn incorrect solutions...

    I was watching a series of PAID training videos on OOP a few days ago, and this instructor was pushing all data destined for mysql_* queries through these methods.

    He was not just putting $_POST/$_GET/$_COOKIE values in here, but all others as well.

    PHP Code:
    function __construct() {
        
    $this->open_connection();
        
    $this->magic_quotes_active get_magic_quotes_gpc();
        
    $this->real_escape_string_exists function_exists"mysql_real_escape_string" );
    }

    public function 
    escape_value$value ) {
        if( 
    $this->real_escape_string_exists ) { // PHP v4.3.0 or higher
            // undo any magic quote effects so mysql_real_escape_string can do the work
        
    if( $this->magic_quotes_active ) { $value stripslashes$value ); }
        
    $value mysql_real_escape_string$value );
        } else { 
    // before PHP v4.3.0
            // if magic quotes aren't already on then add slashes manually
        
    if( !$this->magic_quotes_active ) { $value addslashes$value ); }
            
    // if magic quotes are active, then the slashes already exist
        
    }
        return 
    $value;

    In short, if magic quotes were active, he unescaped EVERYTHING before escaping it again...

    This could under the right circumstances change data in ways he's not expecting...
    Thomas Tremain
  2. #2
  3. Did you steal it?
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    14,071
    Rep Power
    9398
    ...That code is right. magic_quotes doesn't protect you from SQL injection but will corrupt the data if you run it through any escaping function. If magic_quotes are active then the correct procedure is to stripslashes() to undo its effects and then escape the string properly.
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2005
    Location
    Vancouver, WA, USA
    Posts
    397
    Rep Power
    189
    Originally Posted by requinix
    ...That code is right. magic_quotes doesn't protect you from SQL injection but will corrupt the data if you run it through any escaping function. If magic_quotes are active then the correct procedure is to stripslashes() to undo its effects and then escape the string properly.
    But you would not want to run stripslashes on data that was not affected by magic quotes in the first place.

    Only $_POST/$_GET and $_COOKIE data is escaped by magic quotes.. He's unescaping everything, whether escaped or not..

    Obviously it would not have an effect on:

    $a='abcdef';

    But it would have an affect on

    $b='some data //just a note//'

    If he runs this through his routine it would unescape it, when it maybe was supposed to be dual slashes...
    Last edited by ttremain; March 22nd, 2013 at 07:20 PM.
    Thomas Tremain
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2005
    Location
    Vancouver, WA, USA
    Posts
    397
    Rep Power
    189
    Another example...

    If he had a piece of data that was:

    $a='////////////////////////////////////////';

    And you ran it through that escape routine (with magic quotes on) it would come back out as the same thing, but then he would believe it was escaped...

    You then write it to your database, read it back, and unescape it, then you have:

    '////////////////////'

    That is a lack of data integrity...

    Now I have no idea how he would get that data without $_GET/$_POST or $_COOKIE, but he still could...
    Thomas Tremain
  8. #5
  9. --
    Devshed Expert (3500 - 3999 posts)

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

    yeah, if that function is applied to a string that hasn't gotten its "magic quotes", it will remove blackslashes from the content.

    This function is kind of congenial to the "magic quotes": It was a stupid idea to try to escape all data on a global level. And it's a stupid idea to try to revert this on a global level.

    The only way to fix the horrible "magic quotes" is to tell people again and again to deactive it.

    By the way, it's a myth that addslashes() is always wrong, while mysql_real_escape_string() will always protect against SQL injections. This is not the case. The difference between those function is that mysql_real_escape_string() takes the character encoding of the connection into account, while addslashes() will always assume ASCII/ANSI. However, if you change the character encoding with SET NAMES (which many people do), then mysql_real_escape_string() loses that advantage -- and in special cases, you can end up being less secure than with addslashes().

    Long story short: There is no "magical function" that will take care of everything. People have to actually understand the issue and choose the appropriate tool for each case (prepared statements, escaping, encoding, ...).
    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".
  10. #6
  11. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,317
    Rep Power
    7170
    If you can't turn magic quotes off, or can't trust that it will be turned off, one way to deal with it is to stripslashes from the entire GPC arrays at the beginning of the script.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2005
    Location
    Vancouver, WA, USA
    Posts
    397
    Rep Power
    189
    What i do, is if magic quotes are on, immediatly unescape the GPC variables only.... then escape or unescape as close to reading/writing the database as possible.

    using prepared statements is my new favorite method of worring about escaping....

    Thanks for confirming I'm not off my rocker.. though I may have lacked a bit of tact.
    Thomas Tremain
  14. #8
  15. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    By the way, there's not only magic_quotes_gpc. With magic_quotes_runtime turned on, pretty much any string from an external source will be escaped:

    http://www.php.net/manual/en/info.co...quotes-runtime

    So dealing with $_GET, $_POST, $_COOKIE alone won't help you.

    Personally, I consider any setup with "magic quotes" turned on as broken. That's what you have to fix first before you can start programming.

    Workarounds using stripslashes() require a gigantic effort (like I said: It's not only about GPC). And there's a great chance of variables slipping through or being mangled in the process. So I wouldn't even try.
    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
    Dec 2005
    Location
    Vancouver, WA, USA
    Posts
    397
    Rep Power
    189
    Originally Posted by Jacques1
    By the way, there's not only magic_quotes_gpc. With magic_quotes_runtime turned on, pretty much any string from an external source will be escaped:

    http://www.php.net/manual/en/info.co...quotes-runtime

    So dealing with $_GET, $_POST, $_COOKIE alone won't help you.

    Personally, I consider any setup with "magic quotes" turned on as broken. That's what you have to fix first before you can start programming.

    Workarounds using stripslashes() require a gigantic effort (like I said: It's not only about GPC). And there's a great chance of variables slipping through or being mangled in the process. So I wouldn't even try.
    Very good to know!
    Thomas Tremain
  18. #10
  19. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,317
    Rep Power
    7170
    To deal with magic_quotes_runtime you can just turn it off at runtime fortunately.

    Dealing with magic_quotes_sybase is a lot more difficult, but it is rarely turned on. In scripts that I write for distribution I normally have the script just die if magic_quotes_sybase is turned on.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around

IMN logo majestic logo threadwatch logo seochat tools logo