API它的全称是Application Programming Interface，也叫做应用程序接口，它定义了软件之间的数据交互方式、功能类型。随着互联网的普及和发展，API 从早期的软件内部调用的接口，扩展到互联网上对外提供服务的接口。调用者通过调用 API，可以获取接口提供的各项服务，而无须访问源码，也无须理解内部工作机制的细节。
API 它是预先定义的函数，为程序之间的数据交互和功能触发提供服务。调用者只需调用 API，并输入预先约定的参数，即可实现开发者封装好的各种功能，无需访问功能源码或理解功能的具体实现机制。
API通常包含如下组成要素：通信协议、域名、版本号、路径、请求方式、请求参数、响应参数、接口文档等。
API它是程序开发的基础，特别是系统API函数，通过系统自带的API函数可以快速实现程序开发的功能，现在高级语言也都是基于语言特性进行封装各种便于程序开发的API接口，这样就减少了开发者对具体功能的实现，只要直接调用API函数就可以快速实现功能了。但是API的虽然方便了开发，但是也同样存在和暴露出很多安全的风险问题。API的安全风险有被直接HOOK风险、安全漏洞风险、安全攻击风险。
API安全它是由多种安全规则相互交叉，它主要表现是以下三部分:
信息安全：聚焦于信息保护，这种保护包括信息的创建、存储、传输、落还、以及最终销毁的生命周期。
网络安全：解决服务两方面问题，如何保护通过网络传播的数据流以及如何防止未授权的网络。
应用安全：确保设计和部署的应用可以对抗攻击、防止误用。
API 在开发、部署过程中，不可避免会产生各种安全漏洞，这些漏洞通常存在于通信协议、请求方式、请求参数、响应参数、访问行为等环节，面临外部、内部威胁。例如，外部攻击者利用API未授权访问非法获取数据、API参数校验不严谨而被非法篡改。应对外部威胁的同时，API也面临着内部威胁。
API 接口在设计之初未对 API 接口访问频率做限制，使攻击者在短时间内可以进行访问大量 API 接口，这就产生了高频访问行为，这在很短的时间就可以完成如营销作弊、恶意注册等攻击，甚至可能带来 CC 攻击。
OWASP梳理总结的10大API安全风险
1、无效的对象级别授权
API倾向于暴露那些处理对象识别的端点，造成了广泛的攻击面访问控制问题。在每个能够访问用户输入数据的功能中，都应考虑对象级别授权检查。
2、损坏的用户身份验证
身份验证机制通常实施不正确，从而使攻击者可以破坏身份验证令牌或利用实施缺陷来临时或永久地假冒其他用户的身份。损害系统识别客户端/用户的能力会整体损害API安全性。
3、过度的数据泄露
开发人员倾向于公开所有对象属性而不考虑其个体数据敏感性，依靠客户端执行数据过滤并显示。
4、缺乏资源和速率限制
API一般不会对客户端/用户可以请求的资源大小或数量施加任何限制。这不仅会影响API服务器的性能，从而导致拒绝服务（DoS），而且还为诸如暴力破解之类的身份验证漏洞敞开了大门。
5、功能级别授权损坏
具有不同层级、分组和角色的复杂访问控制策略，以及管理功能和常规功能之间的模糊不清，往往会导致授权缺陷。通过利用这些问题，攻击者可以访问其他用户的资源和/或管理功能。
6、批量分配
将客户端提供的数据(例如JSON)绑定到数据模型，而没有基于白名单的适当属性过滤，通常会导致批量分配。无论是猜测对象属性、浏览其他API端点、阅读文档或在请求有效负载中提供其他对象属性，都是攻击者可以修改权限之外的对象属性。
7、安全性配置错误
最常见的安全配置错误是不安全的默认配置、不完整或临时配置、开放的云存储、错误配置的HTTP标头，不必要的HTTP方法、跨域资源共享（CORS）以及包含敏感信息的冗长错误消息导致的。
8、注入
当不受信任的数据作为命令或查询的一部分发送到解释器时会发生注入缺陷，例如SQL、NoSQL的命令注入等。攻击者的恶意数据可能会诱使解释器执行非预期的命令，或未经授权访问数据。
9、资产管理不当
与传统的Web应用程序相比，API倾向于公开更多的端点，这使得文档的准确性和及时更新显得尤为重要。健康的主机和最新的API版本能够有效减轻诸如API版本过期以及调试端点暴露之类的安全问题。
10、日志和监控不足
日志和监控不足，再加上事件响应的缺失或无效集成，使攻击者可以进一步攻击系统，长期驻留，并横向移动到更多系统以篡改、提取或破坏数据。大量入侵调查研究表明，检测到入侵的平均时间超过200天，而且入侵检测警告通常来自外部第三方，而不是企业内部安全流程或监控来检测。
API安全同时在应用安全方面除了参考借鉴OWASP安全风险，同时在面对系统自带API的一些安全漏洞，还要面临一些系统API被HOOK而改变流程的风险。这个是逆向工程的的常规实现方案，这个在软件开发过程中也需要重点关注和应对。
API安全测试主要是对其API的安全性、正确性和可靠性进行测试，以确保产品符合安全要求。它的测试需要包含用户访问、加密和身份验证。API 安全测试从定义要测试的 API 开始。测试工具使用各种规范格式（包括 OpenAPI v2/v3、Postman Collections 和 HAR 文件）提供有关 API 的输入和输出的信息。
API安全测试是一个很复杂的领域，API 的安全测试为手动、自动和混合活动带来了新的挑战。通常API安全测试需要静态分析工具和动态分析工具相结合，在API安全测试中可以基于常见API安全漏洞如 SQL 和 OS 命令注入、授权/身份认证旁路、路径遍历问题和 OWASP Top 10 API 漏洞进行重点安全测试。
静态分析工具，可以有效地识别特定于语言的软件安全问题，或者众所周知的注入攻击类别，继续对API繁重的代码库有效，但前提是这些工具也对用于公开这些API路由的库和平台进行建模。
在API安全测试的时候，也推荐使用OWASP Zap 和Postman 进行API安全测试，同时下面的几个github是可以值得借鉴应用的。
https://github.com/roottusk/vapi
2、API endpoint爆破
https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content/api
3、越权的测试
https://github.com/PortSwigger/autorize
API安全应用应重点通过API的安全漏洞，然后进行做API安全对抗方案的研发和策略制定，API安全应用同时应满足机密性(确保信息只能被指定的用户访问)、完整性(防止未授权的创造、修改和删除)、可用性(当用户需要访问API时、确保是可用的)。
API安全在应用安全方面可以重点关注语言的安全的编码规则、熟悉软件常见的安全漏洞、加强管理访问API的系统和应用凭证。
例如加强对一些系统内部自带的敏感操作的API函数进行保护，可用自实现的方式防止被直接挂钩系统函数而破坏了功能流程。
API安全中在网络安全方面可以重点关注防火墙、负载均衡、反向代理等并使用安全的通信协议(例如https)确保通信中数据安全。
在API安全实践应用中可以遵循以下的一些规则，提高API安全性。
每个 API 都应该使用传输层安全(TLS)来防止数据泄露。虽然这引入了证书管理的复杂性，但现代平台正在转向集成证书解决方案以简化采用。
对于具有已知身份的内部用户，API密钥可用于简化对API的访问，而无需 OAuth2 的复杂性，只要密钥得到安全管理。
3、不要将任何 API 密钥提交到源代码存储库，如有必要，请使用秘密管理解决方案。
4、使用授权中间件来标准化访问控制并避免损坏的功能级授权漏洞。
5、确保对 API 密钥使用精细的权限，以避免提供不必要或意外的访问权限。
6、如果你开发的软件有特别复杂的授权要求，请考虑使用标准库，不要重新发明轮子并增加复杂性和维护问题。
7、使用标准授权模式降低复杂性，同时利用客户端进行密集处理，减少给客户端返回数据量。
8、在软件中强化对日志记录的实施，并确保采用标准模式，有利用后续日志信息的审查和优化。
API安全性已日渐成为了网络应用方面的主要技术需求之一。开发人员需要进一步加大对于API业务模型、分析能力、技术蓝图、以及合规性与标准化方面的深入研究与开发。
通过自动化、多样化的API网络攻击，黑客不仅可以达到消耗系统资源、中断服务的目的，还可以通过逆向工程，掌握 API 应用、部署情况，并监听未加密数据传输，窃取企业数据。
安全架构设计有很多的安全设计原则，比如公开设计原则、权限最小化、开放最小化、默认不信任等。所以在API安全设计过程中也可借鉴参考这些安全性原则。
在API安全中也需要重点关注下API安全的整个生命周期：设计、开发、测试、上线运行、迭代、下线。这个生命周期中会出现的API非法调用、API安全漏洞、API数据泄露问题。
结束阅读
【推荐阅读】
点个在看你最好看
如有侵权请联系:admin#unsafe.sh