开源框架的安全性问题，大家是如何妥善处理的

[areless]

经常一个高危漏洞爆出来便是死一大片。旧项目一般都不会去升级框架吧？比起语言版本升级，开源框架版本升级更频繁且代码兼容性更差。。。这种解决 uri route、orm 基础问题的才是一两年经验该造的私有轮子，但是现在会自己造轮子的人越来越少，熟练使用轮子的越来越多，轮子坏了真的是有共产主义社会来修理？我想未必吧？从 thinkphp 旧版大漏洞殃及 PHP 圈就可以略见一番，很多语言在走 PHP 的老路。那么不开源写原生是唯一的解决办法了？

[leafre]

你自己造轮子难道 bug 少？

[MrUser]

公式：用框架带来的收益 - 用框架带来的损失(风险) > 0 ? 用 : 不用
公司发展：小公司大多不重视安全，怎么赚钱快怎么来，等公司大了就自己开发个框架重构原来的项目。
可以用备份来转移风险。

[charlie21]

诶，一开始就不用开源软件不就没有这个问题了？

[qwerthhusn]

自己造的轮子可黑客懒得去黑，除非这个系统里面有价值的东西

公共的轮子，黑客黑完之后，骇客开始用肉鸡去撒网捕捞，逮到一个是一个

[cuzfinal]

看大厂怎么处理

[areless]

@cuzfinal 哪个大厂没有被脱裤过？何况脱裤了，大厂给的起钱，法务、黑涩会一起干，顶级黑客也顶不住啊。所以大厂的处理方案根本没有参考性。
@wukongkong salt 的原理就是服务端存 KEY 去混淆，然后用 KEY 去解。成本低，安全性高，就跟闭源是一个思路。而真正解决拜占庭将军问题的，成本高的一塌糊涂，就是区块链……
@likaka java 漏洞更多，只是背后有公司在摆平
@liprais 一两年还写不了 orm，都是项目做傻了。where id=3，update 哔哔哔，CRUD boy ……
@Raymon111111 SQL 注入是框架有关的，功能强大恰恰并不是框架的精髓，约定成俗才是，就是设计模式及理念。
@qq565999484 @shuimugan 因为熟悉，你知道哪里怎么运行的。几百几千甚至几万 star 的框架，使用者知道每个部分怎么运行的吗？
@msg7086 rails 的理念是好的，内部约定成俗。

@passerbytiny 板砖砸也怕联防报警器，早在 02 年就可以对互联网入侵进行报警举证了。

[cabing]

开源漏洞少，开源有漏洞也你也可以修复，回报给社区啊~~

[ready]

楼上都带歪了；
楼主是问如何妥善处理；
结果回答的都是该自己造还是用开源。

[expy]

楼主意思是自己造可以避免脚本小子批量自动扫描攻击？
大点的开源软件一般有功能性更新的大版本和安全性更新的小版本，选择长期支持版本够撑几年了，安全性更新一般不会打破兼容性。
旧项目如果要多年完全不动，用什么也没办法保证安全吧。

[w9ay]

首先一条定理，没有安全的系统。然后就看黑客攻击的成本以及是否值得攻击了。对于小网站来说，自己写未尝不是选择，间接提高了黑客攻击的成本而已。当然解决方案可以是试试各大安全公司的防护产品，哈哈

[shuimugan]

你提到的"因为熟悉，你知道那里怎么运行的"和安全问题其实没有很大的关联,安全问题主要是和人员的安全能力以及安全意识有很大的关系.

我就用回 PHP 举例,"根据用户输入的 url 发起请求"这个需求,不用轮子,只用内置 curl 函数,你可能觉得几行代码写出来的,然后呢?

对于这个 url 的检测,问题可多了.

先从协议开始,如果没校验协议,dict 协议可以用来探测内网无密码 redis,而 gopher 则可以构造出 FastCGI 协议,攻击 PHP-FPM,使其执行任意代码.

当 url 的域名指向内网的时候,则可以探测内网无保护的 http 服务,比如探测 Elasticsearch.
当你尝试先校验一下域名是否指向内网的时候,DNS-rebinding 了解一下?

在你没有安全技能和安全意识的情况下,就算你对自己的代码很熟悉,你也完全不知道漏洞在哪里.而当你有安全技能和安全意识的时候,你在开发对应功能的代码时,你就会自然而然地做很多防御手法,以及 review 你依赖的轮子它的内部实现.

最后,OpenRASP 的实现方式可以了解一下,通过和 runtime 结合的形式,对于函数的入参做检测,可以在 runtime 层做防御

[no1xsyzy]

@areless SQL 注入是框架有关还行？请先自己写一个 PHP 拼接 SQL 字符串的页面，然后直接把地址给进 sqlmap，看看没框架注入存在不？ SQL 语法有改变不？
/*!union*/ 绕过 WAF 试试？如果你不进行 AST 等级操作靠字符串拼接不可能存在没有漏洞的情况。

salt 和 闭源 和 拜占庭将军问题 三个完全根本没有关系的东西也能扯一起说？
你闭源的信息量能超过 salt 这个密码学安全随机数的？
你闭源但对所有人用同一个程序…… 你知道 salt 必须对每个账户重新生成吗？不重新生成知道了 salt 值又可以做彩虹表了。
拜占庭将军 这种容错性问题（信息一致性问题）还能和渗透安全性混为一谈？

[areless]

@no1xsyzy 有关系的呀，salt 是现在 api token 的基础。无状态全靠 salt。怎么不能混为一谈了？不用什么高深的技术。约定使用 int 来歪脖传参，根本就不需要去搞什么防注入预执行，类型绑定搞其他类型一点意义都没有~~~用算法全部取整，约定成俗~~~=_= 约定成俗的力量才是最好的，这是 rails 框架让我学习到的知识。
@shuimugan OpenRASP 是不错的东西。学习到了
@expy 你怕不怕过去交付的项目，一访问彩旗飘飘被挂着马。未来会有大量这样项目。随着版本号升级，旧的逐个要么彩旗飘飘，要么爆着一长串路径~~~正所谓程序员不堪入目的过往吗

[no1xsyzy]

@areless https://jwt.io/ 这里哪里有 salt ？
你以为用 int 传参就没事了？ string->int 都存在过任意代码执行漏洞。
DNS 约定用 UDP 请求 TCP 同步，现在不还是随意污染？ HTTP 约定 cache-control 不还是一大堆瞎缓存的 ISP ？约定 DNT:1 结果不还是一堆无视 DNT 头进行跟踪的？
不要和任何无法保证永远的利益一致者进行约定。你要约定不如直接约定：黑客不要来黑我的网站。