企业内部对于代码/接口的改动发现、扫描及漏洞处理时间非常短，不管是基于git hook、AST、JaCoCo或各种精准测试能力在基于代码的基础上均可以做到快速识别，而从外部测试/白帽子角度仅能从黑盒角度判断是否存在接口迭代，从漏洞的角度看接口安全性与安全团队能力成熟度成正比，即新增接口安全测试覆盖度较高，那历史存量接口做迭代是否会100%覆盖？是否更容易出现漏洞？

有幸在投入部分人力有限条件下，对电商场景从零摸索建立适配的数据安全解决方案，在相对激烈的黑灰产对抗现实情况下努力建设被动应急、感知到主动处置解决方案，经历过事件亦拿到过结果。想借用年底review的事件对相关能力做总结，文章内容均以淘系为例分析。

从威胁猎人发布的《2022年数据资产泄露分析报告》且22年多起引起舆论的数据泄露事件看，22年电商行业数据泄露仍然严重，威胁猎人的数据中看电商行业涉及的数据泄露仍在全行业TOP3中。电商行业的复杂性意味着其数据链路足够长且参与方众多，消费者敏感数据一旦离开电商平台其流转、存储及销毁等生命周期均不可控，而如发货链路下数据从平台到第三方流转在电商行业中是必不可少的一部分，导致电商数据泄露的频繁发生且长期处于高压对抗下。

之前做pypi源恶意包监控的方案中使用import hook的方式，即在load_module的过程中做hook劫持，当时该方案存在一定的局限性比如python2中exec实际是statement。最近在学习ebpf故计算利用ebpf做更加通用（pypi、npm）的类似hids的方案，利用两个周末完成相关代码实现并做部分恶意包验证，一定效果的同时也发现预期的噪声过多等问题。

timeline

从12月9号开始忙于业务侧漏洞推动，极少有时间对自己的处置做复盘和思考，文章内会隐去公司层面的处置方式注重于个人。从12月9号以来的timeline

甲方安全工程师一枚，12月9号log4j2漏洞爆发以来一直在资产排查、漏洞影响面、组件修复方案、漏洞推动一系列事情中，忙到疲于奔命，很少有时间做复盘，趁着周六简单记录这个getHost() 绕过的case:

• 2.15.0在JndiManager.lookup中强校验allowedHosts，因为2.15.0默认不会开启lookup的功能，所以对lookup侧的娇艳逻辑简单判断没有问题。

看到apisix因为request_uri导致的权限绕过在印象中nginx对于uri是做过强标准化的，不会出现类似tomcat、spring因解析不一致性引起风险，于是抽时间看了下相关的漏洞及源码

最近在业务需求下设计一个相对安全、可靠的加密算法，业务场景为

• 根据明文字符串$P_{{i}}$生成可检索密文$C_{{i}}$
• 密文$C_{i}$保存在第三方；
• 用户随机输入原明文字符串中的字符组合$W_{{r}}$获得其对应的密文串$C_{{r}}$；

最近在需求中遇到一个问题：在对hash值长度敏感的场景下如何选择合适的hash算法，生成的hash值要尽量短的同时要保证安全hash算法的安全侧基本要求。

如生成短链接目前常用的转换算法进制算法、随机数算法、hash算法三个方案中其中包含7/11位短Hash值的诉求，而目前常见的安全哈希算法的hash值基本为128/256bit。

目前笔者对于Chrome浏览器恶意插件的检测方式为行为特征结合简单的静态分析为中，如CSP对主要的应用页面的请求做拦截、告警同时检测其manfiest.json申请的权限等做简单分析。

目前CSP分析方式

工作中CSP告警主要以在线流式分析为主，同时需定义核心关注的路径： 在处理CSP告警时发现一个相对有趣的点，某个插件前一日在核心路径上有大量的CSP拦截告警，同时次日告警突降问题疑似发布新版本端上“绕过”CSP策略表现较强的对抗性，辅助通过其他方式验证该插件仍然在大量正常使用，故判定该恶意Chrome需做处置、打击。 该插件存在多个恶意行为，除因工作原因不能透露外其他分别为：Cookie获取、新增跳转路由、CSP对抗