遵循还是自创标准的困惑

  • A+
所属分类:WooYun-Zone

(之所以发PHP是因为自己比较熟悉这个领域,而这个问题好像又没有对应的其它领域)

一年前曾经内部PK一个API参数传输方案的时候,个人不同意架构师提出的自创方案(不过原因不是安全方面),认为应当采取业界广泛应用的事实传输标准。但因为没有经验无法举例证明其问题,故最终PK失败(PK内容细节可见这里)。现在回头看,自己是对的,自创方案在后面的其它产品就再没使用,而PHP Hash Collisions Ddos直接将这个自创方案送入了地狱。

之所以想起这件事,是因为在今年2月份的时候研究过一些手机应用的API通讯,发现其自创标准者众,但似乎有些没有考虑到安全性的问题;而另一方面,钓鱼wifi和http明文传输协议的冲突也在wooyun不断曝光,场景在变导致原有标准不适应现在的安全需求,“don’t roll your own”在这种场景转换下完全失去了说服力……以上总总,让开发者们时常感到困惑——遵循还是自创标准,真是一个问题。有关博文写了纲要,但因对安全研究不透,老觉得是不是写错了什么。所以想问问各位,遵循还是自创标准之间的界限是在哪里?或者这么讲,在确定使用一个标准(无论是已有还是自创)后,是否只需要确定好使用场景,就认为是安全的?

遵循还是自创标准的困惑

  1. 1#

    xsser | 2012-03-30 15:15

    顶,我赞成这个意见!标准是经过很多实际的案例证明的,自己实现的如果场景较为单一问题还不大,如果环境发生变化就可能导致很多难以估计的问题

  2. 2#

    牛奶坦克 (青春作伴好还乡) | 2012-03-30 15:29

    标准是历经了很多考验的,其中涉及也包含众多情况的思考;而自定标准的对象可能仅仅是我们眼前的这一切,还是有着思维局限性的。

  3. 3#

    GaRY | 2012-03-31 22:00

    赞楼主的第一帖。基本同意楼上的意见,补充两点:
    1、自创不是不可以,你看所有现行标准不也都是从自创内容逐渐演变成标准么。不过建议要有大公司那种环境,这样可以早期就多做考验,避免考虑失衡;另外要开放,让其他人可以帮助完善你的私有标准,这些都是为了解决更多接受现实考验的问题。
    2、推荐使用标准的还一个原因是,即使出现问题,标准也会更快的出现通用的解决方案(例如http-》https),解决之比私有内容自己查找思考要花费的成本相对较低。

  4. 4#

    horseluke (微碌) | 2012-04-01 00:37

    @GaRY @牛奶坦克 @xsser 先多谢各位的解答,其实大家的意见都比较一致,就是应该尽可能的遵循广泛实践的标准,即所谓“don’t roll your own”。但是有些时候如果碰到场景限制的时候,得自创标准时,新的注意点除了场景,还有哪里?我贴出的文章草稿其实是想用这样的一个现实案例来说明遵循和自创的两难:

    一个通用建站程序需要开发一个用户注册的手机API(/api_mobile/user/login),初期设计如下:业界事实标准的HTTP API通讯方式;HTTP POST;参数email,password,login_type。请求包如下:

    POST /api_mobile/user/login HTTP/1.1
    ……
    [email protected]&password=123456&login_type=1&appkey=123456&api_ver=1&timestamp=11111111&sign=23rasfas

    则此时由于http协议固有的明文传输,在钓鱼wifi下就会遭遇信息泄露的问题(wooyun已有相关案例)。

    如果沿着遵循标准的思路来讲,最好的机制当然上https(先不考虑“万能证书”的威胁)。但很可惜的是,通用建站程序在这个步骤上存在着场景限制而不能执行——不可能要求每个站长都可以申请到可信证书。于是乎有人想到加密敏感参数再传输:
    enc_data=加密方法(‘[email protected]&password=123456′);

    POST /api_mobile/user/login HTTP/1.1
    ……
    enc_data=加密数据字符串&login_type=1&appkey=123456&api_ver=1&timestamp=11111111&sign=654safag

    而这个自创标准就可能存在数个问题:加密算法有问题导致轻易破解;加密算法有问题导致容易遭受中间人攻击解密;enc_data相同内容不变可被用于重放攻击;enc_data控制不良可能导致Hash Collisions Ddos……而以上的这些问题,怎么看,似乎难以轻易地归为场景问题?

    PS:@GaRY 你的第一点意见似乎就是“开放设计原则”(开放设计原则规定机制的安全性不应依赖于机制设计与实现的保密性)?第二个意见确实提醒了我应该关注思考的成本问题,比如Oauth 1.0到2.0。

  5. 5#

    GaRY | 2012-04-06 11:54

    @horseluke 这个场景未必算什么自创标准吧。你这只是传输的数据内容自己做了加密。和传输本身标准或对应的api接口无关,也没有修改到什么RESTFUL之类的原则。如果硬要说加密算法是自创的问题,对应的加密算法是否找个开源或者强大的算法,我倒是觉得无所谓,不用这么较真,投入产出也得成比例不是。还是继续考虑实现成本和受攻击可能性的对比。

  6. 6#

    horseluke (微碌) | 2012-04-06 12:17

    @GaRY 可能我这个例子没有讲明白,我在发布的博文中详细阐述了:http://www.iirr.info/blog/?p=899
    你讲得对,成本和攻击可能等也许是自己想太多了,这个度还在掌握中。

  7. 7#

    紫梦芊 ( ̄. ̄) | 2012-04-10 17:18

    HTTPS

  8. 8#

    蟋蟀哥哥 (̷ͣ̑̆ͯ̆̋͋̒ͩ͊̋̇̒ͦ̿̐͞҉̷̻̖͎̦̼) | 2012-04-19 01:50

    1.不重复造轮子.节省大量工作.并有经验可寻
    2.站在巨人的肩膀是,很多东西不用自己考虑.创建之初就为你考虑好了.