我们一起聊聊 API 安全

api(Application Programming Interface)应用程序接口，可以应用于所有计算机平台和操作系统，以不同的格式连接数据调用数据。比如，用户可以跟踪电商平台购买的货物位置，就是电商平台与物流公司之间使用了API位置实时调用产生的效果。

许多组织更关注于快速的API和应用程序交付，而忽视了API安全保护，这也是近几年来API攻击和数据泄露的主要原因。本文将从API常见类型、API攻击、API安全测试、API安全建设这几个角度做简单分享。

常见API类型

分类	描述	安全现状
公有型API	支持任何人从任何地方访问服务，被暴露在互联网中	网络限制少，认证和授权可能存在，可能不存在
开放API	频繁出现在金融业相关的开放银行倡议中，促进特定行业的创新和提高服务整合	认证和委托授权都是有的
私有型API	通常在数据中心或私有云网络环境中部署和运行，以运营管理、内部服务支撑为主	认证和授权可能存在，但是也有可能认为攻击暴露面有限，而被忽视
合作伙伴API	向特定的外部供应商提供对内部API的有限访问，以推动数字供应链	访问程度控制权位于内部和外部API之间，可能通过API网关管控，但缺少安全方面的考虑

API攻击

说到API攻击不得不说，开放式Web应用程序安全项目(OWASP)的非营利组织，多年来应用安全十大排名在安全行业中经常被引用。

在2019年，OWASP发布了API Security Top 10，描述了十个最常见的API缺陷。

它作为培训和提高认识的辅助工具非常有用，也可以作为一个轻量级的分类标准，对API中的问题进行分类，下面将从用例和预防展开说明。

1.API1:2019-失效的对象级别授权

攻击者在 API 调用中将自己资源的ID替换为属于另一个用户的资源的 ID。缺乏适当的授权检查允许攻击者访问指定的资源。这种攻击也称为IDOR(InsecureDirect Object Reference) 。

用例：

API 调用参数访问的资源 ID /api/id1 /financial_info 。
攻击者将其资源的 ID 替换为猜测的另一个ID /api/id2/financial_info 。
API 不检查权限并允许调用通过。
如果可以枚举ID，问题会更加严重/api/000-999/financial_info 。

预防：

基于用户策略和继承关系来实现适当的授权机制。
不要依赖客户端发送的ID，改用存储在会话对象中的ID 。
检查每个客户端访问数据库的请求授权。
使用无法猜测的随机 ID (GUID) 。

2.API2:2019-失效的用户身份验证

较弱的API身份验证允许攻击者冒充其他用户的身份。

用例：

· 被视为“内部”的未受保护API· 弱密码、纯文本密码、弱哈希密码、共享密码或默认密码· 缺失验证码或没有账号锁定机制，攻击者可以对同一用户账号进行暴力破解· URL中包含令牌凭证和密码· 接受未签名或弱签名的JWT令牌(“alg”:“none”)，或未校验令牌过期时间。

预防：

· 检查所有可能的方式来对所有API进行身份验证· 使用标准身份验证、令牌生成、密码存储和多因素身份验证 (MFA)· 使用短期访问令牌· 验证您的应用程序(以便知道谁在与您交谈)· 对身份验证使用更严格的速率限制，并实施锁定策略和弱密码检查· 使用OWASP Authentication Cheat Sheet(身份验证备忘单)https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md 。

3.API3:2019-过度的数据暴露

API可能会暴露比客户端合法需要之外的更多数据。

用例：

API返回完整的数据对象，因为它们存储在后端数据库中。
客户端应用程序过滤响应并仅显示用户真正需要查看的数据。
攻击者直接调用API并获取被过滤掉的敏感数据(嗅探抓包) 。

预防：

永远不要依赖客户端过滤数据!· 检查API的响应，确认其中仅包含合法数据· 仔细定义所有API响应的模式· 识别所有敏感数据或个人身份信息 (PII)，确认其使用的合理性· 执行schema-based响应验证机制作为额外的安全措施。这种机制定义并强制检查所有方法返回的数据，包括错误信息。

