@ovear

我并不在乎一个网站的帐号，但如果我让你觉得我在人身攻击你，我向你道歉。至于我 AT 你你无法收到，除了降权，可能还因为我 Block 了你。

我这么做是因为想要控制我能跟你争辩的频率，这样我不会因为太过生气。

生气的原因是这样的：

我给出的链接：
stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection/12202218#12202218

The Attack 部分讲述的是攻击的过程和方法，其实就是这个版本：
shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

主题是：addslashes() versus mysql_real_escape_string() debate。就是说在过滤数据的时候是否应该用 addslashes （这不是犯傻么？）。Blog 仍然是拿 0xbf27 来举例，字符变形到 0xbf5c27 然后进行攻击，很简单，几十年前的技术。

结论是：To avoid this type of vulnerability, use mysql_real_escape_string(), prepared statements, or any of the major database abstraction libraries. 就是说通过 mysql_real_escape_string 来避免注入，而不要用 addslashes。

于是 SO 上的回答就着这个问题衍生到了 PDO 上，然后故意没有 $pdo->setAttribute(PDO::ATTR_EMUATE_PREPARES, false); 这样当然会退回本地的模拟。

这是那个 SO 帖子的主题。下面的 Selecting a Character Set、The Payload、$stmt->execute()和 The Query 都是在讨论这个问题。这些都是进行在 MySQL 上的，而不是本地驱动。

而解决方案则列在了 The Simple Fix、The Correct Fix 和 The Saving Grace 这几个小结下，其中 The Simple Fix 小节里，作为一种提示，SO 的 PO 主提到：However, be aware that PDO will silently fallback to emulating statements that MySQL can't prepare natively: those that it can are listed in the manual, but beware to select the appropriate server version)。告诉你即使$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);之后，仍然有可能退回到本地 prepare，并且给出了档案

最后，Safe Examples、Wrapping Up 和 Addendum 对 SO 回答进行了总结。

这就是为什么我一开始觉得是不是我英语不好看漏了某些部分，因为我觉得能挑出那句话放在不应该的地方很奇怪。然而当我看过了全部链接并且提示你之后，你仍然在向我抛出“ However, be aware that PDO will silently fallback to emulating statements that MySQL can't prepare natively ”这句话，并且指责是我没有认真了看过文章并且了解原理。

我个人觉得这是对我之前所花费精力的冒犯。

当然，可能我理解错了一部分你的发言。如果是这样，非常抱歉。

@yangqi 嗯，是我的错。

但是，自从回了这个帖子之后，其他的回帖者在总结这个问题的时候，都会带上“在正确使用的前提下”这个提示。

就像我很早之前就说到的：
> 安全问题没有银弹，不要认为引入一个库或者一个方法就能解决所有问题，你还需要知道如何正确的使用它们。
>
> 综上所述，安全是个体系，而不是一条函数。你需要将所有的事情作对才是安全的。

这逆转了一开始两个盲目信心满满的“能”，我对这样的结果是满意的，只是我在这件事上并没有得到任何好处。

@yangqi

可能吧，我并没有看出

> “用了 PDO 的 prepare 处理，是不是 100%能防注入（？）”

同

> “ PDO 的 prepare 处理是否能 100%防注入？”

在这个问题上的区别。

感谢你一直和我讨论这个问题，现在我们能让它过去了么？我实在不想继续回复这个帖子。事实上，我想我应该不太会想其他的帖子了。不是厌恶，只是为了避免由于我的理解不好而引起不必要的争论。

好了，我早就开始后悔回复这些帖子了。

如果各位路过的看客在看过所有相关的内容之后仍然认为我是在“诡辩”，请麻烦按下 Block。

（如果你不愿意看相关的内容，也请 Block ）

@yangqi

不，我不觉得我有任何问题。因为（可能很多人看贴的时候忽略了这一点）其中的一个陈述：100%

PDO prepare 能防止 SQL 注入么？能
PDO prepare 能 100%防止 SQL 注入么？不能，除非你正确的使用了它

用枪能杀死一个人么？能
用枪能 100%杀死一个人么？不能，除非你正确的使用了它

