加密算法被破解而导致的漏洞，能按内部已知+通用漏洞忽略吗？

原创 棉花糖糖糖 棉花糖fans 2025-06-03 10:11

今天上午某src群中有关于漏洞审核相关的讨论，相信师傅们也已经看到了，本文将打码所有相关信息，以防未知的风险。

首先是提交漏洞的师傅的消息：

image-20250603172638708

随后src审核方面发了如下图片，并说：“给你解释过了 不在多余解释”

image-20250603172804215

提交漏洞的白帽发言：

image-20250603173010260

后续沟通：

image-20250603173157926

截图内容：

image-20250603173233776

审核方最终回复：

image-20250603173257028

OK那么以上就是简单的全过程，相信有很多师傅短时间理不清，没关系，我给大家梳理一遍。

以下为根据仅有的信息梳理出的内容：

首先白帽提交了六个漏洞，为破解请求包加密算法后，更改相关参数，导致的越权、任意用户密码修改、信息泄露等等漏洞，本次提交的漏洞皆忽略，但已修复。

据白帽方的说法，该src资产在21年时就已经有参数加密的安全手段，可通过hook改参数，后来又采取了加壳的安全手段，再次被调试出加密算法，继而挖出漏洞；在24年末该白帽也提交过同类的越权漏洞，与本次提交的类型一致，也是破解加密算法后更改参数而导致的漏洞。

src方的看法是这样的:破解加密算法后更改参数，这是一类通用攻击手法，以往已收取过类似漏洞，内部对该攻击手法梳理后，发现涉及接口较多，考虑重构。

在白帽角度中，src方收取了漏洞并修复，但忽略，理由是扯淡的已知+通用漏洞。

在src角度中，该攻击手法已知，从大体的安全角度考虑，需要重构相关系统从而杜绝此攻击手法，故在此期间，不应收取这类漏洞。

棉花糖角度中，勾八src尼玛的有什么事能不能提前说，老是你买了个表的交了洞才说，这种事后解释而造成的误会不在少数了，我可以理解src业务方发现这种攻击手法太通用了想彻底杜绝，我也可以理解业务要彻底整治这种世界通用的攻击方法，想要做好所有系统的安全而非简单的通过加密参数来防护，话说到这里我很好奇这咋重构，系统始终会不安全，换加密方法无异于脱裤子放屁。

哪怕src提前公告说暂时不收因参数加密算法被破解而导致的漏洞，虽然这很扯淡，但我们可以理解，要收什么类型漏洞是src说了算，我们不能强求人家必须要收什么洞，但你得提前说清楚….而且相关人员一定要专业，
从事网络安全的人一定要懂网络安全。

这次漏洞的审核处置也有问题，就算按src方的理解，相关白帽提交的漏洞最差也是破解了同一算法而导致的，按规则应该归类为一个漏洞，而非忽略。

不能简单的用这种想法：“加密算法破解—>通用+以前提交过加密算法破解导致的漏洞->内部已知=忽略”，这个算式参数里面少了一个“已提前公告”。

对此，你有什么看法？欢迎留言讨论

广告时间：棉花糖会员站介绍(25年5月16日版本)

☟上下滑动查看更多