注：没看《“假漏洞”到“不忘初心”》可以先点击查看，后再看此文。

今天看到《Harbor 未授权漏洞的背后是魔幻的荒诞主义》，感觉作者是看了我的文章后，认同我的一些观点，又不太认同我的一些结论，所以可能出现了“魔幻荒诞”的印象，所以就简单来个后续，看能不能打破这种印象 ...

1、可以看出来作者本身还在纠结这个问题不是产品的“漏洞”，是用户的锅，做产品太难了不能要求我产品为傻逼用户负责。实际上我的文章里要表达的核心是：大家都需要为自己的用户或者客户负责而努力[当然在实际中不得不承认这个是我作为一个“现实理想主义者”的自欺欺人]。在这个问题上Harbor本身有很大的优化空间，当然文章里也用了我的默认安全“尽可能的安全设置作为默认设置“ 观点来“反驳”，也就是建立项目的时候public并不是默认，另外强调建立项目的时候有个感叹号提示用户，由此认为官方是产品设计本身的需求而且非常尽力了。实际上我是觉得可以做得更好，比如在选择public的时候弹个窗啥的。当然我这里只是举个栗子！

2、在我那篇文章里用的功能的角度去评估的，实际上在《我的安全世界观》https://dokumen.tips/documents/superhei-.html 里还有一个权限的维度评估视角，在这个例子里实际上也可以用来很好的解释，也就是没有考虑“注册用户”与“匿名用户”的权限等级区别，当然这个本身就是官方自己的产品原始设计public项目就是对互联网上的匿名用户开放，那么是不是应该考虑这个功能存在“滥用”的场景，也应该思考下有没有更好的方法，是不是可以思考下usergroup进行细分呢，现在不行，未来是不是可以加上这个需求呢？

3、类比其实都不太靠谱

用php exec函数来比喻，实际上是不ok的。实际上php曾经考虑过这个问题并做了优化，比如安全模式（当然后面安全模式被废弃），还有函数禁用功能。另外exec这个函数本身的认知是可靠的，所以我文章里那个例子是用10年+前的一个“新”出现的函数is_a()例子，PHP当时也是进行了“优化”的（实际上那个文章里也提到exec的类比问题）。

“从产品的角度上来想，我觉得这类的安全问题，并不是一个产品上能够 cover 的事情，而是用户意识上的安全。类比弱口令，如果我们真的认为，默认复杂的密码就可以解决弱口令的问题，而没有关注用户自身意识的安全建设，那么对于安全意识较差的用户来讲，他甚至可能会觉得默认密码过于复杂而吐槽产品，然后自行将密码修改为了弱口令。为什么一个开源的产品，明确写的特性，明确写的功能提示，还需要为用户的安全意识建设买单？”

这个类比也是有问题的，实际上我文章里提到的默认口令的问题，不是“说产品默认的弱口令有问题，而默认一个复杂强大的问题口令就没问题”，而是说默认口令本身就是产品问题，默认考虑你管你多复杂，本身就是弱口令。关于弱口令的问题，可以看看《基于网络空间搜索引擎的通用漏洞挖掘》https://paper.seebug.org/1282/ 那么在产品角度怎么优化解决呢？比如我看到近年来，很多设备就开始让你默认出场口令登陆后强制更改的这种就是非常好的优化等等

所以猪猪侠还吐槽过 “弱口令都没解决的下去关注APT关注0day” 才是真正的魔幻荒诞！

4、不是说我特么的免费开源了，你们还特么的吐槽！在安全问题上我们见过太多这样的开源社区项目了，以至于我提出了“官方不可信”的观点。参考：《Web应用安全之殇》 http://www.hackdig.com/08/hack-25432.htm 

作者可能觉得这是在难为产品，是在搞“对立”，实际上在《我的安全世界观》最后提到了“最短路径”的防御思想能解释这个问题，首先安全是一个整体，安全防御是一个相对概念，所以最接近产品本身属于最短路径防御，有很多时髦词语叫“安全左移”，“安全右移”，“安全到处移” ...

当然我更加期待对于开源项目等官方应该还需要具备“用户量越大责任越大”的觉悟！

另外建议下大家，在写文章的时候还是写上参考，熟悉我的人可能知道我本身对那些不写参考或著名来源的文章非常反感，以至于原本不打算补充此文的！

可能还有一些人认为，我这种老jj写这种文章有点针对欺负某个新人的印象，而且我发现有一些小伙也好像也不太愿意直接找我沟通交流，这可能也存在一些多老年人的鄙视或者担心被鄙视。其实大可不必，因为我针对的是所有人 ...

最后作为一个“现实的理想主义者”，希望能为拯救更多的傻逼伟大目标奋斗终身！