4.API4:2019-资源缺乏和速率限制

API无法防止过多的调用和载荷大小。攻击者会使用拒绝服务 (DoS)，造成API无响应或不可用。

用例：

攻击者通过发送超出其处理能力的请求来使API过载和阻塞。
请求时某些字段超出API可以处理的范围。

预防：

定义适当的速率限制· 限制有效载荷大小· 添加对压缩比的检查· 定义容器资源的限制(内存、CPU、文件描述符和进程) 。

5.API5:2019-失效的功能级授权

攻击者找出“隐藏”的管理API方法并直接调用它们。

用例：

一些管理功能作为API公开，如果非特权用户知道，他们可以在未经授权的情况下访问这些功能。
可以是发掘的URL，或者使用不同的参数/api/users/my_financial_info —> /api/admin/all_info 。

预防：

默认拒绝所有访问。
确保所有管理控制器都从管理抽象控制器继承，抽象控制器根据用户的组/角色实施授权检查，只允许对属于相应组或角色的用户进行操作。
正确设计和测试授权。

6.API6:2019-批量分配

在API中容易利用批量分配，因为，它们通过设计公开了应用程序隐含的实现方法以及属。

性名称。现代框架鼓励开发人员使用来自客户端的输入自动绑定到代码变量和内部对象中的功能。攻击者可以使用这种方法来更新或覆盖开发人员从未打算公开的敏感对象属性。

用例：

攻击者可以通过仔细阅读配套文档，来推测出对象的属性、查找到不同的 API 端点、或在请求负载中发掘额外的属性，进而对它们进行篡改。

· 与权限相关的属性：user.isadmin、 user.isvip仅应由管理员设置· 与流程相关的属性：user.cash仅应在付款验证后在内部设置· 内部属性：article.created_time仅应在应用程序内部设置。

预防：

不要自动绑定传入数据和内部对象。
仅将客户端可更新的属性列入白名单。
使用内置功能将客户端不应访问的属性列入黑名单。
在设计时精确定义在请求中接受的模式、类型，并在运行时强制执行它们。

7.API7:2019-安全配置错误

API 服务器的不良配置允许攻击者利用它们

用例：

缺少最新的安全补丁，或者系统已经过期。
未受保护的文件和目录。
缺少传输层加密，使用过时或配置错误的TLS 。
暴露存储或服务器管理面板。
缺少CORS(跨域资源共享)策略或安全标头。
带有堆栈跟踪的错误消息。
启用了不必要的功能。

预防：

在所有环境中持续评估配置和设置有效性的自动化过程。为了防止异常追踪和其他有价值的信息被传回攻击者，如果可以，定义和强制使用统一的API响应格式，包括错误信息。
禁用不必要的功能。
限制管理访问。

8.API8:2019-注入

攻击者通过任何可用的注入方法(如，直接输入、参数、集成服务等)向API提供恶意数据，并期望这些恶意数据被发送至解释器执行。

用例：

攻击者发送恶意输入以转发给内部解释器。
SQL· NoSQL· LDAP· 操作系统命令· XML外部实体。

预防：

永远不要相信你的 API 消费者，即使他们是内部的。
严格定义所有输入数据，例如模式、类型和字符串，并在运行时强制执行。
验证、过滤和清理所有传入数据。
定义、限制和强制执行 API 输出以防止数据泄漏。

9.API9:2019-资产管理不当

攻击者通过发现API的非生产版本(例如，临时的、测试版或更早期的版本)，他们没有如生产环境API那样受到良好保护，将通过这些渠道进行发起攻击。

用例：

DevOps、云、容器和 Kubernetes 使多个部署变得容易(例如，开发、测试、分支机构、旧版本等) 。
为了保持向后兼容性，迫使旧的API继续运行。
旧版本或非生产版本未得到适当维护，但这些端点仍然可以访问生产数据。
一旦通过一个端点进行身份验证，攻击者可能会切换到生产端点。

预防：

