首页   注册   登录
 bianhua 最近的时间轴更新

bianhua

  •   V2EX 第 207436 号会员,加入于 2016-12-24 18:07:24 +08:00
    算法:(数列||矩阵)问题求解
    问与答  •  bianhua  •  2017-05-15 14:58:57 PM  •  最后回复来自 wuyukai
    8
    「#3 on Trending」来,自己组装个 iPhone 玩
    分享发现  •  bianhua  •  2017-04-14 08:41:21 AM  •  最后回复来自 bianhua
    2
    摩拜最近貌似很拼啊,短信每天一条几乎
    互联网  •  bianhua  •  2017-04-10 00:21:58 AM  •  最后回复来自 wclebb
    11
    无聊的楼主做了盘菜玩 doge
    美酒与美食  •  bianhua  •  263 天前  •  最后回复来自 lfs9azh
    24
    @18616942091 兄弟,你为什么要用我的手机号注册 V2EX?
    寻人  •  bianhua  •  2017-01-14 20:02:29 PM  •  最后回复来自 gdsagdada
    5
    bianhua 最近回复了
    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 就不开心的用户,都不会是目标对象。

    不见得完全不会,首先因为人总是会进行一些评价,什么好什么不好;其次因为人总是会有纷争。所以想要保证上面这些并不容易。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   鸣谢   ·   2957 人在线   最高记录 3541   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.1 · 24ms · UTC 06:23 · PVG 14:23 · LAX 23:23 · JFK 02:23
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1