文章来源：https://blog.chain0x0.com/blog/

序言

最近一直在研究新东西，很久没有写文章记录了，刚好把博客网站装修了一下（停运了快几个月，本来都打算下线了，但是期间有几个师傅都让我继续开着，就想着还是继续记录一下吧），刚好也可以写一篇新文章来让新老朋友参观一下。

这篇文章将记录我挖金融行业漏洞的一些思考和案例，打破一些师傅对金融行业只有逻辑漏洞的偏见。

在圈内经常听到一些观点，“现在没有SQL注入了”、“基础漏洞代码审计都能审出来，黑盒根本挖不到”、“都这么多年了XSS早都没了”、“XXE都多少年的漏洞了怎么可能还有”、“SSRF也太少了不可能有”等等论调。那么在众测（获取金融行业漏洞赏金的主要途径）中就没有除了逻辑漏洞之外的漏洞了吗？

说明一：本文观点并非说金融行业没有逻辑漏洞。

说明二：加密解密和APP调试相关技术问题不在本文的讨论范围，默认读者已经有这方面的基础知识。

金融行业特点导致的困境

在很早之前我刚学漏洞挖掘的时候听过一句话：“Learn it before you hack it.”。那么金融行业的一些特点造就了我们对他的一些偏见。

加密

可能是国家有要求，涉及金融的必须要加密传输数据（我也不是很清楚，但是确实几乎都是加密的）防止中间人攻击。

有很多师傅会觉得加密了我就测不了了，或者是稍微厉害一点的师傅就费尽心思去解密然后去测试。由于解密就花费了一些时间和精力了，这个时候就很容易疲劳，脑子里只想着可能的简单漏洞，比如直接改个ID就越权了，或者是直接滞空参数就泄露大量敏感信息了，确实这种情况也不少。但是会形成一种惯性思维，就一直去挖越权，习惯性的待在舒适圈中，有一次就有两次，周而复置，这种惯性思维越来越严重（我最开始挖越权交了也大几百个漏洞😂）。

资产少且难

资产少。众测和SRC不一样，很多众测就只收那几个域名或者一个核心APP、小程序和公众号。这种情况下要挖到漏洞都很难了，更何况是要有代码基础和需要对业务更深入理解的非逻辑漏洞。

难挖。小程序抓包和调试大家都能解决，通用一套方案，但是APP的抓包和调试很多师傅，可能是绝大部分师傅都解决不了，因为他没有一个通用的解决办法，只能从代码中慢慢去扣，慢慢去调试。确实难挖。

业务类型少

如果是银行就几乎都是核心功能（转账、贷款和理财等）或者围绕着其核心功能展开的其他功能。直接减少甚至杜绝很多特定漏洞类型，比如SSRF，银行的功能说有要向外发出请求的需求确实很少很少几乎没有。

白帽的幻觉

特别多的师傅认为众测是有门槛的，会比SRC竞争少很多，所以漏洞会好挖很多。确实是只邀请一些符合要求的白帽进去测试，但是按照我进入的这些众测项目来看，几乎都是30个人以上，甚至多的时候几百人一起测。最重要的是有时间限制，比如一周左右。

可以从三个角度来分析这个问题。

1.能进入这个项目里面的大部分人都是能挖到漏洞的，至少技术在国内白帽的中上层。虽然说每个师傅挖洞方式方法不完全一样，但也会有一样的地方。看似比SRC（谁都能挖）少了很多，其实也就是挖SRC牛逼的那些人，那些挖不到漏洞的根本对我们没有任何威胁和影响。

2.有时间限制更加加重了这种竞争的激烈，几天就结束的东西，谁都是争分夺秒的想多挖几个。

3.上文说的资产少且难就会导致其实很多人都是在看同一个东西，可能你认为比较偏的一个资产一大堆人在打，那他还偏吗？

所以说认为众测比SRC简单绝对是白帽子的幻觉。

困境的负面结果

因为上述各种各样的困境，让我们在挖洞的时候非常不冷静和疲惫让思路更加被局限，打死都不愿意相信那么大的银行/证券公司会有SQL注入、XSS、SSRF、XXE这种漏洞的存在。

质疑

上文阐述了大量的白帽确定金融行业没有基础漏洞。

直接上点截图让大家质疑一下自己的确定（随便截的别问哪些项目，有保密协议不能说，平台是漏洞盒子、360众测）。

SQL注入赏金截图：

XSS赏金截图：

SSRF赏金截图：

相信

很多师傅可能还是会有最后一丝借口。心里可能想，你挖的到，我挖不到啊，这些看起来就很难。

我从中每个类型筛选了一个案例给大家脱敏写出来。

XSS案例（今天新鲜出炉）

一个客服系统

发消息测xss

但是尖括号被挡住了

从burp里面改绕过前端限制也不行

分析js发现他会自动解开html实体化编码

用html10编码的方式绕了一下waf

弹窗的exp：

html

<iframe srcdoc=<script>alert(1)</script>>

然后加上打cookie的payload，就能直接打到人工服务的cookie了。

SQL注入案例（2025-04-13）

查保险的时候查看保险条款

直接就SQL注入了

SSRF（2026-03-24）

上传文件的时候看到一个preview路径，直接拼接访问

发现kkFileView组件

这个组件有历史漏洞（SSRF），直接打就行了

案例总结

第一个案例可能稍微有那么一点点难度，但是如果想得到这里有XSS还是非常有可能成功的。

第二个案例纯粹就是无脑SQL注入了，但是我相信很多师傅在真正挖洞的时候可能点都不会点那个功能（我带了很多学生都是这样，自认为那里没有漏洞）。因为那个位置看着太安全了，就是一个协议，大部分时候都是静态的，怎么可能有SQL注入呢，但是他就是查询了一次个人的某个属性的信息（就是这个数据包注入了）才去请求协议的内容。

第三个案例简单的都不能再简单了，但是如果想不到这个组件可能有问题也会忽视这个漏洞。

结语

很多师傅可能会直接跳过前面的部分直接看案例，如果你看到了这里真心希望看看前面的分析。

希望这篇文章能够带给大家一些思考，真心劝告少一点看见ID就改的墨守成规。多一个想法，就多一丝希望！

黑白之道发布、转载的文章中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用，任何人不得将其用于非法用途及盈利等目的，否则后果自行承担！

如侵权请私聊我们删文

END