@查尔斯是非常正确的！
您面临多种 已知 SQL攻击的风险，包括您提到的
- SQL注入：是的！Mysql_Escape_String可能仍然使您容易受到SQL注入的影响，具体取决于您在查询中使用PHP变量的位置。
考虑一下：
$sql = "SELECt number FROM PhoneNumbers " . "WHERe " . mysql_real_escape_string($field) . " = " . mysql_real_escape_string($value);
这样可以安全可靠地逃脱吗？没有！为什么？因为黑客很可能仍然可以这样做：
在我之后重复：
mysql_real_escape_string()
仅用于转义变量数据，而 不是 表名，列名，尤其是LIMIT字段。
LIKE漏洞：LIKE“ $ data％”，其中$ data可能是“％”，它将返回所有记录…这 很可能 是安全漏洞…只是想像一下信用卡最后四位数字的查找。糟糕！现在，黑客可能会收到您系统中的每个信用卡号！（顺便说一句：几乎不建议存储完整的信用卡！）
Charset Exploits：无论仇恨者怎么说，Internet Explorer 在2011年 仍然 容易受到Character Set Exploits的攻击，也就是说， 如果 您正确设计了HTML页面，等效于
<meta name="charset" value="UTF-8"/>
！这些攻击非常讨厌，因为它们给黑客提供了与直接SQL注入一样多的控制权：例如完全攻击。
这是一些示例代码来演示所有这些：
// Contains class DBConfig; database information.require_once('../.dbcreds');$dblink = mysql_connect(DBConfig::$host, DBConfig::$user, DBConfig::$pass);mysql_select_db(DBConfig::$db);//print_r($argv);$sql = sprintf("SELECT url FROM GrabbedURLs WHERe %s LIKE '%s%%' LIMIT %s", mysql_real_escape_string($argv[1]), mysql_real_escape_string($argv[2]), mysql_real_escape_string($argv[3]));echo "SQL: $sqln";$qq = mysql_query($sql);while (($data = mysql_fetch_array($qq))){ print_r($data);}这是传递各种输入时此代码的结果：
$ php sql_exploits.php url http://www.reddit.com idSQL generated: SELECt url FROM GrabbedURLs WHERe url LIKE 'http://www.reddit.com%' ORDER BY id;Returns: Just URLs beginning w/ "http://www.reddit.com"$ php sql_exploits.php url % idSQL generated: SELECt url FROM GrabbedURLs WHERe url LIKE '%%' ORDER BY id;Results: Returns every result Not what you programmed, ergo an exploit --
$ PHP sql_exploits.php 1 = 1 ‘
http://www.reddit.com ‘身份证结果：返回每列和每个结果。
然后有一些非常讨厌的LIMIT漏洞：
$ php sql_exploits.php url > 'http://www.reddit.com'> "UNIOn SELECt name FROM CachedDomains"Generated SQL: SELECt url FROM GrabbedURLs WHERe url LIKE 'http://reddit.com%' LIMIT 1 UNIOn SELECt name FROM CachedDomains;Returns: An entirely unexpected, potentially (probably) unauthorized query from another, completely different table.
无论您是否了解攻击中的SQL，都是不明智的。这表明，即使是最不成熟的黑客也 很容易
绕过mysql_real_escape_string（）。那是因为它是一种反应式防御机制。它仅修复数据库中非常有限且已知的漏洞。
所有转义都永远不足以保护数据库。实际上，您可以显式地对每个已知的漏洞进行反应，并且将来，您的代码很可能会受到将来发现的攻击的攻击。
适当且唯一（实际上）的防御是一种主动：使用准备好的语句。对准备好的语句的设计要格外小心，以便仅执行有效的和已编程的SQL。这意味着，如果正确完成，则会大大降低执行意外SQL的可能性。
从理论上讲，可以很好地实现的预处理语句不会受到所有已知和未知的攻击，因为它们是一种SERVER SIDE技术，由DATAbase SERVERS
THEMSELVES和与编程语言接口的库处理。因此，始终保证您会受到最低限度的保护，免受任何已知的黑客攻击。
而且代码更少：
$pdo = new PDO($dsn);$column = 'url';$value = 'http://www.stackoverflow.com/';$limit = 1;$validColumns = array('url', 'last_fetched');// Make sure to validate whether $column is a valid search parameter.// Default to 'id' if it's an invalid column.if (!in_array($column, $validColumns) { $column = 'id'; }$statement = $pdo->prepare('SELECt url FROM GrabbedURLs ' . 'WHERe ' . $column . '=? ' . 'LIMIT ' . intval($limit));$statement->execute(array($value));while (($data = $statement->fetch())) { }现在不是那么难吗？而且它的 代码减少了百分之四十七 （195个字符（PDO）对375个字符（mysql_），这就是我所说的“充满胜利”。
编辑：为了解决这个答案引起的所有争议，请允许我重申我已经说过的话：
使用准备好的语句使您可以利用SQL Server本身的保护措施，因此可以保护您免受SQL Server人们所了解的事情的影响。
由于这种额外的保护级别，无论多么彻底，您都比仅使用转义安全得多。
