API 测试

前提概要

本文章主要用于分享API测试基础学习,以下是对API测试的一些个人解析,请大家结合参考其他文章中的相关信息进行归纳和补充。


API 测试描述

什么是API?

        API 是应用程序编程接口(Application Programming Interface)的缩写。它是一组定义、协议和工具,用于让不同的软件应用程序之间进行交互和通信。以下从几个方面为你详细介绍 API:

        功能:1.提供服务接口        2.数据交互

        工作原理

                1.请求与响应:

        当一个应用程序想要使用另一个应用程序的功能或数据时,它会向对方的 API 发送一个请求,这个请求中包含了所需操作的相关信息。被请求的应用程序接收到请求后,会根据请求的内容进行相应的处理,并将结果以响应的形式返回给发起请求的应用程序。

                2.遵循特定协议:

        API通常遵循一定的协议和规范,如HTTP协议、REST架构风格等,这些协议规定了请求和响应的格式、数据传输的方式以及各种操作的具体规则。

        作用:促进了软件之间的互联互通,提高了开发效率,使得不同的应用程序能够更好地协同工作,为用户提供更加丰富和便捷的服务。

 

什么是API测试?

        API 测试是一种软件测试类型,主要用于测试应用程序编程接口(API)的功能、性能、安全性等方面,以确保 API 能够按照预期正常工作,并满足相关的业务需求和质量标准。

 

API测试的目的

  • 验证 API 的功能是否正确,确保其能够准确地处理各种请求并返回预期的响应。
  • 检查 API 的性能指标,如响应时间、吞吐量等,以保证在不同的负载条件下都能提供良好的服务质量。
  • 评估 API 的安全性,防止潜在的安全漏洞,如身份验证和授权问题、数据泄露等。
  • 确保 API 的兼容性,使其能够与不同的客户端、操作系统和浏览器等正常交互。

 

API漏洞描述:

        API 中的漏洞可能会破坏⽹站机密性、完整性和可⽤性的核⼼⽅⾯。

API测试原理

        通过发送各种请求到 API 端点,检查接收到的响应是否符合预期,以验证 API 的功能、性能、安全性等方面是否满足要求。

 

        功能测试原理

                请求发送

        根据 API 的文档和设计,构造各种不同的请求,包括不同的参数组合、请求方法(如 GET、POST、PUT、DELETE 等),发送到相应的 API 端点。例如,对于一个获取用户信息的 API,可能会发送带有不同用户 ID 参数的 GET 请求。

                响应验证

        接收 API 返回的响应,验证响应的状态码、数据格式、数据内容等是否与预期相符。例如,成功获取用户信息的响应应该返回状态码 200,并且响应数据的格式应该是正确的 JSON 格式,其中包含的用户信息也应该准确无误。

 

        性能测试原理

                负载生成

        使用专门的性能测试工具,模拟大量的并发请求发送到 API,以增加系统的负载。这些工具可以控制并发用户数、请求频率等参数。例如,模拟 1000 个并发用户同时向 API 发送请求,以测试 API 在高负载情况下的性能表现。

                性能指标监测

        在发送负载请求的过程中,监测各种性能指标,如响应时间、吞吐量、错误率等。响应时间是指从发送请求到接收到响应所花费的时间,吞吐量是指单位时间内处理的请求数量,错误率是指出现错误的请求占总请求数的比例。通过分析这些指标来评估 API 的性能是否满足要求。

 

        安全测试原理

                漏洞扫描

        利用安全测试工具或手动方法,对 API 进行漏洞扫描,检查是否存在常见的安全漏洞,如注入漏洞、身份验证和授权漏洞等。例如,通过向 API 输入一些特殊的字符或字符串,尝试触发 SQL 注入或其他注入漏洞。

                模拟攻击

        模拟各种攻击场景,如暴力破解、中间人攻击等,来验证 API 的安全性。例如,使用工具尝试通过暴力破解来获取用户的登录凭证,或者通过拦截和篡改 API 请求来模拟中间人攻击,检查 API 是否能够有效防范这些攻击。

        兼容性测试原理

                环境变化

        在不同的操作系统、浏览器、服务器环境等下运行 API 测试,检查 API 的兼容性。例如,测试 API 在 Windows 和 Linux 操作系统下的表现是否一致,在不同版本的浏览器中是否能够正常工作。

                版本兼容性

        对于有多个版本的 API,测试不同版本之间的兼容性,确保新版本的 API 不会对旧版本的客户端造成影响,并且能够正确处理与旧版本的交互。例如,检查新版本的 API 是否仍然能够支持旧版本客户端发送的请求,并返回正确的响应。

 API ⽂档

        API ⽂档(API Documents,docs)可以看作是 API 的说明书,以便开发⼈员使⽤,也可被攻击者利⽤。

        API ⽂档可以是⼈类可读或机器可读的形式。

        ⼈类可读的⽂档旨在让开发⼈员了解如何使⽤API。它可能包括详细的解释,⽰例和使⽤场景。

        机器可读的⽂档被设计为由软件处理,以⾃动执⾏API 集成和验证等任务。它是以 JSON 或 X 等结构化格式编写的。

 

