note 110413 added to function.mysql-real-escape-string

No discussion of escaping is complete without telling everyone that you should basically never use external input to generate interpreted code. This goes for SQL statements, or anything you would call any sort of "eval" function on. So, instead of using this terribly broken function, use parametric prepared statements instead. Honestly, using user provided data to compose SQL statements should be considered professional negligence and you should be held accountable by your employer or client for not using parametric prepared statements. What does that mean? It means instead of building a SQL statement like this: "INSERT INTO X (A) VALUES(".$_POST["a"].")" You should use mysqli's prepare() function (http://us3.php.net/manual/en/mysqli.prepare.php) to execute a statement that looks like this: "INSERT INTO X (A) VALUES(?)" NB: This doesn't mean you should never generate dynamic SQL statements. What it means is that you should never use user-provided data to generate those statements. Any user-provided data should be passed through as parameters to the statement after it has been prepared. So, for example, if you are building up a little framework and want to do an insert to a table based on the request URI, it's in your best interest to not take the $_SERVER['REQUEST_URI'] value (or any part of it) and directly concatenate that with your query. Instead, you should parse out the portion of the $_SERVER['REQUEST_URI'] value that you want, and map that through some kind of function or associative array to a non-user provided value. If the mapping produces no value, you know that something is wrong with the user provided data. Failing to follow this has been the cause of a number of SQL-injection problems in the Ruby On Rails framework, even though it uses parametric prepared statements. This is how GitHub was hacked at one point. So, no language is immune to this problem. That's why this is a general best practice and not something specific to PHP and why you should REALLY adopt it. Also, you should still do some kind of validation of the data provided by users, even when using parametric prepared statements. This is because that user-provided data will often become part of some generated HTML, and you want to ensure that the user provided data isn't going to cause security problems in the browser. ---- Server IP: 64.71.164.2 Probable Submitter: 184.74.76.66 ---- Manual Page -- http://www.php.net/manual/en/function.mysql-real-escape-string.php Edit -- https://master.php.net/note/edit/110413 Del: integrated -- https://master.php.net/note/delete/110413/integrated Del: useless -- https://master.php.net/note/delete/110413/useless Del: bad code -- https://master.php.net/note/delete/110413/bad+code Del: spam -- https://master.php.net/note/delete/110413/spam Del: non-english -- https://master.php.net/note/delete/110413/non-english Del: in docs -- https://master.php.net/note/delete/110413/in+docs Del: other reasons-- https://master.php.net/note/delete/110413 Reject -- https://master.php.net/note/reject/110413 Search -- https://master.php.net/manage/user-notes.php