![]() |
Mysql_real_escape_string and PDO statements
I hear many times some people keep saying to use PDO statement to prevent SQL injections. I still use mysql_real_escape_string against sql injection and htmlentities or strip tags for XSS to protect forms etc.
So, why PDO statements? MySQL_real_escape_string is not good anymore? Does PDO statement provides better security than mysql_real_escape_string? I work with Procedural only just to enable people fill some short details to store in database, then retrieve them and display on pages. |
Mysql library itself is old. Really old; API indicates that it is discouraged to use it old.
I assume what you actually mean is prepared statements; PDO is an abstraction layer which happens to support prepared statements. MySQLi, OCI and SQLServer all support prepared statements as well. Prepared statements provide much better SQL injection prevent-ability. As in, 0% chance of injection. Prepared statements precompile the statement structure separate from the data so it is impossible for the data to corrupt the SQL itself with input data bound by variable. Its also a dream in batch processing. |
And can we add our traditional htmlentities or strip tags in PDO statements to protect against XSS?
|
Not in the statements, but you can do whatever you want to the variable first.
|
Ok thank. I will consider it now. Hope I find a good tutorial on this. It is very rare you find PHP OO tutorials on books, videos etc... Most of them are difficult to follow.
|
Quote:
|
MySQLi can be used in a procedural fashion or an OO fashion.
See the API documentation for an example of each: http://ca3.php.net/manual/en/mysqli-stmt.prepare.php MySQLi base also has a prepare method which would be more or less the same as going directly through the MySQLiStatement class. |
So PDO and Mysqlli are different? If yes, which one is better?
|
Quote:
Theoretically, specific packages built for specific dbs should perform better overall than an abstraction layer would. But an abstraction layer has the benefit of being abstract, so I guess it depends on if you are looking for performance over swap-ability. If you intend to use MySQL proprietary syntax like group_concat or LIMIT, then you may as well use the MySQLi for the gain. |
Quote:
You should use striptags where you want to convert HTML to plain text. Neither has anything to do with databases. Vakidating your data properly when it is first received from the user is the best way to prevent against XSS and also protects against your database getting filled with meaningless junk. If you validate your data properly then there is no possibility of XSS existing - it only happens because sites allow garbage to be entered in forms and don't validate it. How many people do you know whose name or address looks like an SQL command? |
I have never said strip_tags and htmlentities are used for database! I said I used them against XSS. Read again.
|
Quote:
Quote:
By the way, XSS is client side by the way, and not related to SQL injection (correct me if I'm wrong please). Quote:
|
Yes as in Procedural we often protect textbox etc in variable, I wanted to know if in PDO also the same. It has nothing to do with SQL injection. I clearly mentioned it on XSS.
|
Well yeah, but you were referring to PDO statements, which are used for database.
But, that's besides the original subject of your thread, so lets drop the discussion :) Getting back to your original post though, are you using MySQL or MySQLi? If the answer is MySQL, you should really switch to using the MySQLi library. For one PHP will drop support on MySQL with the next major release (or so the rumours go), secondly it support OOP and thirdly it has real_escape_string to :) Oh, and it's just generally better, faster and safer. Or so they say. |
I am planning to use MySQLi in the future. I do web design more than programming. And its for fun only as programming is boring lol. Im more on web marketing, marketing, office and little desktop publishing.
|
| All times are GMT +1. The time now is 04:25 PM. |
Powered by vBulletin®
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.