API安全

jimmyleeee

已于 2024-04-20 20:06:25 修改

阅读量551

点赞数

分类专栏： web安全文章标签：安全

于 2023-09-20 17:23:17 首次发布

本文链接：https://blog.csdn.net/jimmyleeee/article/details/132908213

版权

web安全专栏收录该内容

8 篇文章 0 订阅

订阅专栏

1 API的简介

API代表应用程序编程接口，它由一组允许软件组件进行通信的定义和协议组成。作为软件系统之间的中介，API使软件应用程序或服务能够共享数据和功能。但是API不仅仅提供连接基础,它还管理软件应用程序如何被允许进行通信和交互。API控制程序之间交换请求的类型、请求的方式以及允许的数据格式。例如，智能手机上的天气应用程序使用API从提供天气信息的服务中获取每日天气信息。为了向用户及时提供天气更新，手机的天气应用程序通过API与该系统通讯。API就像应用或者服务的代理人使得应用可以与其他应用进行通讯，执行在线的任务。

随着云计算的出现以及单体式应用程序向微服务的转变，API已经变成数字世界的一个关键的元素。API可以是的应用程序可以相互交换信息，增加了应用程序的互联性。可以将一个大的应用分解成很多小的应用，这些小的应用可以通过API进行通信，完成一个大的业务流程或者功能。由于独立的业务被分开开发，再结合敏捷开发模式，是的业务的拓展变得越来越容易，也越来越快。

由于API的出现，加速了当今的应用的创新的速度。特别对于Mobile和IoT设备的发展，API是最关键的一环，成为现代应用程序的重要组成部分。

API可以使用具象状态传输(Representational State Transfer, REST)或简单对象访问协议(Simple Object Access Protocol, SOAP)构建，REST是一种用于开发web服务的架构风格，因其简单性而流行;SOAP是一种允许应用程序的分布式元素进行通信的消息协议。SOAP可以在各种低级协议上传输，包括与web相关的超文本传输协议(HTTP)。

2 API的类型

根据不同的标准实现的API，也可以分为：REST API，SOAP API和GraphQL API等。根据API提供接口的服务对象的不同，可以分来内部接口和外部接口，也可以成为公共接口和私有接口。

虽然内部接口和外部接口面向的威胁不一样，但是，还是建议能够根据统一的安全架构提高所有的API的安全性。因为，内部的接口可能被外部的接口调用，这样就等于内部接口可以间接被外部调用，内部接口如果有漏洞可以被利用，也可以通过外部接口来发起攻击。

3 API的安全

由于越来越多的业务逻辑通过API来实现，API也就接触到了应用程序内部的核心数据，如PII（个人身份信息），它已经成为基于Web的互动式的应用的程序的关键。API安全涉及企业数据的机密性、完整性和可用性。一旦API受到攻击，可能导致企业敏感数据泄露、业务中断甚至声誉受损。

此外，API安全还关系到用户隐私的保护。因此基于用户名和密码的基本的认证已经不能满足API的安全需求，更多的会使用各种各样的安全token，例如：MFA和API Gateway等。它也越来越多地成为攻击者的目标。随着，越来越多的攻击者更加关注API，尝试通过API的漏洞来攻击系统，因此由API的安全导致的攻击和安全事件也愈来愈多。

近年来，也发生了许多著名的API攻击事件，如Twitter API攻击、Equifax数据泄露等，都表明API安全不容忽视。

API的安全不仅需要通过网络层来保护，而且需要在实现层进一步保护。在实现时，针对恶意的输入进行严格地检测，识别出恶意的流量并丢弃，这样才能保护通过API传输的数据的保密性、有效性和完整性。

4 API安全的重要性

随着API的普及，API相关的安全问题也越来越受关注。根据调查https://rapidapi.com/report/state-of-enterprise-apis的调查结果可以知道，所有的参与调查的人都认为成功地执行API安全对公司的发展和成长很重要。这意味着API正在成为大多数现代应用程序的支柱，因此它们的安全性是现代信息安全的核心。

根据Salt Security的数据，在2022年，94%的组织的产品线上的API遇到了安全问题，五分之一的组织由于API的安全漏洞而遭受数据泄露。

API作为大多数云原生应用程序的后端框架，包括移动应用程序、web应用程序和SaaS以及内部、面向合作伙伴和面向客户的应用程序。由于API暴露了应用程序逻辑、资源和敏感数据(包括个人身份信息(PII))，因此它们已成为攻击者的目标。如果攻击者能够访问未受保护的API，他们就可以破坏业务，访问或破坏敏感数据，并窃取财产。

