0.3　应该测试哪些API特性

明确API安全评估的范围，其核心在于明确在测试过程中必须完成的工作。例如，确定需要测试的独有API端点、方法、版本、特性、认证与授权机制以及权限级别的数量。通过与客户交流、审阅相应的API文档及分析API集合，可评估测试范围。在获取所需信息后，可预计实施有效测试所需的时长。

0.3.1　API认证测试

明确客户对验证用户与未验证用户的测试需求。客户可能期望测试各类API用户及角色，以了解在不同权限级别下潜在的漏洞。此外，客户还希望审视他们所采用的身份验证与用户授权流程。许多API安全隐患都是在身份验证和授权环节中被发现的。在黑盒测试中，需要了解目标的身份验证流程，并尽力获取验证状态。

0.3.2　Web应用程序防火墙

在白盒测试中，需要关注可能正在使用的Web应用程序防火墙（WAF）。WAF是一种控制抵达API的网络流量的设备，能保护Web应用程序和API。如果配置WAF得当，那么在进行简单扫描后，一旦访问API受限，你将在测试期间迅速发现这一异常情况。高效的WAF能够限制意外请求，阻止API进行安全测试。出色的WAF会将请求频率异常或请求失败的情况纳入检测，并限制测试设备。

在灰盒测试和白盒测试中，客户可能透露WAF相关信息，此时需做出相应决策。尽管关于组织是否应放宽安全性以提高测试效果的观点不一，但分层的网络安全防御对有效保护组织至关重要。简言之，不应将所有安全措施集中于WAF。长远来看，持续攻击者可能了解WAF的边界，找到绕过方法或利用零日漏洞使其失效。

在理想状况下，客户应允许测试IP地址绕过WAF，或适度放宽常规的边界安全设置，从而确保测试能够全面而准确地评估API的安全控制措施。如前文所述，制订此类计划和决策实则关乎威胁建模。对API的最佳测试应与API提供商的实际威胁相一致。为获得最具价值的API安全性的测试结果，最佳做法是了解潜在对手及其黑客技术。否则，你会发现自己只是在测试API提供商的WAF的有效性，而不是其API安全控制的有效性。

0.3.3　移动应用测试

诸多机构均具备扩展攻击面的移动应用。移动应用通常依赖API在应用内部及支持服务器间传输数据。为确保API的安全性，可采用手动代码审计、自动化源代码分析及动态分析等方法进行测试。手动代码审计涉及对移动应用源代码的访问，以查找潜在漏洞。自动化源代码分析与之类似，但会借助自动化工具辅助寻找漏洞与奇特文件。动态分析则在应用运行时进行，包括拦截移动应用客户端API请求与服务器API响应，试图发现可利用的漏洞。

0.3.4　审计API文档

API文档通常是一份详尽的操作指南，深入阐述了如何使用API，包括身份验证要求、用户权限、应用实例以及API端点等关键信息。对任何自有的API来说，完备的文档是其成功运行和维护的关键要素。如果缺乏有效的API文档，企业将不得不依赖用户培训来提供支持。因此，确保API文档的准确性、实时性和安全性至关重要。

然而，API文档可能存在不准确、过时或泄露敏感信息等问题。API安全专家应对API文档给予关注，并充分发挥其优势。因此，在灰盒测试和白盒测试中，API文档审计应纳入考察范围。通过对文档进行审计，可以揭示包括业务逻辑漏洞在内的安全隐患，从而提高API的安全性。

0.3.5　速率限制测试

速率限制是一种对在特定时间内API消费者可发起请求数量的约束措施。这一限制由API提供商的Web服务器、防火墙或WAF实施，对API提供商具有两大关键作用：一是有助于实现API货币化，二是能够防止资源被过度消耗。由于速率限制是实现API货币化的核心要素，因此在API项目开发过程中应对速率限制给予充分关注。

例如，一家公司可能会设定免费级API用户每小时仅能发起一次请求。在发起此请求后，用户在接下来的一小时内将无法再发起其他请求。然而，若用户选择付费，他们便能在一小时内发起大量请求。若没有充足的控制措施，这些未付费的API用户可能会试图规避收费，从而无限制地消耗大量数据。速率限制测试与拒绝服务测试有所区别。DoS测试旨在通过攻击破坏服务，使系统和应用程序对用户不可用，以评估组织的计算资源弹性。而速率限制测试则旨在评估在给定时间段内绕过限制发送请求的数量。试图绕过速率限制并不一定会导致服务中断，反而可能助长其他攻击，并揭示组织在API货币化策略中的漏洞。

通常来说，各类组织会在API文档中明确规定API请求的限制。这些限制的具体内容可能包括：在指定的 Y 时间段内，允许发起的最大请求次数为 X 。若超过此限制，将从我们的Web服务器接收到代码为 Z 的响应。以Twitter为例，其根据授权等级设定请求次数限制。第一层授权用户每15分钟可发起15次请求，而第二层授权用户每15分钟可发起180次请求。若超过请求上限，用户将收到HTTP错误代码420，如图0-1所示。