当"安全盾牌"变成"数据漏勺"：.bank.in域名注册局的翻车启示录

2014年，印度储备银行（RBI）推出了。bank.in域名，目标是给印度老百姓打造一块"净土"——让大家上网找银行的时候，至少能确认自己没进错门。十多年来，这套机制看起来挺靠谱的。

直到研究人员发现，这个"安全盾牌"本身就是个漏洞，而且一漏就是13个月。

事情是这样的

安全研究人员最近挖出来一个大问题。.bank.in的注册局系统里，有一组API接口压根没做身份验证，任何人只要懂点技术，就能直接访问管理员联系信息数据库。

整整一年时间，以下这些数据就这么敞着：

• 管理员的完整姓名
• 工作邮箱
• 电话号码
• 所在银行和金融机构的详细信息

涉及5576条记录，全是负责管理印度金融网络基础设施的人。现在这些信息跟停车场告示牌上的内容差不多了——谁都能看。

最讽刺的部分来了

. bank.in这个域名本身是拿来防钓鱼的。RBI的逻辑很简单：只要你认准。bank.in结尾的网址，就不用担心碰到骗子网站。

结果呢？现在这套registry反而给骗子送了大礼——送的还是"精准制导"那种。

你想啊，对于搞诈骗的人来说，以前发钓鱼邮件跟撒网捕鱼一样，撒出去一万封，能上钩几个算运气好。现在不一样了，他们手里有的是"真名实姓+直拨号码+工作邮箱"，目标直接锁定各大银行的IT管理员。这种情报质量，做社工攻击简直美滋滋。

技术层面到底哪里出了问题

这一节主要面向技术圈的朋友，但普通读者也能看热闹。

API接口没有身份验证：说白了就是大门敞开。甭管是API密钥、OAuth令牌还是IP白名单，总得有个门槛吧。处理敏感数据的系统，连这个基本配置都没有，确实说不过去。

没有请求频率限制和监控：接口对外开放就算了，还不限流、不记录谁在访问。这就好比你家WiFi没密码，还不看路由器后台都有谁连进来。

安全审计缺位：13个月啊朋友们。按理说定期做渗透测试、上线自动化漏洞扫描，这事儿早就该发现了。结果愣是等外面的人挖出来。

访问权限管理太粗：退一步说，就算这个接口确实需要对外开放，数据返回的逻辑也有问题。为啥要返回完整的联系信息？只返回机构名称不行吗？最小权限原则懂不懂？

各位老板们该学到什么

这件事不是印度的专利，也不是金融行业的专利。任何处理敏感数据的组织——不管你是刚起步的创业公司还是大厂——都得长点心了。

1. 安全这事儿没有"一劳永逸"

.bank.in注册局当初设计这套东西，不是拍脑袋做的，人家确实认真想过。问题在于，他们以为把系统搭好就完事了。安全不是项目，是状态。你什么时候停止监控、停止测试，漏洞什么时候就摸进来了。

2. 别光顾着保护别人，忘了保护自己

这帮人天天琢磨怎么防止老百姓被钓鱼，防得挺起劲。结果呢？自家后院的管理员数据库敞着让人看。所以啊，做安全方案的时候，记得留只眼睛看看"守门员"自己牢不牢靠。

3. API安全不是可选项

现在什么都讲API对接，什么都讲微服务。很多人觉得API就是个"传数据的管道"，接上能用就行。你这么想的，黑客也这么想的。认证要上、加密要上、限流要上、日志记录也要上——甭管是给外部用的还是内部跑的，一视同仁。

4. 默认"已经泄露"来思考问题

哪怕你安全做得天衣无缝，也得假设最坏情况。那些被曝光数据的机构，现在就应该当成"骗子手里已经有这些信息"来处理。具体怎么应对？钓鱼邮件盯紧点、该换的密码赶紧换、接到奇怪的电话多问两句。

接下来怎么办

据说.bank.in注册局已经把漏洞补上了。但这件事暴露的问题远不止一个API配置错误。

它是印度金融数字化基础设施的一面镜子。如果连这个"防钓鱼旗舰项目"都能出这种低级问题，那些不太起眼的系统，谁知道还藏着什么？

管着。bank.in域名或者类似信任基础设施的机构，强烈建议现在就动起来：立刻检查你们的API接口、全面梳理访问权限、建立持续监控机制。还有——测试系统的时候，请假设对面是个想搞事情的坏人，用这个标准来审视自己的防御。

说点大的

现在这个时代，数字信任比任何时候都重要，也比任何时候都脆弱。

域名注册局、证书颁发机构、各种"信任基础设施"——这些平时没人注意的东西，其实是互联网安全的基石。它们一出问题，影响就像多米诺骨牌一样往外扩。

.bank.in这次的数据泄露，说白了就是"初心很好，执行拉胯"的典型案例。构建信任不容易，维护信任更难。你得持续投入、持续警惕，还得对自己的短板保持清醒。

给技术圈的朋友留句话：现在就去审计你的系统，别等下个季度，别等有空再说。

因为说不定此刻，就有人正在研究.bank.in的案例呢——而且那帮人可不是什么好人。

互联网的安全，靠的是那些我们平时根本不会想起的基础设施。与其指望它们不出事，不如主动出击。别让"13个月的裸奔"在你自己身上重演。