提高API安全性很重要，因为它可以防止一些常见的攻击，例如跨站点脚本(XSS)、SQL注入、代码注入，以及保护敏感数据不被泄露。总的来说，API安全性对于API及其支持的程序的成功和安全性能至关重要。

5 常见的API安全问题

OWASP TOP 10也在最近几年针对API安全出了一个TOP 10，专门列出了过去一段时间威胁最大的10个类型，可以参考https://owasp.org/www-project-api-security/。这里简单罗列出最新的10大威胁如下：

API1:2023 - Broken Object Level Authorization

API2:2023 - Broken Authentication

API3:2023 - Broken Object Property Level Authorization

API4:2023 - Unrestricted Resource Consumption

API5:2023 - Broken Function Level Authorization

API6:2023 - Unrestricted Access to Sensitive Business Flows

API7:2023 - Server Side Request Forgery

API8:2023 - Security Misconfiguration

API9:2023 - Improper Inventory Management

API10:2023 - Unsafe Consumption of APIs

除了OWASP TOP 10之外，API也会受到常见的网络方面的攻击：DOS，DDOS，MITM,等。

6 API安全的最佳实践

前面列出了API的安全威胁很多，针对不同的攻击类型需要有不同的预防措施。本章主要讲讲预防这些威胁的一些最佳实践。

第一、要有一个清理的API列表。

系统有哪些API，哪些API是向外的，哪些API是针对内部提供服务的，要有一个清晰地列表。与资产管理类似，首先要有一个清单，然后才可以管理好清单里的资产。如果一个API不在清单里，也没有被使用，在采取保护措施时，就很容易被遗漏。这种没有保护的API正是攻击者喜欢的对象，很容易利用它突破系统的防护。

现在有关于API Discovery的工具，可以在工具的协助下，在实际的运行环境上搜索出所有的API，根据API的属性进行分类，统一管理。

第二、启用HTTS协议。

使用HTTPS协议不仅可以保证数据在传输过程中的保密性和完整性，而且，还可以有效地预防MITM攻击。特别是传输敏感信息时，例如：登录使用的用户名和密码，保密性尤其重要，因为它是整个应用的最重要的一层保障，没有这一层保障，程序的安全性就无从而言。

应用中可能管理着不同类型的数据，需要将这些数据分类分级管理，对于比较敏感的数据，需要严格审查每一个API是否必须返回这些数据？如果没有必要，是否可以删掉。

曾经在做渗透测试时，有个Web应用在用户列表页面的API的响应消息中，返回了所有用户的加密的密码，而且这个信息又不显示在页面上，这种做法就是画蛇添足。

第三、使用统一的安全的认证和授权架构。

在OWASP TOP 10的前六名中，有五个是和认证和授权有关的，【API1:2023 - Broken Object Level Authorization，API2:2023 - Broken Authentication，API3:2023 - Broken Object Property Level Authorization，API5:2023 - Broken Function Level Authorization，API6:2023 - Unrestricted Access to Sensitive Business Flows】。由此可知，认证和授权问题的危害之大。使用统一的架构可以有效地实施认证与授权管理，例如：OAuth2 or JSON web tokens (JWTs)。架构可以针对每一个请求进行认证和授权的检查，判断该请求是否有足够的权限访问当前的资源。

关于认证与授权，可以关注我的其他博客：https://blog.csdn.net/jimmyleeee/article/details/117366339和https://blog.csdn.net/jimmyleeee/article/details/118632872。

对API实施Rate Limit

由于API是公开的，任何人都可以无限之地调用API，如果没有Rate Limit，而且这个API可能比较消耗资源，攻击者就可以利用它发起DOS攻击。例如：上传头像功能，接收到上传的图片之后，还要对图片进行转换，这个操作时很好资源的，如果用户上传一个大图片或者不停地上传多个图片就会消耗服务器端的CPU资源和内存。速率限制限制了在指定时间段内可以向API发出的请求数量。在API上实现速率限制，以防止暴力攻击和其他恶意行为。

使用API Key

API密钥是唯一标识符，用于标识调用API的应用程序并验证访问授权。API Key与身份验证令牌的不同之处在于，它们标识发出API调用的应用程序(或网站)，而不是使用该应用程序(或网站)的人。有时，不同的端点需要访问不同的数据，并非每个用户都需要访问完整的权限访问所有数据。可以考虑针对不同的端点赋予不同的API Key，每一个API Key赋予不同的权限。当权限需要收回时，只需要废掉相对应的API Key即可。这使得权限的管理变得更加容易。

