FreeBuf甲方群话题讨论 | 聊聊企业API安全

FB客服

发布于 2022-04-12 09:32:17

4190

发布于 2022-04-12 09:32:17

文章被收录于专栏：FreeBufFreeBuf

安全和开放是互联网世界永恒的话题，其中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 等等）。