I mean the output is identical
But when I use HTMLentities only the source code gets changed
IS this what I'm looking for?
you don't use htmlentities and PDO together - they are unrelated.
Originally Posted by phpnewbie34
htmlentities will turn <div> into < ;div> ;
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 < ;script src='...'> ;< ;/script> ; in the raw html, which is harmless
Last edited by Northie; May 31st, 2013 at 10:29 AM.
What do htmlentities and PDO have in common?
They both deal with injection.
What do they not have in common?
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
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.
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:
Originally Posted by Northie
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.
// important! specify the character encoding in the DSN string, don't use SET NAMES
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.
June 27th, 2013, 04:53 AM
I ♥ ManiacDan & requinix
This is a sig, and not necessarily
a comment on the OP:
don't be a help vampire
June 27th, 2013, 06:35 AM
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.