内容构成:

  • 端点信息:详细列出 API 提供的各个端点(URL),以及每个端点对应的 HTTP 方法(如 GET、POST、PUT、DELETE 等),明确告知开发者每个端点的作用和所支持的操作。

  • 请求参数:说明每个端点接受的请求参数,包括参数的名称、类型、是否必填以及参数的取值范围等。例如,一个获取用户信息的 API 端点,可能需要接受一个名为 “user_id” 的整数参数,用于指定要获取信息的用户 ID。

  • 响应数据:描述 API 在不同情况下返回的响应数据结构和内容。包括响应的状态码(如 200 表示成功,404 表示未找到等)、数据格式(如 JSON、XML 等)以及具体的数据字段和含义。例如,成功获取用户信息后,可能会返回一个 JSON 格式的数据,包含 “name”“age”“email” 等字段,分别表示用户的姓名、年龄和电子邮件地址。

  • 错误处理:列举可能出现的错误情况以及对应的错误码和错误信息,帮助开发者在调用 API 时能够正确地处理各种错误。例如,当用户未提供有效的身份验证信息时,API 可能返回一个 401 错误码,并提示 “Unauthorized” 的错误信息。

  • 认证与授权:如果 API 需要进行身份认证和授权,文档会详细说明认证的方式(如令牌认证、OAuth 认证等)以及授权的流程和规则,指导开发者如何获取合法的访问权限。

  • 使用示例:提供一些实际的代码示例,展示如何使用 API 进行各种操作,帮助开发者快速上手。示例代码可以使用不同的编程语言编写,以便满足不同开发者的需求。

 

作用:

  • 帮助开发者使用 API:为开发者提供了清晰、准确的 API 使用指南,使他们能够快速了解 API 的功能和使用方法,减少开发时间和成本。

  • 促进团队协作:在团队开发中,API 文档是不同开发人员之间沟通的重要依据。前端开发人员可以根据 API 文档与后端开发人员进行对接,确保双方对 API 的理解一致,提高开发效率和代码质量。

  • 保证 API 的稳定性和兼容性:通过详细记录 API 的接口信息和使用规则,有助于在 API 的版本迭代过程中保持稳定性和兼容性,避免因接口变更而导致的系统故障或错误。

  • 便于维护和管理:对于 API 的开发者和维护者来说,API 文档是对 API 进行管理和维护的重要参考资料。它可以帮助开发者快速定位和解决问题,同时也为 API 的升级和扩展提供了依据。

OWASP API Security TOP 10

API1:2023 对象级授权失效(Broken Object Level Authorization):

        API 倾向于公开处理对象标识符的端点(Endpoint),从⽽造成对象级访问控制(Object Level Access Control)问题的⼴泛攻击⾯。在使⽤来⾃⽤⼾ ID 访问数据源的每个功能时,都应该考虑对象级别的授权检查。

 

API2:2023 ⽤⼾⾝份验证失效(Broken Authentication):

        往往,不恰当的开发实施⾝份验证机制,可使攻击者能够破坏⾝份验证令牌,或利⽤开发实施缺陷临时或永久地采⽤其他⽤⼾的⾝份。破坏系统识别客⼾机或⽤⼾的能⼒会损害API 的整体安全性。

 

API3:2023 对象属性级授权失效(Broken Object Property Level Authorization):

        该类别结合了 API3:2019 过度数据暴露 和API6:2019 批量分配 ,着重关注根本原因:在对象属性级别上缺乏授权验证或给予不适当的授权验证。这会导致未经授权的各⽅接触或操纵信息。

 

API4:2023 资源消耗不受限制(Unrestricted Resource Consumption):

        满⾜ API 请求需要⽹络带宽、CPU、内存和存储等资源。其他资源,如电⼦邮件、短信、电话或⽣物特征验证,则由服务提供商通过 API 集成提供,并按请求付费。如果成功的进⾏了此类攻击,可能导致拒绝服务或增加运营成本。

 

