Doc #60398 [Opn->Wfx]: mysql_real_escape_string description is wrong and decieving

Edit report at https://bugs.php.net/bug.php?id=60398&edit=1 ID: 60398 Updated by: frozenfire@php.net Reported by: col dot shrapnel at gmail dot com Summary: mysql_real_escape_string description is wrong and decieving -Status: Open +Status: Wont fix Type: Documentation Problem Package: Documentation problem Operating System: irrelevant PHP Version: Irrelevant Block user comment: N Private report: N New Comment: Hi. Let me first say that I agree with you wholeheartedly. The mysql extension needs to be deprecated and removed as soon as possible, because it encourages new programmers to make bad design decisions in favour of quick, sloppy code. However, this is not a documentation problem. So long as the project retains the mysql extension as an active extension, and does not provide any notice-type errors warning against its use, there is nothing to be done from the documentation perspective. In short, yes you're right, but no we can't do anything about it. Previous Comments: ------------------------------------------------------------------------ [2011-11-27 10:26:38] col dot shrapnel at gmail dot com Description: ------------ --- From manual page: http://www.php.net/function.mysql-real-escape-string#refsect1- function.mysql-real-escape-string-description --- I am writing in account of the mysql_real_escape_string() description, which current phrasing is erroneous and decieving, leading thousands of PHP programmers to confusion and make them writing the code that actually _allows_ injection. It says at the moment --- This function must always (with few exceptions) be used to make data safe before sending a query to MySQL. --- Which is obviously wrong, as the function doesn't make data whatever "safe". And "few exceptions" statement is not an excuse as it explains nothing. Based on this very description, many people having an idea of injection protection limited to just "escape all your data" and actually allow an injection as a result. I insists on the different phrasing, says (with obvious grammar or styling check): --- This function must always be used to process every string (i.e. piece of data enclosed in the single quotes) added to the query. Note that this function doesn't make any data "safe" as it's just escaping special characters in the strings only and thus it is useless to protect other data types, such as numbers or identifiers. --- Same goes for the note, saying --- If this function is not used to escape data, the query is vulnerable to SQL Injection Attacks. --- "data" again! So, it is just false statement, as even if the function were used, there are circumstances under which your query remains vulnerable. Also, in account of the only purpose of this function, in should be explicitly noted that only prior call to mysql_set_charset() will make the mysql_real_escape_string different from mysql_escape_string() - i.e. make it " taking into account the current character set of the connection". Test script: --------------- $data = "1 union select password from users" $data = mysql_real_escape_string($data); $sql = "SELECT title FROM news WHERE id=$data"; Expected result: ---------------- The $data become "safe" and stopped injection. Actual result: -------------- The code above didn't make the data "safe" and didn't stop the injection. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=60398&edit=1