API接口安全

现在大多数服务端都是各个 API 调来调去，权限验证，有 SSO 的、有用分布式 Session 的，我们主要业务就是几个 App，里面很多 API 调用，刚来的时候发现很多的业务逻辑问题，现在都修复了，要求涉及个人权限认证的统一使用 Session 中的字段，后台进行效验，不完全依赖前端传过来的数据，主要这个 session 是后端在登陆成功时下发的，攻击者没办法伪造。现在架构都趋向微服务，将接口拆得更细，存放的位置可能不同，session 的存放有变成了一个问题。
解决方案可以使用 JWT，比较通用，也是现在比较流行的解决方案，第一段给出了加密方式，第二段放一下用户唯一标识符，过期时间，第三段就是签名，key 在服务端，签名也是在后端完成的，后端到用户、前端到后端的中间过程攻击者就没办法修改这个数据包了，修改完了，签名不过，就不行，不过 jwt 不注意也会有一些小问题，比如禁止 none 的加密方式，如果配置错误就会被攻击者利用，因为 jwt 是每个人都可以解密的，修改加密方式为 none，这样在后台验证是就会通过，从而绕过了验证环节，jwt 对所有人是透明的，可以明文看到里面的数据，所以也不可以保存敏感信息在 jwt 字符串中，还有就是加密用到的 key 值，我之前试过 4 位数的加密 key，2 分钟就可以跑出来，16G、7 代 i5、4 核 Mac，所以设计时这个 key 需要长点、复杂点，再者可能就是销毁问题了，因为 jwt 是无状态的，可能用户退出后，这个 Token 还能用，这里有些思路，比如根据 jwt 里的过期时间来销毁。
再者就是防刷，防刷其实大部分攻击场景是反爬，之前我们有用过某云的产品，做业务风控，主要就是接口的防刷，它是怎么做的呢，第一是根据频率，有几种配置，可以在发现频率高了，web 直接推送验证码，比如图形验证码、滑块验证码，这种可能对用户体验度不好，产品那边不同意，还有就是推 js，后台用发送一些 js 逻辑，这个逻辑需要浏览器去解析运算，得到的结果跟着下一次请求发送到后端，一般的脚本刷接口就可以屏蔽掉了，可是现在 selenium、chrome driver 一些自动化软件的使用，这种也是可以绕过的，只不过成本比较高了，测试中发现，某云的接口防刷功能也是不严谨，触发规则后，浏览器算出来的这个字符串在半个小时内是有效的，那么这半个小时对于攻击者来说，就没什么门槛了，有点像 csrf token 也是这样一种逻辑，就看攻击者的技术能力了。具体还是看业务场景吧，这种我感觉和业务场景依赖比较高。
如果是客户端做的比较好的就是防范中间人劫持，进行证书验证，如果截取不到流量数据，可以说是能防范一半的攻击，安全性提高一个层次，但也会带来性能上的问题，根据实际情况进行取舍

SDL

SDL：Security Development Lifecycle 安全开发生命周期
SDL 能做可能就是周期性的面向后台人员、测试、开发进行安全意识、安全测试、安全开发培训，可以拿一些实例进行讲解，这样他们比较有兴趣。然后就是做一些安全评审、需求、开发，上线时的安全测试、主机的安全加固等等。
再就是黑白盒测试，白盒没有商用产品，就是简单的使用 sonar 中的 findbugs 做一些，质量部有 sonar 平台，代码打包就会触发扫描，findbugs 的规则自己把一些认为没用的、效果不好的就关闭掉，一些比较有用的，确实可以检测出问题的就留下来，结果的话就人工去核实，当然也可以自定义规则主要是 java 不熟悉，xpath 语法也不熟悉，就没弄。黑盒主要利用 Mitmproxy 进行数据包的获取，功能测试安装证书，配上代理，统一收集数据， Mitmproxy 自带的类很丰富，自己简单写些 python 脚本处理、格式化一些，主要是 url 的去重，保留 session 一些认证信息，这样基本可以很全的拿到带登陆太的接口数据，因为 appscan、wvs 这种对 ajax 请求没法爬取链接，就没法扫描，拿到这些构造请求发送到 arachni 扫描引擎中，通过对比 arachni 的扫描效果还是不错的，而且 API 比较详细。
剩下可做的就是应急响应了，之前会做很多的告警措施，通过告警到钉钉，人工确认，进行事件的应急，比如一些攻击者的 web 攻击，一些公开的最新漏洞，之前的挖矿病毒等等，可能在甲方不太关注应急响应标准流程步骤，但是之前会有一系列的规范，确定各个业务线的接口人，这样找起来也比较快，加上之前漏洞修复也会知道各个业务线的对应的开发、运维，碰到一些事件首先判断出事件类型，影响范围，进行网络隔离，确保不会让事件再继续恶化下去，后续会有针对恶意文件的研究，包括攻击溯源，分析脚本执行的一系列动作，最后进行加固。
当然应急响应对技术人员的要求也非常高，平时多会关注网上别人应急的一些文章，一些新漏洞的攻击手法，需要本地模拟，分析攻击的数据包，这样在应急的时候至少心里有那样一个事，看一些日志文件，以及服务、主机的弱点会想到攻击者怎么利用，这样在应急时也会很快，不至于束手无策。
参考：安全开发流程

安全评审流程

前期做数据安全的时候定义好了哪些属于敏感数据，涉及到用户传入参数对我们数据库进行操作的一些功能，产品、开发会拉上安全进行评审，比如一些接口需要不需要加密、签名、防重，权限怎么效验，敏感数据需不需要脱敏、主要是安全、法规上的一些要求，这样的话可能比较精确，也不会浪费时间。

漏洞管理实施

漏洞管理还比较好，毕竟这个是看得见的，如果不修复就会对公司业务产生影响，比较直接，有的甲方可能会有专门的运营来做这件事情，安全工程师只需要指出哪里出问题、修复后的复测，不关心漏洞跟踪，团队比较少的时候就是一个人干，发现问题在钉钉群里面发出来，每个大的业务线都有一个漏洞跟踪群，发现说一次，修复说一次，系统比较多，线上系统可能就是每个季度进行一次全面的安全测试，上线、临时项目就是另外针对性测试，有漏洞、有问题就直接落实到个人，具体哪个开发，直接过去，咱们翻代码，流程对一遍，看是哪个地方出现的问题，怎么修复，我比较喜欢这种方式，这样的效率比较高。当然、首先你的懂 java、php、go 这些语言，可能比较大的漏洞问题，涉及的人员比较多、业务复杂，就会拉上开发、产品、架构师开会，商量好方案，排期修复，修复好了，也是在群里面说一下，然后去复测。
后来搭建了一套宜信开源的漏洞管理，里面有些功能不适合我们现在架构，我就简单改一些代码，python 写的，读一遍源码，改起来也比较容易，毕竟符合公司现阶段的才是最好的。目前是还没有进行处罚制度，只需要和技术部门负责人定好漏洞的等级，各个等级漏洞多长时间修复，这个是各个负责人都同意的方案，就会在后面修复的时候比较好排期，开发都很配合，也还好。