不知道你是否同意上面的陈述。

// BTW: Dear FBI & NSA, yes, I just googled something like "Can I 100%ly kill a man with gun" on ... Google. It's just for this topic, I'm not actually going to kill anyone, please don't come to my door. Thank you!

如果在市区的话不要种菜之类的，城建不可能不管。

其实可以去附近社区问问看有没有合适的事可以拿来做，主要是社交之类的。

比如我们这里有个湖，一些老人平常会出来钓鱼。能不能钓到鱼说不定，但是有社交是肯定的。

或者养狗

@leeg810312 如果你在说我吹毛求疵的话，那么你真应该看看我到底说了什么：
t/362646#r_4343233

当然，大部分人都喜欢简单的答案嘛。“能”，够简单，喜欢吧？

可你在发帖的时候也带了前提：“好好写代码，避免已知 bug ”。

这跟我说的难道不一样？

@msg7086

这就是问题。

他想用指出我“有问题”，来美化当时他的疏漏而已。

所以你看，那片文章大片篇幅在说字符的事（这是那个 Po 的主题，我想你能看懂），他偏偏看不见，却能看到关于 MySQL Driver 的 prepare 兼容性警告，然后说是“ Bug ”。

这很邪恶不是么？不知道是不是仅仅是为了让自己个人主页的 Reply 好看，显得自己专业？

@ovear

所以你在证明什么？

你帖的这些东西只是我在发 4 楼那个帖子之前已经做好功课的东西。你为什么要尝试驳斥我并没有提出的东西呢？心虚？

我现在来割断你最后一根稻草吧：

The Simple Fix

Now, it's worth noting that you can prevent this by disabling emulated prepared statements:

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

This will usually result in a true prepared statement (i.e. the data being sent over in a separate packet from the query). However, be aware that PDO will silently fallback to emulating statements that MySQL can't prepare natively: those that it can are listed in the manual, but beware to select the appropriate server version).

的意思是：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
能解决这个问题。但是（就是 However 那句）需要注意，说一些 MySQL 的版本不能正确的 prepare，那时 PHP 的 MySQL 驱动会退化到本地 prepare。所以需要选择正确的 MySQL 版本来解决问题（如果你程序里有某些旧版本不支持的 prepare 在新版本里支持了，要使用新版本）（当然，也可以不写那些语句）。

要点是：这并不是 Bug，而是 MySQL 还不支持这些，所以 PHP 的 MySQL 驱动不会发送。

请问你抓包有什么用？能驳斥我哪一条观点？

建立一个“审帖委员会”相当于将原来相对集中的权利分享给更多人。原来，你只需要相信 @Livid 一个人的人品，现在你需要相信几个人甚至几十个人。所以这并不见得是一件好事。

更何况， @mornlight 所说的：

> 你说的那些嘲讽 xx 的用户，和看见别人嘲讽 xx 就不开心的用户，都不会是目标对象。

不见得完全不会，首先因为人总是会进行一些评价，什么好什么不好；其次因为人总是会有纷争。所以想要保证上面这些并不容易。

@ovear

上面我说的：
>> 另外你上面：
>> 如果你非得揪着字眼，我承认我那句话不完善
>> 应该是 在 pdo 起作用的时候，fully functional 的情况下，100%
>>
>> 我能这样看么：prepare 自己没有办法保证 100%不会注入，只有正确配置好一切之后它才能提供安全保证？

你对此说：
> 错误，只要是 MySQL native prepare，就没办法注入。特殊的 0day 之类的素除外。

这不是诡辩是什么？我建议我们还是不要经常进行这样的交流比较好。

@ovear

抓包，呵呵呵。

好，哪怕你将本地 prepare 模拟理解为“退回了 SQL 拼接”（当然，想想看确实，字符串最后毕竟是组合起来了嘛哈哈哈），但是楼主问题的预设是在 bind 和 exec 阶段，我提示的问题是在 initialization 阶段。

如果 Initialization 没有作对，那么之后的过程肯定会出问题，所以那时候的 prepare 必然不能保证安全。这没有任何问题，符合我的观点。

