文章目录

• API安全风险与防范
• • 前言
  • API安全风险与防范
  • • 未授权访问
    • 越权问题
    • 数据窃听
    • DDoS攻击
    • 资源耗尽攻击
    • 重放攻击（Replay Attack）
    • 注入攻击
    • 篡改数据
    • 代码泄漏
    • 数据泄漏
    • API URL泄漏
    • 服务端被黑
  • 攻击者的常用手段
  • API安全小结
  • 安全三要素
  • 参考文档
  • 扩展阅读

API安全风险与防范

前言

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

API安全风险与防范

未授权访问

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

防范：

前端调用后端的接口，必须由后端作二次校验，不能只相信前端页面控制；

系统对系统的接口，需要用身份认证机制（比如，appId和appSecret机制、token机制）

参见：

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

越权问题

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

防范：

不信任接口调用传入参数，必须由后端对访问作严格的权限控制，不要偷懒；

前端调用后端的接口，必须由后端作二次校验，不能只相信前端页面控制；

不相信前端传进来的和权限有关的参数（或者不要让前端传进来和权限有关的参数），而是后端自动获取当前登录用户的权限相关的信息；

后端不能只判断用户是否登录，而是还要判断当前用户是否有权限；

特别小心传入id来查询或操作的场景，一定要校验当前用户是否有该id的权限；

参见：

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

数据窃听

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

防范：

尽量在安全的网络中传输，比如内网、专线等；

采用HTTPS协议对传输过程加密；

对传输的数据进行加密。

DDoS攻击

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

防范：

采用WAF和防火墙；

采用流量清洗和黑洞技术；

设置IP白名单；

对接口调用频率和调用次数进行限制。

资源耗尽攻击

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

防范：

限制上传文件类型和文件大小；

限制分页查询时每页的最大记录数；

限制接口调用频率和调用次数；

限制其它可能耗尽服务端资源的行为。

重放攻击（Replay Attack）

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

防范：

在请求报文中加入随机数（nonce）和签名，如果随机数重复则服务端认为是无效请求；(该方法的不足是需要维护一张随机数的全表记录，如果用Redis来存储可能会占用较大内存)

在请求报文中加入时间戳（timestamp）和签名，如果请求报文的时间戳与服务端的时间差较大（比如1分钟），则认为是无效请求；（该方法的不足是在允许的时间差内，仍然有被重放攻击的风险）

结合nonce和timestamp机制（只在允许的时间差内维护随机数的全表记录，比如在Redis中随机数全表记录有效期只保留1分钟，这样就可以节约内存）；

一次性token机制，token使用一次后就失效。

参见：

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

注入攻击

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

防范：

程序和数据分离，不允许调用者来控制如何执行程序；

使用预编译SQL，而不是动态拼接SQL；

在接口入参对象中只放必要的属性，且操作时只修改必要的属性。（防止利用JSON字符串和Object自动绑定特性，来传入多余的JSON属性，来更新整个对象）。

篡改数据

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

防范：

采用API签名（sign）方式来防止数据被篡改；

客户端对请求报文进行签名，服务端验签通过后，才响应请求；

服务端对响应报文进行签名，客户端验签通过后，才相信响应报文；

常用的签名算法包括SHA256或MD5，推荐使用SHA256（哈希算法，签名不可逆计算出原始值）；

签名时需要同时考虑防止签名被预测和重放攻击，需要将nonce和timestamp一起签名，保证每次签名（sign）值都不同；

参见：

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

代码泄漏

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

防范：

不要在前端代码中存放secret等敏感信息，即使已经加密过的secret；

正确配置.gitignore，不要将一些不应该提交的代码或配置文件放到了Web服务器上，特别是前端代码；

代码中含有一些测试用的管理用的“秘密”API URL；

代码中含有一些过时且保护不当的API URL；

防止泄漏代码到互联网上，比如GitHub；

在后端服务器上，在受控的服务配置中心来配置敏感信息；

数据泄漏

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

防范：

只返回必要的数据给前端，不要依赖前端来隐藏数据；

由后端来对敏感数据进行脱敏，不要依赖于前端进行脱敏。

API URL泄漏

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

防范：

不要在API URL中放敏感信息；

尽量使用HTTP POST，来在HTTP Request body中传输参数，再采用HTTPS协议对传输过程加密；

服务端被黑

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

防范：

做好服务端安全防范工作，最小权限原则，网络隔离，开放最少端口，设置安全组，漏洞扫描，入侵检测，告警等；

客户端对服务端的返回数据也要验签，防止响应数据被篡改（比如攻击者在服务端前安插了一个代理服务器来篡改返回的数据）；

攻击者的常用手段

攻击者的常用手段：

网络窃听；

抓包工具；

Chrome浏览器开发者工具；

编写Python程序进行来请求接口；

病毒程序。

API安全小结

互不信任原则：接口提供方不信任接口调用方的请求参数，接口调用方不信任接口提供方的返回数据；

不信任网络原则：假设网络传输过程是不安全的，网络中的每一个节点都是不安全的；

采用HTTPS协议，保证传输过程安全；

作最坏的打算，即使数据被窃听，也无法解密；

设立网络安全边界，采用WAF、防火墙、网络隔离、IP白名单、流量清洗和黑洞技术来防止DDoS攻击；

使用API网关，在API网关上实现安全机制和限流，简化API实现；

采用包含了nonce和timestamp的API签名来防止数据被篡改和重放攻击；

时刻关注水平越权问题；

注意编码安全，防止代码泄漏和API URL泄漏；

安全三要素

简化的安全三要素：

• 加密（Encryption）：数据传输过程加密，敏感数据存储加密。
• 认证（Authentication）：识别是谁，定义哪些是公开资源，哪些是需要用户登录后才能访问的资源。
• 鉴权（Authorization）：允许或拒绝用户的某些操作。

参考文档

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

扩展阅读

• OWASP TOP 10
• OWASP Top 10 Web Application Security Risks

总结

以上是生活随笔为你收集整理的API安全风险与防范的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。