@
ovear 我并不在乎一个网站的帐号,但如果我让你觉得我在人身攻击你,我向你道歉。至于我 AT 你你无法收到,除了降权,可能还因为我 Block 了你。
我这么做是因为想要控制我能跟你争辩的频率,这样我不会因为太过生气。
生气的原因是这样的:
我给出的链接:
stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection/12202218#12202218The 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_EMULATE_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 ”这句话,并且指责是我没有认真了看过文章并且了解原理。
我个人觉得这是对我之前所花费精力的冒犯。
当然,可能我理解错了一部分你的发言。如果是这样,非常抱歉。