保持所有API主机的最新清单和未知API的能力。
限制不应对外公开的任何访问。
限制对生产数据的访问，并隔离生产和非生产数据之间的访问。
实施API网关和安全检测产品。
淘汰旧版本的API或旧版本程序安全修复。
实施严格的身份验证、重定向、CORS 等。

10.API10:2019-日志和监视不足

缺乏适当的日志记录、监控和警报会导致攻击和攻击者被忽视。

用例：

日志不受完整性保护(没有生成任何日志、日志级别没有正确设置、或日志消息缺失足够的细节信息) 。
日志未集成到安全信息和事件管理 (SIEM) 系统中。
日志和警报设计不佳。
公司依赖手动而不是自动化系统。

预防：

记录失败的尝试、拒绝访问、输入验证失败或安全策略检查中的任何失败。
确保对日志的标准化，以便其他工具也可以使用。
包括足够的细节来识别攻击者。
避免在日志中包含敏感数据，如果需要这些信息用于调试目的，请对部分信息进行脱敏处理。
与SIEM以及其他监控和警报工具集成。

中文详细参考链接：

http://www.owasp.org.cn/OWASP-CHINA/owasp-project/OWASPAPITop102019.pdf

API安全测试

在左移的API安全实践中，一个重点是确保构建管道的安全，需要企业将安全工具嵌入持续集成/持续交付(CD/CD)中，以及基于git的开发人员工作流程中。以下列出了两类安全测试工具。

1.静态应用安全测试(StaticApplication Security Testing，SAST)

用于分析原始代码的潜在弱点和漏洞，通常在代码被提交到版本控制或构建阶段时运行。

GitHub code scanning、Coverity Scan Static Analysis、reshift、Xanitizer、HCL AppScan CodeSweep

2.动态应用安全测试(DynamicApplication Security Testing,DAST)

用来分析运行中的应用，以发现可利用的漏洞，通常在生产交付前启动，或在生产中持续使用。

开源软件：OWASP ZAP、StackHawk、Arachni、sec-helpers、OWASPPurpleteam 。

缺点：当然以上工具也有其弱点，比如SAST工具误报率会较高，涉及人工复核成本。DAST工具运行时间会较长，需提前预留时间，以免耽误发布。

需要承认的是扫描器工具并不能用来检测所有类型的问题，比如一些滥用的业务逻辑缺陷。

来源参考：

https://owasp.org/www-community/Free_for_Open_Source_Application_Security_Tools

API安全测试实践

1.API安全测试的小技巧

https://github.com/inonshk/31-days-of-API-Security-Tips
https://cloud.tencent.com/developer/article/1805577

(以上链接的中文翻译)

2.开发安全的API所需要核对的清单

https://github.com/shieldfy/API-Security-Checklist/blob/master/README-zh.md

API安全建设思考

架构设计对于有效的保护API安全至关重要，架构中需要具备捕获和分析所有API流量的产品。

需要有丰富的数据引擎、基于API Security Top10威胁、算法识别等技术来检测暴露的分析，并进行有效的拦截，以及提供加固补救措施。

流程和人员设计同样重要，在发现、测试和保护API时，补救措施以及各内部角色和第三方组织的协同。

1.安全产品与环境无关

需要支持现代云架构和传统的基础设施架构。

2.API资产和攻击检测能力

由于API发开、API集成和第三方API依赖，使得API清单不断发展，必须有不断识别API端点和参数(不仅是IP和主机名，还需要功能、路径、信息主体)，未知影子API，过期或者废弃的僵尸API。特别是敏感数据发现能力，比如个人身份信息，因为这块会涉及监管合规问题。持续检测数据权限、口令认证等缺陷，并能及时感知API的攻击存在。

3.集成能力

能够与负载均衡、API网关、WAF、漏洞管理平台(VM)、DevOps套件、ITSM等平台集成。

4.API代码分析

在生产交付前扫描可能存在的缺陷，以减少攻击者发现可利用条件的可能。

5.人员能力

API安全专业知识可能分散在开发、基础设施、运营、安全或者API产品团队中，需要去梳理，以便在发现、测试、保护和事件响应方面进行合作。

来源：新钛云服

链接: https://fly63.com/article/detial/11579