SitePoint Sponsor

User Tag List

Results 1 to 16 of 16
  1. #1
    SitePoint Addict
    Join Date
    Apr 2005
    Posts
    287
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Is this too crazy?

    PHP Code:
    $name mysql_real_escape_string(rtrim(ltrim(htmlspecialchars(strip_tags($_POST['name']))))); 
    Too much?... just testing some things.
    How does that make your feel?

  2. #2
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    all you need
    PHP Code:
    $name mysql_real_escape_string($_POST['name']); 
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  3. #3
    SitePoint Addict CVPer's Avatar
    Join Date
    Sep 2007
    Location
    Vancouver, BC, Canada
    Posts
    233
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    you may keep htmlspecialchars() and strip_tags() if really need, but mysql_real_escape_string() does more than rtrim() and ltrim().
    * @location Vancouver, BC, Canada
    * @name Steve
    * @job PHP/MySQL, Drupal, WordPress Developer

  4. #4
    SitePoint Wizard cranial-bore's Avatar
    Join Date
    Jan 2002
    Location
    Australia
    Posts
    2,634
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    FYI rtrim and ltrim and equivalent to trim

  5. #5
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by CVPer View Post
    you may keep htmlspecialchars()...
    htmlspecialchars is for output into an html page not into a database.
    Those characters will not harm a DB.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  6. #6
    SitePoint Addict CVPer's Avatar
    Join Date
    Sep 2007
    Location
    Vancouver, BC, Canada
    Posts
    233
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    htmlspecialchars is for output into an html page not into a database.
    Those characters will not harm a DB.
    that's right, logic_earth. that's also why i said '... if really need'
    * @location Vancouver, BC, Canada
    * @name Steve
    * @job PHP/MySQL, Drupal, WordPress Developer

  7. #7
    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 CVPer View Post
    that's right, logic_earth. that's also why i said '... if really need'
    I believe his point was, that they aren't.

  8. #8
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Using htmlspecialchars is encoding data for a specific document format. You should not taint your database data with that encoding. Don't over think injection security. Escaping is all you need for database storage. Trimming surrounding white space is fine, as this may aid in database searches and in proper display of values from the database, but just use trim for that.

  9. #9
    SitePoint Addict CVPer's Avatar
    Join Date
    Sep 2007
    Location
    Vancouver, BC, Canada
    Posts
    233
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    at least, htmlspecialchars() is useful to avoid hacking by inputing javascript
    * @location Vancouver, BC, Canada
    * @name Steve
    * @job PHP/MySQL, Drupal, WordPress Developer

  10. #10
    SitePoint Addict
    Join Date
    Apr 2005
    Posts
    287
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by CVPer View Post
    at least, htmlspecialchars() is useful to avoid hacking by inputing javascript
    That was my thinking on the htmlspecialchars
    How does that make your feel?

  11. #11
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    Except you only need it on output when putting into an HTML page.
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.


  12. #12
    SitePoint Addict CVPer's Avatar
    Join Date
    Sep 2007
    Location
    Vancouver, BC, Canada
    Posts
    233
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by logic_earth View Post
    Except you only need it on output when putting into an HTML page.
    but i think if there exists such a possibility then it should be dealt with, no matter how many usages of it.

    that's why fighting with hackers is so hard because we cannot know all the possible ways to be attacked.
    * @location Vancouver, BC, Canada
    * @name Steve
    * @job PHP/MySQL, Drupal, WordPress Developer

  13. #13
    reads the ********* Crier silver trophybronze trophy longneck's Avatar
    Join Date
    Feb 2004
    Location
    Tampa, FL (US)
    Posts
    9,854
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    i vote for NOT using html_special_characters() when inserting in to the database. that kind of thing is presentation layer logic and should only be used when displaying data, not inserting.

  14. #14
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It serves no security purpose to do that to database data. It only needs to be done on output that is for display in HTML. A clean dataset can be used for display in many data formats. PDF, Excel, HTML. If you encode the data for one, you can't use it for another. Not to mention the difficulty of doing searches and matches on data. You get no benefit what so ever from encoding the data, going into the database. In addition this sort of encoding increases the size of the data. For instance you go from a double quote character to ".

  15. #15
    SitePoint Addict CVPer's Avatar
    Join Date
    Sep 2007
    Location
    Vancouver, BC, Canada
    Posts
    233
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    my original point is that htmlspecialchars() could be kept in madmike's code since its function cannot be done by mysql_real_escape_string()

    now, it seems that we shifted the focus to htmlspecialchars() and we are discussing,
    - whether function htmlspecialchars() is necessary or useful and
    - when to use it if we need to use it for security reason.

    well, htmlspecialchars() may not be an efficient or suitable method for security check. but it does function in some particular case, such as avoiding javascripts when showing the data in html format.

    for each piece of data stored in the database, there must be some specific purposes. if html tags are regarded as valid data, then there is no much difference between encoding it when inserting it the database and when showing it, or even encoding is not necessary. at this point, i totally agree with longneck. if the tags are invalid contents, on the other hand, they should be dealt with before storing into the database. otherwise, data is getting dirty.
    * @location Vancouver, BC, Canada
    * @name Steve
    * @job PHP/MySQL, Drupal, WordPress Developer

  16. #16
    . shoooo... silver trophy logic_earth's Avatar
    Join Date
    Oct 2005
    Location
    CA
    Posts
    9,013
    Mentioned
    8 Post(s)
    Tagged
    0 Thread(s)
    If you do not want HTML tags in your database then strip them out. But don't encode them. Inserting JavaScript into a form won't be able to hack anything. Its when it is outputted it becomes an issue.

    When it comes to storing data in a DB you want to filter not encode unless you have no other means but to encode. (In this case you don't need to encode.)
    Logic without the fatal effects.
    All code snippets are licensed under WTFPL.



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
  •