在白帽子眼中SRC漏洞处理流程一般为：
1.漏洞上报
2.漏洞审核
2.1漏洞定级
2.2漏洞分类
2.3漏洞去重，建立漏洞库
2.4奖励发放
3.漏洞修复
3.1漏洞分发
3.2漏洞处理
4.漏洞关闭
其中白帽不光可以关注在漏洞审核阶段的评级与奖励，在整个漏洞生命周期中漏洞复盘也是尤为重要的。一是总结挖洞经验，将一些琐碎的东西逐渐变成自己的一套体系；二是本着对企业负责的态度督促漏洞修复。开发小哥哥通常时间紧任务重（不光要研发新产品，上线的产品出了问题还要被diss，惨兮兮）在漏洞修复处理后，漏洞完全有二次利用的可能。
某天逛站，发现一个子域名。访问之自动重定向到/xxx/login.jsp，几个大字就这样摆在我面前
我哪能经得起这诱惑，拿起御剑，JSFinder就是一顿扫
找到一处Apache CXF的Server list
看到这么多SOAP services，手工构造接口请求包不太显示。遂用burp的Wsdler自动化解析WSDL文档，生成接口请求Demo。然后对这些Web Services接口一个个手工测试
呕吼 貌似掉进了漏洞窝，如上图挖到了n多的SQL注入以及越权，HQL注入等漏洞
一般漏洞冷却期为三个月，三月之后我又来了。还是从上个接口开始，用原来的payload先打一遍
无果，再用单引号测试报错。确定了此处注入未修复完全
经过fuzz发现她只是匹配了or后边的空格和updatexml这个函数。只要匹配到就拦截。fuzz的过程不在赘婿，精髓就是控制变量的思想。绕过updatexml很简单，将updatexml换为其他黑名单之外的报错函数即可，如extractvalue等
相对于值得分享的就是空格的绕过了，首先尝试了+，%20等发现后端不会解析
后又尝试了注释，会被无情拦截。
最终使用Tab，回车换行实现Bypass
值得深思的问题就是在发现问题后，要抓住问题的根本产生原因。从根本上解决问题
类似案例：看小灰灰师傅如何一个漏洞梅开五度https://xz.aliyun.com/t/8974
本文迁移自知识星球“火线Zone”