另外你上面：
> 如果你非得揪着字眼，我承认我那句话不完善
> 应该是 在 pdo 起作用的时候，fully functional 的情况下，100%

我能这样看么：prepare 自己没有办法保证 100%不会注入，只有正确配置好一切之后它才能提供安全保证？

我不知道你在后面拼命证明我是错的，最后得到了什么结论。

@ovear

Let's recap:

从第二层（包括你）开始两位说“能（ 100%防止 SQL 注入）”。

我在第三层说“不完全能”，有边界情况并且给出了链接。

你在第四层说：
> However, be aware that PDO will silently fallback to emulating statements that MySQL can't prepare natively
>
> 请认真朗读上句。。这是一个 bug 级别的东西，下面看评论已经提交给 php 官方了。

好，你为了支持你的管但认为这是的 Bug，没问题。我把过程解释给你看，告诉你 PO 说的是类似在没设置好字符集的情况下跑 mysql_real_escape_string 的情况（本身跟 PDO 机制如何没关系），会造成字符变形攻击。

你对我丢：

> However, be aware that PDO will silently fallback to emulating statements that MySQL can't prepare natively

这还是想证明“那是个 Bug ”并且坚持你“能”的观点还是承认原来 prepare 并不能完全阻止 SQL 注入？

另外，你在 9 楼所说

> 而你举例的这个问题在于，PHP 没有这么操作，而是因为某种原因，回退到 SQL 语句拼接了，只不过是 PHP 自动拼接的。

这根本就是错的，原因是进行了本地的 prepare，而不是退回了 SQL 拼接。

此外：

> 另外，PHP 官方已经写得很清楚了，设置 charset 的时候，要在初始化的时候进行。你错误的使用了 PDO，导致 PDO 本身失效，能怪谁呢？

是啊，“你错误的使用了 PDO ”，导致 prepare 不能 100%防止 SQL 注入，怪谁呢楼主？

我建议你直接承认你的错误，因为你在三楼敲“能”这个字的时候，无论后面你怎么说，都已经无法挽回了。

@ovear

但为什么你不翻译完？或者我们通过同一个链接看到的版本不是一个？ LOL

要点是这样的，这是那个 PO 主的 Demo：
$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));

注意，他没有用 $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

其实到这就不用看了，因为后面肯定会有问题：服务器所认为的链接字符集被设置成了 gbk，本地的未改变，而且 prepare 是在本地。

然后那个 PO 主就挑了个 Easy Target，0xbf27 => addslashes() => 0xbf5c27 （ 0x5c == '\'） => 字符串：'。

所以自然注入了。

这就是问题。所以这是一种 Charset Attack，利用字符串变形进行攻击。防御的方式也说了：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

> However, be aware that PDO will silently fallback to emulating statements that MySQL can't prepare natively

这说的是另一回事。解决方案是：beware to select the appropriate server version

希望这能解答你的疑问 :)

当然，回到楼主的问题：prepare 能保证你的安全不被黑么？答：不能。

安全问题没有银弹，不要认为引入一个库或者一个方法就能解决所有问题，你还需要知道如何正确的使用它们。

综上所述，安全是个体系，而不是一条函数。你需要将所有的事情作对才是安全的。

@ovear

或者，这只是一种 Charset 攻击，没涉及到你所说的东西。;)

@ovear

哦。好吧，我之前看的时候竟然没看出这句话与问题本身的上下文关系（事实上，现在我看了 10 次也没看出来）。英语渣表示抱歉。

@bianhua

其实上面说的不准确，new 出来的是一个 Object 的 Instance。

第一个问题：new PDO 返回的是一个参考（ Reference ），在上面的代码中，这个参考被赋值给了$db、$db2 和$db3。现在$db2、$db3 拿到了这个参考，因此通过$db2、$db3 就可以访问 PDO 这个对象。

第二个问题：PDO 本身就是个 Object，而不是 Resource。你可以将这个 Object 看成一个 Resource Representation，就像你可以建立一个叫 File 的 Object 然后在其中包裹一个 File Handle 和操作这个 Handle 的代码一样。

@maskerTUI
@ovear

感觉你们信心很足啊。

但是其实不完全能。

https://stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection/12202218#12202218