API5:2023 功能级授权失效(Broken Function Level Authorization):

        具有不同层次结构、组和⻆⾊的复杂访问控制策略,以及管理功能和常规功能之间的不明确分离,往往会导致授权缺陷。通过利⽤这些授权缺陷,攻击者可以访问其他⽤⼾的资源或管理功能。

 

API6:2023 对敏感业务流的⽆限制访问()Unrestricted Access to Sensitive Business Flows):

        易受此⻛险影响的 API 会暴露业务流,例如购买机票或发布评论。攻击者以⾃动化⽅式过度使⽤该功能,如果不能及时修正限制,可能会对业务造成损害。这不⼀定来⾃于开发实施漏洞。

 

API7:2023 服务器端请求伪造(Server Side Request Forgery):

        当 API 在未验证⽤⼾提供的 URI 的情况下获取远程资源时,可能会出现服务器端请求伪造(SSRF)漏洞。这使得,即使在防⽕墙或 VPN 的保护下,攻击者也能够强制应⽤程序将别有⽤⼼设计的请求发送到⾮预期⽬标。

 

API8:2023 安全配置错误(Security Misconfiguration):

        通常,为了使 API 更加可定制化,API 和相关⽀持系统包含复杂的配置。软件⼯程师和 DevOps ⼯程师可能未察觉这些配置,或者在配置⽅⾯未遵循安全最佳实践,从⽽为不同类型的攻击打开⼤⻔。

 

API9:2023 库存管理不当(Improper Inventory Management):

        与传统的 Web 应⽤程序相⽐,API 往往倾向于公开更多的端点(Endpoint)。这使
得正确和更新的⽂档⾮常重要。正确的主机清单和部署的API 版本对于缓解由不推荐的 API 版本和公开的调试端点等导致的问题也很重要。

 

API10:2023 API 的不安全使⽤(Unsafe Consumption of APIs):

        ⽐起⽤⼾输⼊,开发⼈员往往更信任从第三⽅ API 接收的数据。因此对第三⽅ API 的数据接收采⽤较弱的安全标准。为了破坏 API,攻击者追击集成的第三⽅服务,⽽不是试图直接危害⽬标 API。

API信息收集

1.API端点(接口)

        浏览器、客⼾端、⽤⼾或其他应⽤程序所能访问的 URL,这些 API 接⼝是接收客⼾端2.向服务器请求资源的位置

2.⾝份验证机制,是否能访问指定的 API 接⼝。
3.API ⽂档,API 说明书。
4.提请参数,强制参数、可选参数、⽆⽤参数、特殊参数、参数格式(如,JSON 格式)
5.请求类型,常规 HTTP 请求或⾮常规。
6.速率限制,如,1 秒内,能访问 API 的次数。
7.域名(IP)限制,是否只允许特定域名(IP)访问

 

portswigger靶场

1.

2.

 

 

 

 

 

 

认证和授权的区别

  • 定义和目的

    • 认证:是验证用户或实体身份的过程,旨在确认 “你是谁”。通过验证用户提供的凭证(如用户名和密码、令牌、生物识别信息等),来确定其是否为系统或应用程序中合法的用户。例如,用户登录银行网站时,输入用户名和密码,系统会验证这些信息以确认该用户是否为注册客户。

    • 授权:是确定经过认证的用户或实体被允许访问哪些资源以及执行哪些操作的过程,即解决 “你能做什么” 的问题。在用户通过认证后,系统会根据其角色、权限等信息,授予其相应的访问权限。例如,银行系统中,普通柜员可能被授权进行日常的账户查询、存款等操作,而经理则有更高的权限,如审批贷款等。

  • 实现方式

    • 认证:通常基于用户提供的身份凭证进行验证。常见的认证方式包括用户名 / 密码认证、基于令牌的认证(如 JSON Web Tokens)、单点登录(SSO)、生物识别认证(如指纹、面部识别)等。这些方式通过验证用户提供的信息与存储在系统中的用户信息是否匹配来确定用户身份的合法性。

    • 授权:一般通过访问控制列表(ACL)、角色 - 权限模型等方式来实现。访问控制列表明确规定了不同用户或用户组对特定资源的访问权限;角色 - 权限模型则是将权限与角色相关联,用户通过被分配到不同的角色来获得相应的权限。例如,在一个企业的办公系统中,通过角色 - 权限模型,将 “财务审批” 权限赋予 “财务经理” 角色,当用户被分配到 “财务经理” 角色时,就自动获得了该权限。

  • 先后顺序

    • 认证:是授权的前置步骤。用户必须先通过认证,证明自己的身份合法,系统才能进一步判断该用户是否具有访问特定资源或执行特定操作的权限。

    • 授权:在认证成功后进行。系统根据用户的身份以及相关的权限配置,决定是否授予用户访问请求资源或执行请求操作的权限。例如,用户在电商平台登录(认证)成功后,系统会根据其会员等级等因素(授权规则)来决定其是否能享受某些优惠活动或进行特定商品的购买操作。