虽然保护API Key的安全是客户的责任，但是，作为服务提供方，也有责任对如何保护API Key提供指导。如果有示例代码，则会更好。

对所有的输入进行验证

在OWASP API TOP 10中，也有未验证输入导致的攻击SSRF，关于SSRF可以参考https://blog.csdn.net/jimmyleeee/article/details/122847453。如果输入未验证可能导致：SQL注入、XPath注入、LDAP注入、SSRF和Open Redirect等问题。注入问题对系统的危害也十分大，在OWASP TOP 10中多年占据榜首的位置。常见的错误是：请求是从内部的其他模块发过来的，所以，完全信任。这么做的前提是：那个模块已经做了严格的验证。但是，有时一个API会被多个模块调用，不能保证每个模块都做了相同的严格的验证，其中的一个模块有遗漏，就会影响整个系统。为了保证系统的安全，“靠人不如靠自己”，还是遵循“所有的输入都是恶意的”的原则，对输入进行严格验证为好。

对API进行监控

管理和监控API规范、流量和指标。阻止不需要的活动，例如恶意API流量和恶意机器人，以帮助保护应用程序并减少不必要的成本。定期对API进行安全审计，及时发现潜在的安全风险和漏洞。同时，对API进行实时监控，以便在发生攻击时迅速做出应对。

关键操作和错误记录入日志

将异常和关键操作记录日志，可以用于检测API的后端是否收到某种类型的攻击，一旦检测到攻击的发生，就可以根据记录的信息，及时判断可能发生什么问题，并作出及时的预防措施。在记录日志的同时，需要关注不能保存PII信息，以防PII数据通过日志泄露。

针对某一个请求，可以分配一个全局唯一的ID在所有后端的微服务中进行跟踪。这样就可以把一个请求所有相关的操作通过唯一的ID进行匹配，以备审计使用。

使用API 网关

对于大多数的基于微服务的应用，实现一个API Gateway是非常重要的，它不仅可以负责请求转发、请求合成和协议转换，而且它还提供身份验证、路由、监控、缓存、速率限制、熔断等安全功能。具体的服务层只关注自身业务逻辑，保证业务逻辑代码的独立。当某个微服务不能正常提供服务时，API GateWay可以通过提供默认值或者缓存的方式来掩盖后端服务的错误，提高应用的可用性和对客户的友好性。

API网关需要放在防火墙或者WAF后面，可以防止攻击者直接针对API进行攻击。同时，API Gateway可以封装内部的实现，充当多个服务的大门，系统的统一入口，方便内部服务的管理与调整，减少对外暴露的服务。

这个设计理念上和设计模式的FACADE模式很像。通过API Gateway一个对外提供服务的端，来隐藏后端的很多的微服务。

使用安全的库

再强的系统如果是基于有安全漏洞的库的基础上建立起来的，就如盖房子地基没有打好一样，很容易被攻击者通过第三方库的漏洞攻入系统。由于这些第三方的库的CVE是公开的，POC也是公开的，这些漏洞很容易被利用。所以，在系统上线前能够检查系统所使用的所有库的CVE情况，可以很好地了解系统的安全状态。有一些工具可以在扫描第三方组件漏洞时，还可以给出是否可以通过程序的入口到达，这样就可以判断此漏洞对当前应用是否可以被利用。可以根据CVE是否可以被利用，优先修复和升级这些库。如果工具能够提供自动修复，则更好，就可以省掉调查如何升级的努力和时间了。

提高所有工程师的安全意识

计算机系统就如动物的身体一样，是一个完整的系统，有输入和输出，内部的保护措施就相当于免疫系统，如果想有效地预防疾病，最重要的就是增强免疫力。计算机系统也一样，如果想预防攻击，最有效的方法就是在写代码的时候，就考虑到所有的可能的用例写出安全的代码。这就需要通过培训和流程来保障。在CI/CD流程的早期嵌入安全性，将SAST和SCA集成到CI/CD中，可以及时检测出代码中的安全问题，并提供培训以提高开发人员对安全性风险的认识，例如弱身份验证和逻辑漏洞等，提高开发人员写出安全代码的能力。

如果公司内部有针对每种类型的安全问题提供统一的解决方案和对应的开发库，就可以协助开发有效地解决安全问题。同时，还可以结合SAST工具定制规则，检测出系统内部遗留的安全问题。经过多年的经验，安全开发库+SAST定制的规则是一把利剑，不但可以检测出代码中的问题，还可以有效地解决安全问题。

实施DevSecOps原则，包括安全和开发团队之间的协作。定期地沟通和交流，在每个团队中培养安全专员，可以有效地推动安全措施在每个团队的实施。