首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Coding
V2EX  ›  bianhua  ›  全部回复第 1 页 / 共 10 页
回复总数  192
1  2  3  4  5  6  7  8  9  10  
2017-05-21 13:14:05 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@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_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 ”这句话,并且指责是我没有认真了看过文章并且了解原理。

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

当然,可能我理解错了一部分你的发言。如果是这样,非常抱歉。
2017-05-21 12:23:02 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@yangqi 嗯,是我的错。

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

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

这逆转了一开始两个盲目信心满满的“能”,我对这样的结果是满意的,只是我在这件事上并没有得到任何好处。
2017-05-21 11:58:34 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@yangqi

可能吧,我并没有看出

> “用了 PDO 的 prepare 处理,是不是 100%能防注入(?)”



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

在这个问题上的区别。

感谢你一直和我讨论这个问题,现在我们能让它过去了么?我实在不想继续回复这个帖子。事实上,我想我应该不太会想其他的帖子了。不是厌恶,只是为了避免由于我的理解不好而引起不必要的争论。
2017-05-21 11:08:50 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
好了,我早就开始后悔回复这些帖子了。

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

(如果你不愿意看相关的内容,也请 Block )
2017-05-21 11:05:04 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@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!
如果在市区的话不要种菜之类的,城建不可能不管。

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

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

或者养狗
2017-05-21 09:01:24 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@leeg810312 如果你在说我吹毛求疵的话,那么你真应该看看我到底说了什么:
https://www.v2ex.com/t/362646#r_4343233

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

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

这跟我说的难道不一样?
2017-05-21 07:54:47 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@msg7086

这就是问题。

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

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

这很邪恶不是么?不知道是不是仅仅是为了让自己个人主页的 Reply 好看,显得自己专业?
2017-05-20 23:35:11 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@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 驱动不会发送。

请问你抓包有什么用?能驳斥我哪一条观点?
2017-05-20 23:21:07 +08:00
回复了 Livid 创建的主题 全球工单系统 关于腾讯云腾云阁 spam 事件的后续和思考
建立一个“审帖委员会”相当于将原来相对集中的权利分享给更多人。原来,你只需要相信 @Livid 一个人的人品,现在你需要相信几个人甚至几十个人。所以这并不见得是一件好事。

更何况, @mornlight 所说的:

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

不见得完全不会,首先因为人总是会进行一些评价,什么好什么不好;其次因为人总是会有纷争。所以想要保证上面这些并不容易。
2017-05-20 23:08:50 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@ovear

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

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

这不是诡辩是什么?我建议我们还是不要经常进行这样的交流比较好。
2017-05-20 22:54:37 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@ovear

抓包,呵呵呵。

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

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

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

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

我不知道你在后面拼命证明我是错的,最后得到了什么结论。
2017-05-20 22:27:00 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@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 注入,怪谁呢楼主?

我建议你直接承认你的错误,因为你在三楼敲“能”这个字的时候,无论后面你怎么说,都已经无法挽回了。
2017-05-20 21:33:00 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 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 能保证你的安全不被黑么?答:不能。

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

综上所述,安全是个体系,而不是一条函数。你需要将所有的事情作对才是安全的。
2017-05-20 20:07:47 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@ovear

或者,这只是一种 Charset 攻击,没涉及到你所说的东西。;)
2017-05-20 19:46:38 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@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 的代码一样。
2017-05-20 19:06:15 +08:00
回复了 xiaoyanbot 创建的主题 PHP 使用 PDO 的 prepare 预处理,能 100%防止 SQL 注入吗?
@jingniao

如果打印机的还原程度不高的话,打印出来再拍确实比拍屏幕要可靠一些,因为一些噪纹无法被准确还原。

二值化不一定能完全破坏水印,因为仍然可能会保留一些噪点,只是水印的值被偏移了。

但是,想要插入水印其实方法也还有别的,比如用字符间隙、行高和字体之类的东西来做标记,这样的话几乎图上的任何元素都能用来做水印了。
1  2  3  4  5  6  7  8  9  10  
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4010 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 354ms · UTC 03:58 · PVG 11:58 · LAX 19:58 · JFK 22:58
♥ Do have faith in what you're doing.