产品安全

### 0x01 不睡魔女 提问：您好，公司想请外部第三方安全公司做下外部渗透，有哪些靠谱的第三方安全公司推荐吗？

答：长亭科技，web渗透比较强，其他的乙方大厂都能做，360，齐安信，绿盟，安恒，启明这些，可以多找几家，然后对比对比，选一个性价比高的，多找几家交流交流，然后让他们投标，这样能省点钱，也能选个相对不错的。
公司是一方面，主要是做实施的人千差万别，高手去渗透和菜鸟去是不一样的，最好按效果付费，这样对于甲方来说比较好。
如果单纯是为了过公安部的要求，可以选一家有资格且便宜的就行，如果只想要效果，可以试试众测的模式，按效果付费，集大家之力，能发现不少问题

不睡魔女：倒是考虑过众测，就是对众测平台的安全性和保密性有点怀疑？另外有合适的众测平台推荐吗？

myh0st 回复 不睡魔女：据了解，众测的都是通过vpn之类的接入，会有流量审计，众测平台也不少，具体可以接触接触厂商，让他们来解决你的疑问。

白帽子众测平台也不少，补天，漏洞盒子，漏洞银行等，可以都跟他们接触聊聊，看看他们是怎么解决安全性和保密性的问题。

## Web 防护

我们的 web 防护有 waf, openrasp, db ids, webshell, host ids 五层，waf 表层防护，openrasp 深层防护

不过可以讨论一下，在进行红蓝对抗或者外部渗透前，会让高层以及受检查方签署风险同意认知书吗？搞等保前都签吗？

渗透前，还真的要签风险确认书，至少正规机构要求签，等保不会，等保很少搞生产环境

数据库锁死，业务缓慢。简单说，有的系统，ping一下就死的那种也可能会遇到，端口扫描，url扫描，组件扫描，漏洞扫描，依次递进，有的系统什么都不提供或者提供不出来，数据库用户弱口令5次就锁

如应用数据访问控制要求，主体是应用层账号，客体是数据库的表/字段/记录。手机话费套餐数据是一些合作输出的数据。很多反欺诈厂商和大厂用这个识别手机的可信度

“能够在开发前期的需求、设计阶段，充分考虑并采取安全控制措施及手段，保证开发编码的交付安全，至少包括前期的安全需求分析、安全控制分析、安全的流程、功能的安全保障和安全功能的设计。”

1，包含全部宾客信息的数据库，应该是CRM之类应用系统的核心数据库。

2，该数据库应该只能被CRM访问，万豪酒店人员通过该CRM访问数据（这叫应用内访问）；当然DBA可以直接进入Oracle实例执行Select（这叫应用外访问）

3，如果第三方工具通过CRM对外开放接口访问数据，这也叫应用内访问；第三方工具不应该直接访问Oracle实例

安赛亲测半年作为waf补充蛮好，waf用的impreva，瑞数听吴总介绍过两次也不错，统计分析看着像splunk改的

## 漏洞修复流程

![](/media/202201/2022-01-17_151552_846795.png)

有流程，有角色定义，还要问题定级标准，还要有对应级别的通用修复时间要求及通报机制。

1，是不是漏洞扫描计划需要数据中心经理一级审批或者变更审定会审定？

2，漏洞下发前是不是要进行预评估？然后再“漏洞分发”，相关业务部门做“漏洞确认”或“漏洞评估”。

3，安全员和业务方都无异议的漏洞直接进入“漏洞修复”；存在异议的漏洞上报上级部门进行“漏洞申诉”或者“漏洞再确认”，确认是否重要漏洞?是否可修复?等

4，逾期未修复漏洞上报数据中心经理

5，所以漏洞都要入库，只是入库的标签不同

## API 安全

![](/media/202201/2022-01-17_152543_370118.png)

爬取、竞对、密钥泄漏、数据泄露追溯，还有未知开放，冷接口

1. 获取api定义，rest，soap？前者 swagger，后者 wsdl 关注
2. API连接，双向tls，单向tls，签名报文，安全网关tls session，验证（xss.csrf等）
3. API架构注册，登记内部API库，加入监控列表，是否按架构要求接入，API过期有效追踪
4. 认证，是否，满足公司内要求，仅双向tls，还是客户端ID/secret，API key，OpenID模式，触发下一介评审，三方provider
5. 授权实现，access token? 需要关注如URI等实现是否有控制，此外关注日志记录
6. 传输层加密，每一跳的加密是否实现，是否满足公司要求，是否存在中间路由解密的可能，关注证书，加密算法，CRL等应归属常规开发要求
7. 其中 http 头关注，如content -type. cord. 等是否正确格式书写或有安全控制，如 js

## 网站架构

如果不强调交易中台，重点就放到逻辑分层（如前端、后端）和各基本安全功能（如认证、访问、授权、加密）方面设计；如果强调交易中台，就由交易业务架构基础上，设计各组件、接口的安全控制措施，重点放在定义场景的安全架构。

