Is it enough to simply use the addslashes() function on database queries involving user input? Or should user input be ran through some other functions first?

    Yep, that's all you need. Remember that if you have magic_quotes_gpc turned on then you will be doubling up. You also need to check other things as well, though.

    • Inserting no more than 255 chars into a varchar(255)
    • Dates are legal (eg. 2002-02-31 is bad)
    • Etc., etc.

      Hiya,

      There's lots that you can and probably should do to user submitted content - I'll list a few off the top of my head, with a brief explanation of why - obviously some of these may not be needed depending on the level of trust you have with whoever is punching the stuff in:

      addslashes() - yep sure, that will stop some of your sql syntax errors

      striptags() - I'm assuming here you don't want your users chucking HTML into your pages - if you do, then use the optional argument to specify which ones are allowed - for example:
      $apples = strip_tags($apples, '<p><br><i>');
      (note you don't need to specify the trailing tag as well - PHP can figure that one out for you!) more information here:
      http://www.php.net/manual/en/function.strip-tags.php

      use regular expressions to allow only the information you want. ie bar everything then let in only what is acceptable.
      For example this will allow only the alphabet and numbers, spaces and a dash:
      $strSearch = eregi_replace("[a-zA-Z0-9 -']", "", $strSearch);

      Explicitly state what form the data is in using settype(). If your expecting a string then set it as such:
      settype($strSearch,"string");
      likewise for an integer etc.
      more information here:

      http://www.php.net/manual/en/function.settype.php

      You didn't mention what database you're using, so I'll assume MySQL - if so, don't accept // (which is used as a comment) or, if you're using MSSQL bar -- which is used in the same manner.

      My main concern in all the above, is protecting your db against SQL Injection attacks - one can never be tooo paranoid ;-)

      Oh, and as chriskl points out - make sure the data is in the right format for your database design...

      Have a nice day
      /s

        Just to add another note, i never let the # sign into my db either.... Those tend to act as comments, and welll importing a backup has become a pain with just a few of them scattered....

        Also, a striptags() might be a bit to harsh... perhaps just htmlspecialchars() the string if you're worried about HTML working it's way in....

        also don't forget to stripslashes() in any select results 🙂

          Make sure you run intval( ) (or float, etc) on numeric input.

            All of these comments are good, but if you are re-displaying the input back to a browser it is vital that you STRIP TAGS. An evil user could insert VB or Java Script that can do unpleasant things to the next person to view that database entry.

              hmz to make it all complete... dont forget the trim and chop...
              i agree with edwardsbc.. strip_tags(addslashes($value)); must be more than enough..

              But all of this is nice but no the way of storing data. you all store the data in a way nobody can work with it in a easy way.. maybe its worth it to take a peek at XML/XSLT. Its VERY powerfull in combination with a DBMS.

                Write a Reply...