API安全风险与防范

API安全风险与防范

前言

本文就API安全面临的常见风险和如何防范，浅谈了一下个人见解，供API设计和开发时参考。

API安全风险与防范

未授权访问

风险：攻击者知道API地址和传入参数后，访问未授权的数据或操作。

防范：

1. 前端调用后端的接口，必须由后端作二次校验，不能只相信前端页面控制；
2. 系统对系统的接口，需要用身份认证机制（比如，appId和appSecret机制、token机制）

参见：

• 移动应用微信登录开发指南

越权问题

风险：攻击者试图访问权限范围外（水平越权或垂直越权）的数据或操作。

防范：

1. 不信任接口调用传入参数，必须由后端对访问作严格的权限控制，不要偷懒；
2. 前端调用后端的接口，必须由后端作二次校验，不能只相信前端页面控制；
3. 不相信前端传进来的和权限有关的参数（或者不要让前端传进来和权限有关的参数），而是后端自动获取当前登录用户的权限相关的信息；
4. 后端不能只判断用户是否登录，而是还要判断当前用户是否有权限；
5. 特别小心传入id来查询或操作的场景，一定要校验当前用户是否有该id的权限；

参见：

• Web业务安全测试方法（1）—越权测试

数据窃听

风险：在调用API的传输过程中，数据可能会被窃听，比如恶意WIFI、DNS劫持、网络设备被黑等。

防范：

1. 尽量在安全的网络中传输，比如内网、专线等；
2. 采用HTTPS协议对传输过程加密；
3. 对传输的数据进行加密。

DDoS攻击

风险：攻击者控制一群肉鸡，发起DDoS攻击（分布式拒绝服务攻击），导致接口被网络请求堵塞，无法正常服务。

防范：

1. 采用WAF和防火墙；
2. 采用流量清洗和黑洞技术；
3. 设置IP白名单；
4. 对接口调用频率和调用次数进行限制。

资源耗尽攻击

风险：攻击者利用接口漏洞来耗尽服务端资源。

防范：

1. 限制上传文件类型和文件大小；
2. 限制分页查询时每页的最大记录数；
3. 限制接口调用频率和调用次数；
4. 限制其它可能耗尽服务端资源的行为。

重放攻击（Replay Attack）

风险：攻击者获取一段报文后，重复多次请求接口。

防范：

1. 在请求报文中加入随机数（nonce）和签名，如果随机数重复则服务端认为是无效请求；(该方法的不足是需要维护一张随机数的全表记录，如果用Redis来存储可能会占用较大内存)
2. 在请求报文中加入时间戳（timestamp）和签名，如果请求报文的时间戳与服务端的时间差较大（比如1分钟），则认为是无效请求；（该方法的不足是在允许的时间差内，仍然有被重放攻击的风险）
3. 结合nonce和timestamp机制（只在允许的时间差内维护随机数的全表记录，比如在Redis中随机数全表记录有效期只保留1分钟，这样就可以节约内存）；
4. 一次性token机制，token使用一次后就失效。

参见：

• 防止重放机制
• https://www.kaspersky.com/resource-center/definitions/replay-attack

注入攻击

风险：攻击者传入一些畸形数据，让接口执行一些意想不到的操作。

防范：

1. 程序和数据分离，不允许调用者来控制如何执行程序；
2. 使用预编译SQL，而不是动态拼接SQL；
3. 在接口入参对象中只放必要的属性，且操作时只修改必要的属性。（防止利用JSON字符串和Object自动绑定特性，来传入多余的JSON属性，来更新整个对象）。

篡改数据

风险：攻击者获得一段报文后，篡改报文中的内容，再请求接口。

防范：

1. 采用API签名（sign）方式来防止数据被篡改；
2. 客户端对请求报文进行签名，服务端验签通过后，才响应请求；
3. 服务端对响应报文进行签名，客户端验签通过后，才相信响应报文；
4. 常用的签名算法包括SHA256或MD5，推荐使用SHA256（哈希算法，签名不可逆计算出原始值）；
5. 签名时需要同时考虑防止签名被预测和重放攻击，需要将nonce和timestamp一起签名，保证每次签名（sign）值都不同；

参见：

• 微信支付-小程序支付安全规范

代码泄漏

风险：代码或程序中含有敏感信息，当代码或程序泄漏后，敏感信息也被泄漏。

防范：

1. 不要在前端代码中存放secret等敏感信息，即使已经加密过的secret；
2. 正确配置.gitignore，不要将一些不应该提交的代码或配置文件放到了Web服务器上，特别是前端代码；
3. 代码中含有一些测试用的管理用的“秘密”API URL；
4. 代码中含有一些过时且保护不当的API URL；
5. 防止泄漏代码到互联网上，比如GitHub；
6. 在后端服务器上，在受控的服务配置中心来配置敏感信息；

数据泄漏

风险：接口返回了过多的数据，包括敏感数据。

防范：

1. 只返回必要的数据给前端，不要依赖前端来隐藏数据；
2. 由后端来对敏感数据进行脱敏，不要依赖于前端进行脱敏。

API URL泄漏

风险：使用HTTP GET调用API时，API URL上带有参数，因为API URL是明文传输的，因此网络中的网络节点都可能窃取这些参数数据。

防范：

1. 不要在API URL中放敏感信息；
2. 尽量使用HTTP POST，来在HTTP Request body中传输参数，再采用HTTPS协议对传输过程加密；

服务端被黑

风险：虽然大多数攻击都发生在客户端向服务端的调用过程，但是如果服务端被黑，也会导致客户端面临风险。

防范：

1. 做好服务端安全防范工作，最小权限原则，网络隔离，开放最少端口，设置安全组，漏洞扫描，入侵检测，告警等；
2. 客户端对服务端的返回数据也要验签，防止响应数据被篡改（比如攻击者在服务端前安插了一个代理服务器来篡改返回的数据）；

攻击者的常用手段

攻击者的常用手段：

1. 网络窃听；
2. 抓包工具；
3. Chrome浏览器开发者工具；
4. 编写Python程序进行来请求接口；
5. 病毒程序。

API安全小结

1. 互不信任原则：接口提供方不信任接口调用方的请求参数，接口调用方不信任接口提供方的返回数据；
2. 不信任网络原则：假设网络传输过程是不安全的，网络中的每一个节点都是不安全的；
3. 采用HTTPS协议，保证传输过程安全；
4. 作最坏的打算，即使数据被窃听，也无法解密；
5. 设立网络安全边界，采用WAF、防火墙、网络隔离、IP白名单、流量清洗和黑洞技术来防止DDoS攻击；
6. 使用API网关，在API网关上实现安全机制和限流，简化API实现；
7. 采用包含了nonce和timestamp的API签名来防止数据被篡改和重放攻击；
8. 时刻关注水平越权问题；
9. 注意编码安全，防止代码泄漏和API URL泄漏；

参考文档

• 移动应用微信登录开发指南
• 微信支付-小程序支付安全规范

扩展阅读

• OWASP API Security TOP 10中文项目