按照逻辑分层设计可以参考X805，按安全功能设计可以参考CC、OWASP，按照场景设计可以参考NIST、OSA等

我一直觉得dos拿抗d设备防还有点用，ddos对绝大部分带宽还不到1g公司来说，一打就满，只能靠外部流量清洗，或者指到大带宽的cdn，靠设备基本没用

## 代码审计

请教个问题，除了fortify，有没有什么比较好的代码扫描工具？希望这个工具能内嵌到开发平台中，基本能在开发中做到准实时提醒，谢谢

eclipse，IDEA，可以在Git提交的时候自动做findbugs，sonar和IDE本身的代码检测

像findbug这些能集成在ide中，在编译时介入，或者c语言代码类的在makefile中捆绑

北京有一家啄木鸟公司，产品叫codepecker，是做源码静态分析的产品，可以约下聊聊。

有些需要改变开发习惯的，就是需要在代码中打桩的，效果会好点，但是开发需要增加一部分工作，这个不太推荐，建议可以在提交svn, 编译这些环节介入

checkmarx这边了解的按系统数量收费的，不太好采购，正在使用fortify和findbugs，fortify效率不是太高

先前调研过某些iast产品，厂商称能检测到某些开源组件的漏洞，按我理解这个在运行时应该能检测包名，但是某些漏洞都是细分版本，这个要在运行时能检测出来，那得靠细分的特征，这个特征库的维护工作就很大了吧，不知道有没有了解的

这个 跟检测出来所有的攻击差不多了。 我觉得就是常见的一些开源组件  用的多的  ，毕竟防御这个东西没啥银弹，不能靠着一招就把所有事情给做了

所以 要配合 赵老板说的agent收集+ 代码库管理 + 出了poc 后收集poc特征进行流量监测 + 平时的宣传 ，这些做到位了  基本上来说 ，差不多了吧

## 漏洞监控

正向输入，开源组件引入评审，品牌型号录入，反向输入，代码库inode爬取组件，漏扫扫存在的服务和组件

漏洞获取，爬cve，爬cnnvd，买安全服务，人工监测资讯手工补充

匹配，compass等开源系统实现

机制，业务重要性，利用可行性，影响，评价高中低危，缓解措施先行，持续收敛，管理通报评价

比较重要的还是要先梳理内部资产，知道有哪些组件、应用系统版本。这样才能有针对性进行自查

需要一个多维度的安全资产库：加入安全属性和安全的维度

（例如：CVE攻击的可能性、漏洞与CVE的关系等，楼上老师说的组件中间件等）确保资产信息的完整性

自动化的方法目前看到的是两类，一类是自动化扫描的，有漏扫，资产探查。第二类是漏洞管理平台，主要是流程自动化。

微微说一句哈，漏洞监测我觉得是先有后优，公司资产可能一时半会搞不定搞不全，一头扎进资产梳理的大坑里，可能会爬不出来，一开始可能只能覆盖待上线代码，走正规流程采购的设备，承认局限性，但是搞了就比没搞的更加知己知彼，就能先出成果，先获得认可和进一步的资源，用外部反馈来逐步促进完善，不至于说等上级主管部门通报了再大家赶紧自查一下呀明天反馈，起码能每一次都走在监管前面，领导就会觉得这事交给你是兜得住的，能更有力量去把这件事做好

做总比不做强，一入资产深似海，资产和漏洞或风险可以分开做，先解决资产有的问题，在逐步完善优化，分阶段高，我们先做IT资产，现在慢慢过度到数据资产，每个阶段的目标不同解决的问题也不同。漏洞或风险可以再资产的基础做漏洞或风险发现，如自动化引擎，定期检查资产的安全问题。

资产管理等这些我喜欢分期搞，第一期一般是一个月，必须出一点可以看到的成绩，汇报也好给其他部门看也好，后面搞二期三期就有人支持了。

前年，我和同事想推IT资产评估（先把资产搞清楚，然后再评估风险），被领导给否了。

去年搞过一个安全管理平台，先后搞了机房，硬件，ip端口，dns和系统归属，第三方组件版本，github，cve，供应商到期提醒。。。。

这个话题确实有点大，主要拓展下脑洞 ，必须得分段聚焦。资产的安全属性梳理，只是想持续性保持资产安全这样的一个结果。

不要通过资产解决所有问题，这个依赖公司的基础设施管理。可以一阶段先解决资产准确定位到人，二阶段在说安全属性

系统在哪里，有安全漏洞，在上面修修补补，不如建一个修好漏洞的系统，把数据迁移过来。这样把漏洞修补问题变成数据迁移问题。不过漏洞管理不管是修补，大家觉得是漏洞发现重要，还是漏洞修补重要？我觉得后者。

感觉这么多年还有这些基础问题，不知道安全的规划建设进步在什么地方？

技术不成熟才成本高，如果能快速构建系统，其实小修小补的成本比构建一个系统成本高。

## 鉴权相关

不是所有业务平台，有些采买的由于有独立的鉴权体系，不适合接入。一般自研的都会尽量要求接入，通过 API 或 SDK 方式提供接入方式，再鉴权模型上通过 RBAC+ABAC 的方式对功能和数据鉴权，最复杂的就是商户系统中对机构、渠道、岗位、职级等各种复杂的组合需求，这些基本上都可以通过不同数据维度的方式抽象成相对通用的模型，当然理解起来可能没有那么直观。

这才是实际运营里难的地方，也是需要经验的地方。微信就做的很好，这么多年，大家很少听说微信的水平越权啥的吧，其实这里就是一个典型的有解决方案，但是很多人不知道或者推不动的事情，正是运营要发力的点。

我倒觉得难点不在于后台的统一权限系统，而是权限如何合理分配使用。目前权限分配的按照权限分级的方式走不同的审批流程，但是说句实在话，这个申请是否合理，也不好评估，一般是 Leader 和 Owner 说明理由并审批过后也就通过了。另外就是定期梳理每个系统的低频帐号或异常帐号，给相关领导进行公示和审阅，然后定期清理这些废弃帐号。低频、冷权限都好处理，一个逻辑下去就行

## 公用组件

我两年前研究过 fastjson，jackson，gson，fastjson 和 jackson 类似，架构比较相似，gadget 通用，但是 fastjson 相当坑，为了方便牺牲了安全性，包括前期的默认打开 autotype 机制，中期的 cache 机制，代码实现都是 kpi 赶出来的，像最近的 dos。gson 的安全性相对于前两者要好很多。用 jackson 的只要不打开 autotype，问题也不大，可以自己封装一层 jackson，将默认的不安全实现给禁用，目前我们就是这么处理的

建议把常见的开源组件拉一个安全补丁或版本更新频率的表，做下数据分析，然后和研发谈一个尺度，更新频率最高和最低 top5 的，都不得用，且年更新低于 3 次或年更新高于 10 次的，不得用，且xxxxx......

一般是，业务上提个功能要求，然后让评估有没有啥安全风险，安全说不行，风险比较大，不能这么用。。业务说不行，非得用，安全不安全我们不管，不安全你们的想办法让他安全，安全隐患不是我们考虑的事。

## 开发安全

一要建立制度和规则。制度和规则要求安全团队从立项时就参与项目，中间需求、设计和测试评审阶段要参与评审；要与研发的CMMI过程管理融合，修改过程管理制度；制度和规则主要起到管理作用。

二要改造流程，一是项目管理流程，二是ITSM流程。在项目管理流程中把安全需要参与的过程加进去，在ITSM中的变更流程中加入安全控制的环节，安全检测不过不允许上线。

三要组建安全开发运营团队，持续改进工具中涉及到的场景、不断总结归纳标准组件和标准解决方案；不断优化完善流程，参与到各个研发项目中。

补充两点。第一，针对需求分析平台定为的问题，我们将其定为“知识平台”，解决“知”的问题，以工程化的方式解决开发安全管理内容标准化的问题。即使刚入职的同学也能利用这个平台快速的掌握相关知识，解决安全需求提不出来，提不全面的问题。目前我们没有把这个平台定位为落地、流程的工具。从我中心试运行情况看，效果不错。研发部门认可这份安全需求。

第二，安全适用性问题。这个平台的建设分享的意义是帮助我们中小机构提升开发安全能力的平台，适用于安全团队人员少、专业能力不统一，且研发团队依靠外包的情况，属于开发安全体系建立起步阶段的平台。像您提到落地、是否真正实现等问题，其实无法依托这个平台去解决，就像我们不能用汽车登月一样。目前我们还是依托研发部门的安全测试团队进行安全功能的测试。我们安全团队把控上线前的检查关，做到我们检测能力范围不“带病上线”。开发安全的管理能力需要一步一步提升。

“知”这个对开发人员来讲有帮助，有些对安全没啥概念，对于安全人员刚开始没概念的时候确实能帮助不少，需求较为全面，但是撇开基础场景的话平台自身是匮乏满足不了的，还是得自己不断提出优化，当然这是个过程，只能说有这么一个建模平台

您说的很对，针对于您提到的“某舜”平台需求场景不丰富的情况，我们也发现了。不过目前好处是交付了我们管理模式和方法，内容方面他们针对owasp排名前十的应用安全漏洞的解决思路还是不错的，我们也利用其他机会让其他大厂评估了需求基线。但是针对创新型产品的安全需求开发的确不足，这也是我们在我们行业内提出“共建”的目的，想多收集需求场景，集中威胁建模开发安全需求，不断丰富。