API漏洞的相关名词

  1. 注入攻击:包括 SQL 注入、命令注入、LDAP 注入等,攻击者通过在输入参数中注入恶意代码,以篡改 API 的查询逻辑或执行系统命令。
  2. 身份验证与授权漏洞:如弱身份验证机制、未授权访问、越界访问等,攻击者可能利用这些漏洞绕过身份验证或获取超出其权限的资源访问。
  3. 过度数据暴露:API 返回过多的敏感信息,超出了客户端实际需要,可能导致信息泄露,如用户的敏感个人信息、系统内部数据等。
  4. 速率限制与资源耗尽漏洞:未对 API 请求进行合理的速率限制,攻击者可能通过大量并发请求耗尽服务器资源,导致服务中断,即拒绝服务攻击(DoS)或分布式拒绝服务攻击(DDoS)。
  5. 不安全的直接对象引用:API 在处理对象引用时,未对用户提供的对象标识符进行充分的验证和授权,攻击者可能通过篡改对象标识符来访问其他用户的资源或敏感信息。
  6. JSON 注入:针对使用 JSON 数据格式的 API,攻击者通过注入恶意的 JSON 数据来破坏 API 的正常处理逻辑,可能导致数据泄露或系统异常。
  7. XML 外部实体注入(XXE):如果 API 接受 XML 输入且未正确配置解析器,攻击者可以利用 XXE 漏洞来读取服务器上的本地文件或进行远程代码执行。
  8. API 密钥泄露:API 密钥是访问 API 的凭证,如果泄露,攻击者可以利用该密钥冒充合法用户进行 API 调用,获取敏感信息或执行恶意操作。
  9. 中间人攻击:攻击者在客户端和 API 服务器之间拦截和篡改通信数据,如窃取用户登录凭证、修改请求参数等,通常由于缺乏足够的加密传输或身份验证机制导致。
  10. 逻辑漏洞:API 的业务逻辑存在缺陷,例如在密码重置流程、交易流程等环节中存在漏洞,攻击者可以利用这些漏洞绕过安全机制或执行非法操作。
  11. 路径遍历漏洞:攻击者通过操纵 API 中的路径参数,尝试访问服务器上的文件或目录,超出了 API 预期的访问范围,可能导致敏感文件泄露或执行任意文件。
  12. 整数溢出漏洞:当 API 处理整数数据时,如果没有对数据的范围进行充分验证,攻击者可以通过输入过大或过小的整数值,导致整数溢出,从而可能改变程序的执行流程或造成内存破坏。
  13. 缓冲区溢出漏洞:API 在处理数据缓冲区时,如字符数组或字节数组,如果没有正确检查边界,攻击者可以通过输入超长数据,使数据溢出到相邻的内存区域,覆盖重要的程序数据或执行恶意代码。
  14. 格式字符串漏洞:如果 API 中使用了格式化函数,且对用户输入的格式字符串没有进行严格验证,攻击者可以利用格式化字符串的特性,读取或写入任意内存地址,导致信息泄露或程序崩溃。
  15. 代码注入漏洞:攻击者通过在 API 的输入参数中注入可执行代码,例如通过动态语言的特性或代码执行函数,使服务器执行恶意代码,从而获取系统控制权。
  16. 弱加密算法漏洞:API 使用了安全性较弱的加密算法,或者在加密过程中存在错误的配置,如密钥管理不当、加密模式选择错误等,导致数据容易被破解或篡改。
  17. 重放攻击:攻击者截获并重复发送合法的 API 请求,以达到非法目的,如多次消费同一笔交易、重复获取敏感信息等。通常是因为 API 缺乏有效的请求唯一性验证或时间戳机制。
  18. 会话固定漏洞:攻击者能够固定用户的会话 ID,使得用户在登录后使用攻击者预先知道的会话 ID 进行会话,从而攻击者可以劫持用户的会话,获取用户的权限和敏感信息。
  19. 依赖项漏洞:API 所依赖的第三方库、框架或组件存在安全漏洞,可能被攻击者利用来攻击 API。由于这些依赖项通常具有较高的权限,因此一旦被利用,可能会造成严重的安全后果。
  20. 反射型漏洞:常见于 Web API 中,攻击者通过构造恶意的请求参数,使得 API 将用户输入的内容反射回给用户,如在响应中包含恶意脚本,从而导致跨站脚本攻击(XSS)等安全问题。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值