安全和开放是互联网世界永恒的话题，其中API扮演着重要的的角色，API的安全可以说是开放与创新的前提。随着API成为越来越多企业访问数据和服务的接入口，由API漏洞引发的安全事件时有发生，不安全的API已成为网络攻击者的主要目标之一。本期话题就围绕企业的API安全展开相关讨论：

1.通过日常的工作接触，大家认为不安全的API往往有哪些特性？
2.随着近年来API爆发式增长，让企业的攻击面频频暴露，这是否意味着通过身份安全解决方案和API网关来进行限制的方法存在缺陷或不足？有无改进方法？
3.大家认为目前的API安全架构建设还存在哪些难点，有无自己的一些设计思路？

（本文所有ID已做匿名处理）

1.通过日常的工作接触，大家认为不安全的API往往有哪些特性？

@蓝色之海

鉴权不严格导致的未授权访问或横向越权。

@长青

主要是鉴权机制不健全，其次是业务逻辑到系统逻辑的衔接和匹配问题。

第一个很容易理解，访问者的身份验证、访问请求的合理性鉴别、授权方式等；

第二个就是业务需求、系统设计到系统实践过程中产生的误差，或者考虑不完善。例如，密码重置流程，只在第一步做身份验证，后续步骤并未与相关身份进行一致性验证，就会导致冒用身份，未授权重置其他人员的密码。其他的还有更贴近业务场景的案例。密码重置这个会更通用一些。

@小豆子

可参见OWASP API Security Top 10, 技术层面覆盖的很全，推荐参考。

@卡卡

API的一些数据泄露，没有攻击特征，一般的网络攻击监控看不到。

2.随着近年来API爆发式增长，让企业的攻击面频频暴露，这是否意味着通过身份安全解决方案和API网关来进行限制的方法存在缺陷或不足？有无改进方法？

@蓝色之海

首先解决收敛暴露面的问题，大多数实际业务场景下，网关或身份安全解决方案仅能解决认证的问题，授权还是只能依靠业务应用自身。

@长青

“API爆发式增长，让企业的攻击面频频暴露”，个人认为两者呈弱关联性，数量和应用规模的增长，与攻击面是否扩大无必然联系，但是仍然呈关联性。

身份安全解决方案和API网关虽然有缺陷和不足，但并不是上述问题频频发生的主要原因。它们更具备通用性和普适性。势必无法对企业实际的业务需求考虑的面面俱，这是不可避免的。其次，个人认为相关的攻击频繁并屡见成效，更多的是在于管理人员及相关技术人员的意识和能力问题。有些风险管理人员和技术人员疏忽大意，没有考虑到位，或者旧的方案无法应对新型的攻击技巧，这都是常见情况。

改进方法自然就是全面的能力提升和意识培训，这个需要相关领域的人员一同努力，而非安全人员仅靠一方努力就能做到的。行业属性更大。

@小豆子

一个难点就是API的发现，例如部分没有通过网关发布的API，类似于资产发现，云上以后都是通过API暴露服务，如何保证API资产被及时发现跟踪管理，例如过期的API能否及时移除等等。目前可以试用API的商业工具探测管理，开源的感觉没啥用。

@风和日丽

关于改进方法：

1、身份认证

不要使用 Basic Auth ，使用标准的认证协议 (如 JWT, OAuth)。不要再造 Authentication, token generating, password storing 这些轮子, 使用标准的。在登录中使用 Max Retry 和自动封禁功能。加密所有的敏感数据。

2、JWT (JSON Web Token)

使用随机复杂的密钥 (JWT Secret) 以增加暴力破解的难度。不要在请求体中直接提取数据, 要对数据进行加密 (HS256 或 RS256)。使 token 的过期时间尽量的短 (TTL, RTTL)。不要在 JWT 的请求体中存放敏感数据, 它是可破解的。

3、OAuth 授权或认证协议

每次交换令牌的时候不要加 token (不允许 response_type=token)。使用 state 参数并填充随机的哈希数来防止跨站请求伪造(CSRF)。对不同的应用分别定义默认的作用域和各自有效的作用域参数。

4、访问保护

限制流量来防止 DDoS 攻击和暴力攻击。在服务端使用 HTTPS 协议来防止 MITM 攻击。使用 HSTS 协议防止 SSLStrip 攻击。

5、输入验证

使用与操作相符的 HTTP 操作函数, GET (读取), POST (创建), PUT (替换/更新) 以及 DELETE (删除记录), 如果请求的方法不适用于请求的资源则返回 405 Method Not Allowed。在请求头中的 content-type 字段使用内容验证来只允许支持的格式 (如 application/xml, application/json 等等) 并在不满足条件的时候返回 406 Not Acceptable。验证 content-type 的发布数据和你收到的一样 (如 application/x-www-form-urlencoded, multipart/form-data, application/json 等等)。验证用户输入来避免一些普通的易受攻击缺陷 (如 XSS, SQL-注入, 远程代码执行 等等)。

不要在 URL 中使用任何敏感的数据 (credentials, Passwords, security tokens, or API keys), 而是使用标准的认证请求头。使用一个 API Gateway 服务来启用缓存、访问速率限制 (如 Quota, Spike Arrest, Concurrent Rate Limit) 以及动态地部署 APIs resources。

6、资源处理

检查是否所有的终端都在身份认证之后, 以避免被破坏了的认证体系。避免使用特有的资源 id. 使用 /me/orders 替代 /user/654321/orders。

使用 UUID 代替自增长的 id。如果需要解析 XML 文件, 确保实体解析(entity parsing)是关闭的以避免 XXE 攻击。如果需要解析 XML 文件, 确保实体扩展(entity expansion)是关闭的以避免通过指数实体扩展攻击实现的 Billion Laughs/XML bomb。

在文件上传中使用 CDN。如果需要处理大量的数据, 使用 Workers 和 Queues 来快速响应, 从而避免 HTTP 阻塞。

关闭 DEBUG 模式。

7、输出处理

发送 X-Content-Type-Options: nosniff 头。

发送 X-Frame-Options: deny 头，X-XSS-Protection: 1; mode=block头。

发送 Content-Security-Policy: default-src 'none' 头。

删除指纹头 - X-Powered-By, Server, X-AspNet-Version 等等。

在响应中强制使用 content-type, 如果你的类型是 application/json 那么你的 content-type 就是 application/json。不要返回敏感的数据, 如 credentials, Passwords, security tokens。

在操作结束时返回恰当的状态码（如 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed 等等）。

3.大家认为目前的API安全架构建设还存在哪些难点，有无自己的一些设计思路？

@蓝色之海

还没看到可落地的API安全架构，零信任在国内只能覆盖“人”，国际大厂的系统间零信任体系很难效仿，首先需要全公司具备统一的技术栈和强大的基础设施，毕竟谷歌内部实现无缝迁移零信任也是十年积累。

@小豆子

API很多问题需要从开发测解决，从软件设计架构去改进，也就是从DevSecOps考虑安全设计入手。

本期精彩观点到此结束啦~此外，FreeBuf会定期开展不同的精彩话题讨论，想了解更多话题和观点，快来扫码免费申请加入FreeBuf甲方群吧！

加入即可获得FreeBuf月刊专辑，还有更多精彩内容尽在FreeBuf甲方会员专属社群，小助手周周送福利，社群周周有惊喜，还不赶快行动？

申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入会员俱乐部

如有疑问，也可扫码添加小助手微信哦！