Page 2 of 2 First 12
  • Jump to page:
    #16
  1. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2013
    Posts
    40
    Rep Power
    2

    Re:


    I mean the output is identical

    But when I use HTMLentities only the source code gets changed

    IS this what I'm looking for?
  2. #17
  3. Mad Scientist
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Oct 2007
    Location
    North Yorkshire, UK
    Posts
    3,661
    Rep Power
    4123
    Originally Posted by phpnewbie34
    I tried using html entities to escape HTML tags ... but it's not working.

    If somebody enters <script> or <div>, how do I remove the '<>'s?

    How do I use htmlentities with PDO functions, not mysqli?
    you don't use htmlentities and PDO together - they are unrelated.

    htmlentities will turn <div> into &lt ;div&gt ;

    So if someone had entered <script src='...'></script> into your form the prepared statements in PDO would sort out the quote marks so that the queries doesn't break. Then, when you echo'd it out you'd use htmlentities and you'd get &lt ;script src='...'&gt ;&lt ;/script&gt ; in the raw html, which is harmless
    Last edited by Northie; May 31st, 2013 at 10:29 AM.
    I said I didn't like ORM!!! <?php $this->model->update($this->request->resources[0])->set($this->request->getData())->getData('count'); ?>

    PDO vs mysql_* functions: Find a Migration Guide Here

    [ Xeneco - T'interweb Development ] - [ Are you a Help Vampire? ] - [ Read The manual! ] - [ W3 methods - GET, POST, etc ] - [ Web Design Hell ]
  4. #18
  5. No Profile Picture
    Contributing User
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Sep 2006
    Posts
    2,030
    Rep Power
    535
    What do htmlentities and PDO have in common?

    They both deal with injection.

    What do they not have in common?

    htmlentities protects against xss (cross-site scripting) where a bad guy injects javascript into a poor innocent guy's client. It is often first injected into the database, but typically we don't worry about it then, but only when it is sent to the client.

    PDO protects against SQL injection. This is where some bad guy sends something to the server which is interpreted and executed as SQL.

    As Northie indicated, they are two totally different things
  6. #19
  7. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Posts
    3,959
    Rep Power
    1014
    Use htmlspecialchars() instead of htmlentities(). The latter is a waste of time and resources, because it transforms every possible character into its HTML entity. That's not what you want. You only want to transform the "dangerous" characters -- which is what htmlspecialchars() does.

    It's also crucial to set the right character encoding. Without that, the whole function can be useless (which even Google had to learn).

    Check the 10 worst sins of security. A lot of the things you're discussing here I already wrote down in this thread.



    Originally Posted by Northie
    versions of php prior to PHP 5.3.6 did not allow the charset attribute in the DSN, so set names had to be used. Set names can be buggy.
    No, using SET NAMES to change the character encoding for a database interface is conceptually wrong and can break all escaping functions. In other words, this will make the code vulnerable to SQL injections despite the use of escaping functions. That's why I put a big warning into the code above:

    PHP Code:
    // important! specify the character encoding in the DSN string, don't use SET NAMES 
    This does not affect prepared statements (the real ones). But obviously it's still not a good idea to run around with broken security functions that don't do what they're supposed to do.

    The problem of SET NAMES is that you "silently" change the underlying character encoding without notifying the application of it. The application doesn't know that you've just made a query to change the encoding from, say, ANSI to UTF-8. It still thinks you're using ANSI, so all escaping functions will assume the wrong encoding. This can make them completely blind, because they simply no longer recognize the "dangerous" characters.

    This problem applies to all database libraries, not just PDO. You'll get the same effect with the old MySQL library or MySQLi or whatever.

    Fortunately, the mainstream encodings used today (ASCII, ANSI and UTF-8) all share the same bit encoding for the "dangerous" characters. So while this mistake is made again and again, it rarely leads to actual vulnerabilities. But don't rely on this piece of luck to keep your broken code secure! As soon as you deal with more exotic encodings, your whole security will fall apart. On a side node: If you're willing to rely on all "dangerous" characters being encoded as ASCII, it's safer to use the good ol' addslashes() rather than the new escaping functions (mysql_real_escape() etc.). Because addslashes() is guaranteed to recognize ASCII characters.

    Long story stort: Never use SET NAMES. If that's the only way you can change the encoding due to some outdated PHP version or library, then you cannot change the encoding in PHP at all. You have to do it in MySQL.

    But since your PHP version 5.3.18 came after 5.3.6, I'm not even sure why we're having this discussion. You can simply use the DSN string.
    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".
  8. #20
  9. No Profile Picture
    I haz teh codez!
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Dec 2003
    Posts
    2,549
    Rep Power
    2337
    That last reply from johnmcd appears to be nothing more than a copy/paste from other sites.

    Comments on this post

    • Jacques1 agrees : We really need a spam filter. :-(
    I ♥ ManiacDan & requinix

    This is a sig, and not necessarily a comment on the OP:
    Please don't be a help vampire!
  10. #21
  11. Sarcky
    Devshed Supreme Being (6500+ posts)

    Join Date
    Oct 2006
    Location
    Pennsylvania, USA
    Posts
    10,908
    Rep Power
    6351
    I actually just banned him in another thread.
    HEY! YOU! Read the New User Guide and Forum Rules

    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin

    "The greatest tragedy of this changing society is that people who never knew what it was like before will simply assume that this is the way things are supposed to be." -2600 Magazine, Fall 2002

    Think we're being rude? Maybe you asked a bad question or you're a Help Vampire. Trying to argue intelligently? Please read this.
Page 2 of 2 First 12
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo