API安全风险主动感知与度量探寻

由于应用的增加，每天大量的代码变更会带来很多潜在的安全风险，如果这些风险没有被挖掘出来带病上线，那我们暴露出去的风险就会越来越多，如何在代码变更后及时的感知到这些风险成为非常重要的事情，只有及时的感知，才能确保风险能得到检测和确认，而目前我们尚没有这样的机制来确保代码变更产生风险时第一时间展示出来并布置更多的跟进处理措施，这样就会不断地有新的风险暴露出去。

度量的目的是让我们能够清楚的知道我们的工作重点应该在哪里，不能为了度量而度量，度量或者分析后面应该跟进很多安全动作，比如新增了接口就需要及时的进行安全测试，这样就能确保每个新增api及时的得到安全测试，这样就能覆盖全部的api，同时保证了时效性。要确保覆盖度，最重要的一点就是我们需要知道我们的分子、分母分别是什么。不同的应用对外提供服务的方式不一样，基于目前B/S、C/S架构来讲，目前绝大多数风险在S端对应的后端应用上，目前对公网开放应用绝大多数还是通过rest-api的方式提供服务，后端服务除了api还有大量的rpc接口，目前来看webx、springboot、nodejs等框架类应用普及率越来越高，那么我们就拿webx为例来分享下如何做到应用风险可见，那我们思考下，一个应用在merge代码的时候可能会带来哪些安全问题，针对使用最多的java应用，我总结了两点

1 更新了pom文件，引入/消除了新的存在问题的二/三方组件

2 api或者api代码调用量发生了变化

理论上只要我们分析出以上两个变更就可以非常清楚的知道一次commit到底会不会带来新的风险，对于一些特殊场景，比如api下线，不仅仅意味着风险的消亡，同样实名制意味着我们永远不需要自动化的去更新我们的资产库或者标记数据的相应的api已不可恢复的下线。

要确保一个应用中的api/rpc接口全部得到测试，我们就需要获取到一个应用中包含的全部api/rpc接口，这是我们计算测试覆盖度的分母，而且随着应用代码的迭代，这个分母是变化的，这个分母的变化就会带来风险。所以我们需要做一个测试，通过这个测试我们可以知道我们的api/rpc接口是否正常，如果不正常，我们就需要进行修复。

（编辑：银川站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!