假设我有这样的代码：
$dbh = new PDO("blahblah");
$stmt = $dbh->prepare('SELECT * FROM users where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );
PDO文件说：
准备语句的参数不需要引用;司机为你处理。
这真的是我需要做的就是避免SQL注入吗？这真的很容易吗？
如果它有所作为，你可以假设MySQL。另外，我真的只是对使用针对SQL注入的预处理语句感到好奇。在这种情况下，我不关心XSS或其他可能的漏洞。
简短的回答是NO，PDO准备不会保护您免受所有可能的SQL注入攻击。对于某些不起眼的边缘案例。
我正在调整this answer谈论PDO ......
答案很长并不容易。它基于攻击demonstrated here。
那么，让我们从展示攻击开始......
$pdo->query('SET NAMES gbk');
$var = "\xbf\x27 OR 1=1 /*";
$query = 'SELECT * FROM test WHERE name = ? LIMIT 1';
$stmt = $pdo->prepare($query);
$stmt->execute(array($var));
在某些情况下，这将返回超过1行。让我们剖析一下这里发生了什么：
$pdo->query('SET NAMES gbk');
为了使这个攻击起作用，我们需要服务器在连接上所期望的编码，以编码'，如ASCII，即0x27，并且有一些字符的最终字节是ASCII \，即0x5c。事实证明，MySQL 5.6默认支持5种这样的编码：big5，cp932，gb2312，gbk和sjis。我们在这里选择gbk。
现在，注意SET NAMES的使用非常重要。这会将字符集设置为“服务器”。还有另一种方法，但我们很快就会到达那里。0xbf27开始。在gbk中，这是一个无效的多字节字符;在latin1，它是字符串¿'。请注意，在latin1和gbk中，0x27本身就是字面上的'字符。
我们已选择此有效载荷，因为如果我们在其上调用addslashes()，我们将在\字符之前插入ASCII 0x5c，即'。所以我们最终选择0xbf5c27，gbk是一个两个字符的序列：0xbf5c，然后是0x27。或者换句话说，一个有效的角色后跟一个未转义的'。但我们没有使用addslashes()。那么下一步......mysql_real_escape_string()（MySQL C API函数）。
对mysql_real_escape_string()的C API调用与addslashes()的不同之处在于它知道连接字符集。因此它可以为服务器期望的字符集正确执行转义。然而，到目前为止，客户认为我们仍在使用latin1进行连接，因为我们从未告诉过它。我们告诉服务器我们正在使用gbk，但客户端仍然认为它是latin1。
因此，对mysql_real_escape_string()的调用插入反斜杠，我们在“转义”内容中有一个免费悬挂的'字符！事实上，如果我们在$var字符集中查看gbk，我们会看到：
缞'或1 = 1 / *
这正是攻击所需要的。SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1
恭喜，您刚刚使用PDO准备语句成功攻击了一个程序......
现在，值得注意的是，您可以通过禁用模拟的预准备语句来防止这种情况：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
这通常会产生一个真实的预处理语句（即数据是在查询的单独数据包中发送的）。但是，请注意，PDO将默默地fallback模拟MySQL无法本机准备的语句：那些可以在手册中使用listed，但要注意选择适当的服务器版本）。
这里的问题是我们没有调用C API的mysql_set_charset()而不是SET NAMES。如果我们这样做，我们会很好，只要我们从2006年开始使用MySQL版本。
如果您正在使用早期的MySQL版本，那么bug中的mysql_real_escape_string()意味着无效的多字节字符（例如我们的有效负载中的那些字符）被视为单个字节以用于转义目的，即使客户端已正确通知连接编码因此此攻击仍然会成功。该错误已在MySQL 4.1.20，5.0.22和5.1.11中修复。
但最糟糕的是，PDO没有公开Qazxswpoi的C API直到5.3.6，所以在以前的版本中它无法阻止这种攻击的每一个可能的命令！它现在暴露为mysql_set_charset()，应该用来代替DSN parameter ......
正如我们在开始时所说的，为了使这种攻击起作用，必须使用易受攻击的字符集对数据库连接进行编码。 SET NAMES不易受攻击，但可以支持每个Unicode字符：所以你可以选择使用它 - 但它只能从MySQL 5.5.3开始使用。另一种选择是utf8mb4，它也不易受攻击，可以支持整个Unicode utf8。
或者，您可以启用Basic Multilingual Plane SQL模式，其中（除其他外）改变了NO_BACKSLASH_ESCAPES的操作。启用此模式后，mysql_real_escape_string()将替换为0x27而不是0x2727，因此转义过程无法在以前不存在的任何易受攻击的编码中创建有效字符（即0x5c27仍然是0xbf27等） - 所以服务器仍然会拒绝该字符串无效。但是，请参阅0xbf27，了解使用此SQL模式可能产生的其他漏洞（尽管不使用PDO）。
以下示例是安全的：
@eggyal's answer
因为服务器期待mysql_query('SET NAMES utf8');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");
...
utf8因为我们已正确设置字符集，因此客户端和服务器匹配。
mysql_set_charset('gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");
因为我们已经关闭了模拟准备好的语句。
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));
因为我们已经正确设置了字符集。
$pdo = new PDO('mysql:host=localhost;dbname=testdb;charset=gbk', $user, $password);
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));
因为MySQLi一直都做真实的准备语句。
如果你：
要么
$mysqli->query('SET NAMES gbk');
$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "\xbf\x27 OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();
/ utf8 / latin1 / etc）要么
ascii SQL模式你100％安全。
否则，即使您正在使用PDO准备语句，您也很容易受到攻击......
我一直在慢慢研究修补程序，将默认设置更改为不模拟未来版本的PHP。我遇到的问题是，当我这样做时，很多测试都会中断。一个问题是模拟的准备只会在执行时抛出语法错误，但真正的准备会在准备时抛出错误。这可能会导致问题（并且是测试的原因之一）。
准备好的语句/参数化查询通常足以阻止对该语句的第一顺序注入*。如果在应用程序的任何其他位置使用未经检查的动态sql，则仍然容易受到二阶注入攻击。
二阶注入意味着数据在被包含在查询中之前已经在数据库中循环了一次，并且更难以实现。 AFAIK，你几乎从来没有看到真正设计的二阶攻击，因为攻击者通常更容易进行社交工程，但你有时会因为额外的良性NO_BACKSLASH_ESCAPES字符或类似情况而出现二阶错误。
如果可以将值存储在稍后用作查询中的文字的数据库中，则可以完成二阶注入攻击。例如，假设您在网站上创建帐户时输入以下信息作为新用户名（假设MySQL DB为此问题）：
'如果用户名没有其他限制，则预准备语句仍将确保上述嵌入式查询在插入时不执行，并将值正确存储在数据库中。但是，假设稍后应用程序从数据库中检索您的用户名，并使用字符串连接将该值包含在新查询中。你可能会看到别人的密码。由于用户表中的前几个名称往往是管理员，因此您可能也只是放弃了该服务器场。 （另请注意：这是不以明文形式存储密码的另一个原因！）
我们看到，准备好的语句足以用于单个查询，但是它们本身并不足以防止整个应用程序中的SQL注入攻击，因为它们缺乏一种机制来强制所有对应用程序内数据库的访问都使用安全的代码。但是，用作良好应用程序设计的一部分 - 可能包括代码检查或静态分析等实践，或者使用ORM，数据层或限制动态sql准备语句的服务层是解决Sql注入的主要工具问题。如果您遵循良好的应用程序设计原则，使您的数据访问与程序的其余部分分离，则可以轻松地强制执行或审核每个查询是否正确使用参数化。在这种情况下，完全阻止sql注入（第一和第二顺序）。
*事实证明，当涉及宽字符时，MySql / PHP对于处理参数是愚蠢的（好吧，那些），并且在' + (SELECT UserName + '_' + Password FROM Users LIMIT 1) + '
中仍然有一个罕见的案例可以允许注入通过参数化查询。
不，他们并不总是。
这取决于您是否允许将用户输入放在查询本身中。例如：
other highly-voted answer here
将容易受到SQL注入的攻击，并且在此示例中使用预准备语句将不起作用，因为用户输入用作标识符，而不是数据。这里正确的答案是使用某种过滤/验证，如：
$dbh = new PDO("blahblah");
$tableToUse = $_GET['userTable'];
$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );
注意：您不能使用PDO绑定超出DDL（数据定义语言）的数据，即这不起作用：
$dbh = new PDO("blahblah");
$tableToUse = $_GET['userTable'];
$allowedTables = array('users','admins','moderators');
if (!in_array($tableToUse,$allowedTables))
$tableToUse = 'users';
$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );
以上不起作用的原因是因为$stmt = $dbh->prepare('SELECT * FROM foo ORDER BY :userSuppliedData');
和DESC不是数据。 PDO只能逃避数据。其次，你甚至不能把ASC报价放在它周围。允许用户选择排序的唯一方法是手动过滤并检查它是'还是DESC。
是的，这就足够了。注入类型攻击的工作方式是通过某种方式获得一个解释器（数据库）来评估一些应该是数据的东西，就好像它是代码一样。只有在同一介质中混合代码和数据时才可以这样做（例如，当您将查询构造为字符串时）。
参数化查询通过分别发送代码和数据来工作，因此永远不可能在其中找到漏洞。
尽管如此，您仍然可能容易受到其他注入型攻击。例如，如果您使用HTML页面中的数据，则可能会受到XSS类型攻击。
不，这还不够（在某些特定情况下）！默认情况下，当使用MySQL作为数据库驱动程序时，PDO使用模拟的预准备语句。在使用MySQL和PDO时，应始终禁用模拟的预准备语句：
ASC总是应该做的另一件事是它设置数据库的正确编码：
$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
另请参阅此相关问题：$dbh = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'pass');
另请注意，这只是关于数据库方面的事情，您在显示数据时仍需要注意自己。例如。通过使用正确的编码和引用样式再次使用How can I prevent SQL injection in PHP?。
我个人总是首先对数据运行某种形式的卫生，因为你永远不能信任用户输入，但是当使用占位符/参数绑定时，输入的数据将被分别发送到服务器到sql语句，然后绑定在一起。这里的关键是将提供的数据绑定到特定类型和特定用途，并消除任何更改SQL语句逻辑的机会。
即使您要使用html或js检查阻止sql注入前端，您也必须考虑前端检查是“可绕过的”。
您可以使用前端开发工具（现在内置firefox或chrome）来禁用js或编辑模式。
因此，为了防止SQL注入，在控制器内清理输入日期后端是正确的。
我建议您使用filter_input（）本机PHP函数来清理GET和INPUT值。
如果您想继续安全性，对于合理的数据库查询，我建议您使用正则表达式来验证数据格式。在这种情况下，preg_match（）会帮助你！但要小心！正则表达式引擎并不那么轻巧。仅在必要时使用它，否则您的应用程序性能将下降。
安全性有成本，但不要浪费你的表现！
简单的例子：
如果你想要仔细检查从GET收到的值是否是一个数字，如果（！preg_match（'/ [0-9] {1,2} /'））{...}的重量超过99
htmlspecialchars()所以，最后的答案是：“不！PDO Prepared Statements不会阻止所有类型的SQL注入”;它不会阻止意外值，只会意外连接