SitePoint Sponsor

User Tag List

Page 2 of 2 FirstFirst 12
Results 26 to 36 of 36
  1. #26
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AndreTheDark View Post
    The post by triexa claims the addslashes() function will be removed in php6.
    does that also mean magic_quotes_gpc will disappear since that auto-runs addslashes() on all POST/GET input.
    magic_quotes_gpc is already disabled by default, and it will be removed completely from PHP 6 an onwards. addslashes will still be there, so you can run it manually, if you want.

    Quote Originally Posted by AndreTheDark View Post
    besides, I am looking for a way to code as database independant as possible
    You should use PDO and prepared statements. They work across different database systems/sql dialects and (more importantly) they are completely safe against injection type attacks.

    Quote Originally Posted by AndreTheDark View Post
    and if I understand this exploit problem correctly, as long as I ensure my data is valid UTF-8 encoded, this exploit could not be used.
    The thing is, data usually comes from users, and therefore you have no guarantee as to their contents.

  2. #27
    SitePoint Member
    Join Date
    Mar 2009
    Location
    Beek, Limburg, Netherlands
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    The thing is, data usually comes from users, and therefore you have no guarantee as to their contents.
    I can verify the encoding of the string with mb_check_encoding()
    I wish to verify the encoding, not only for security reasons but also to be sure the data is valid, as in, will be displayed correctly.

  3. #28
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AndreTheDark View Post
    I can verify the encoding of the string with mb_check_encoding()
    I wish to verify the encoding, not only for security reasons but also to be sure the data is valid, as in, will be displayed correctly.
    OK - That's probably not a bad idea, but security-wise prepared statements are completely resistant to any kind of sql-injection attack. This is because with bound parameters, the data and the query are transmitted separately and the data is never interpreted by the database engine.

  4. #29
    SitePoint Member
    Join Date
    May 2009
    Posts
    1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Thumbs up

    All you guys rock and its a very good learning experience for newbies like me.

  5. #30
    SitePoint Member
    Join Date
    Mar 2009
    Location
    Beek, Limburg, Netherlands
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Great!!! really great!!! SPAM about MATH only AFTER I FAILED FOR MY MATH EXAM!!!!

  6. #31
    SitePoint Member
    Join Date
    Sep 2010
    Posts
    2
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank You for your great tips! I my opinion too mysql_real_escape_string() is safe enough.

  7. #32
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    ... and to think all I did was abandon the mySQL_ functions completely and switch to PDO with prepare/execute.

  8. #33
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,872
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    ... and to think all I did was abandon the mySQL_ functions completely and switch to PDO with prepare/execute.
    I agree - mysql_real_escape_string is completely unnecessary if you write your SQL calls properly. Another dinosaur to remove from your toolbox.

    You don't even need to switch to PDO either since the mysqli_ functions support prepare statements (either procedural or object oriented) without the need for anything else.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">

  9. #34
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by felgall View Post
    You don't even need to switch to PDO either since the mysqli_ functions support prepare statements (either procedural or object oriented) without the need for anything else.
    True, but I'm not wild about having the mySQL connection global in scope... another reason to abandon the procedural and if the connection is needed in other functions, pass the PDO object by reference.

  10. #35
    Grumpy Minimalist
    Join Date
    Jul 2006
    Location
    Ontario, Canada
    Posts
    424
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    I'm not wild about having the mySQL connection global in scope... another reason to abandon the procedural
    The mysqli_* functions require neither global connection resources nor procedural syntax.

  11. #36
    Programming Since 1978 silver trophybronze trophy felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, NSW, Australia
    Posts
    16,872
    Mentioned
    25 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by deathshadow60 View Post
    True, but I'm not wild about having the mySQL connection global in scope...
    What has that got to do with anything - the only difference between the mysql_ and mysqli_ connections if you use procedural code is that whether the database connection comes before or after the query in the parameter list.

    If you use the OO version of mysqli_ then you don't need to specify the connection as it is stored within the SQL object you create when you open the database connection.

    Whichever way you access the database the scope of the connection depends entirely on when you do the call to connect and is exactly the same for bot mysql_ and mysqli_

    The only difference is that mysqli_ supports the prepare statement without the need for any add-ons such as PDO.

    As such using mysqli_ is the cleaner and potentially more secure alternative.
    Stephen J Chapman

    javascriptexample.net, Book Reviews, follow me on Twitter
    HTML Help, CSS Help, JavaScript Help, PHP/mySQL Help, blog
    <input name="html5" type="text" required pattern="^$">


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
  •