同城旅行的同城SRC（安全响应中心）上线那天，我盯着提交框看了半天。旅行不是同城因为它界面多酷，而是旅行这个平台本身——一个做本地生活服务的公司，居然愿意花钱请人来挖自己的同城漏洞。这事儿放在三年前，旅行想都不敢想。同城

那时候挖洞的旅行人分两派。一派盯大厂，同城漏洞单价高，旅行但竞争惨烈得跟春运抢票似的同城。另一派专挑小站点练手，旅行图个乐子，同城偶尔碰上个不设防的旅行，能乐呵一礼拜。同城同城旅行的资产属于中间地带——你说它大吧，比不上BAT那种体量；你说它小吧，人家在几十个城市有真实业务，酒店、门票、周边游，全链路的系统。

我花了两个晚上摸它的资产。APP、小程序、H5、后台管理系统，光子域名就扒出来四十多个。大部分是业务系统，但混着几个测试环境，直接挂在公网，nginx默认页都没改。这种疏漏其实比业务逻辑漏洞更致命——测试服务器上往往沉淀着开发人员的调试日志，里面可能躺着数据库连接串、加密密钥、甚至生产环境的跳板权限。

真正有意思的是那个订单接口。我提交了一个带特殊字符的酒店名，结果后端返回的报错信息里，把完整的SQL查询语句原封不动吐了出来。参数没过滤，报错没拦截，数据库类型、表结构、字段名，一目了然。这种低级问题出现在一个运营多年的平台上，多少有点魔幻。但转念一想，业务跑得快，安全跟不上，这是国内互联网公司的通病，同城旅行不是第一个，也不会是最后一个。

后来我提交了三个漏洞，两个中危一个低危。审核速度出奇地快，当天就给了响应，隔天就确认了等级。没有扯皮，没有“正在排查”的官方话术，直接告诉我修复时间点。这种干脆劲儿，老实说，比某些大厂磨叽半个月不回消息的体验强太多了。

同城旅行的SRC给我的感觉是——他们真把这事儿当回事。不是挂个页面走个过场，而是有专人跟进，有明确的评级标准，甚至会在漏洞详情里跟你讨论修复方案。这种互动频率，在同类平台里算得上头部水准。

但问题也藏在这儿。越重视，意味着攻击面被梳理得越清楚。当SRC把资产暴露给白帽子的同时，也等于给黑产画了一张藏宝图。我查过他们最近更新的漏洞公告，有个逻辑漏洞很有意思——改一个状态参数就能免费升级房型。这种漏洞不会造成数据泄露，但能薅羊毛薅到平台肉疼。黑产利用这种漏洞的成本极低，批量操作起来，一晚能刷几十间房。

安全这行当，从来是道高一尺魔高一丈。同城旅行SRC的诚意值得肯定，可他们面对的不是散兵游勇，而是有组织、有工具链的黑灰产团伙。我见过太多SRC上线时轰轰烈烈，半年后沦落为无人问津的僵尸页面。同城旅行能不能扛住这波攻防拉锯，得看他们后续的运营节奏和漏洞响应速度能不能一直保持这个水准。

反正我手里还攥着两个没提交的漏洞，等他们把上一个修复完再说。钓鱼要慢慢来，急不得。