API攻防：Web API安全指南

版权信息

书名：API攻防 : Web API安全指南

ISBN：978-7-115-65275-1

本书由人民邮电出版社发行数字版。版权所有，侵权必究。

您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。

我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。

如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。

版  权

著    ［美］科里·鲍尔（Corey Ball）

译    皇智远 孔韬循

责任编辑 单瑞婷

人民邮电出版社出版发行　　北京市丰台区成寿寺路11号

邮编　100164 　电子邮件　315@ptpress.com.cn

网址　http://www.ptpress.com.cn

读者服务热线：(010)81055410

反盗版热线：(010)81055315

版权声明

Copyright © 2022 by Corey Ball. Title of English-language original: Hacking APIs: Breaking Web Application Programming Interfaces, ISBN 9781718502444, published by No Starch Press Inc. 245 8th Street, San Francisco, California United States 94103. The Simplified Chinese-language 1st edition Copyright © 2024 by Posts and Telecom Press Co., Ltd, under license by No Starch Press Inc. All rights reserved.

本书中文简体字版由美国No Starch出版社授权人民邮电出版社有限公司出版。未经出版者书面许可，对本书任何部分不得以任何方式复制或抄袭。

版权所有，侵权必究。

内容提要

本书旨在打造一本Web API安全的实用指南，全面介绍Web API的攻击方法和防御策略。

本书分为4个部分，共16章。第一部分从API渗透测试的基础理论入手，探讨Web 应用程序的基础知识、Web API攻防的基本原理和常见的API漏洞。第二部分带领读者搭建自己的API测试实验室，结合2个实验案例，指导读者找到脆弱的API目标。第三部分通过侦察、端点分析、攻击身份验证、模糊测试、利用授权漏洞、批量分配、注入这7章，帮助读者了解API攻击的过程和方法，结合7个实验案例，帮助读者进行API测试。第四部分介绍3个真实的API攻防案例，旨在针对性地找到提高API安全性的具体策略和方案。

本书可为初学者提供API及其漏洞的全面介绍，也可为安全从业人员提供高级工具和技术见解。

推 荐 语

本书从基础概念出发，深入剖析常见API漏洞的成因，并提供了实战中的最佳防护策略，鼓励读者以积极的态度进行思考。这段高效的学习旅程从工具解析和侦察技巧开始，逐步深入模糊测试和复杂访问控制等各个环节。通过丰富的实验案例介绍、技巧分享和真实案例分析，作者将API安全的全部精华凝聚成本书。

——Erez Yalon，Checkmarx安全研究副总裁，OWASP API安全项目负责人

本书以一种生动有趣的方式，带领读者深入探索API的生命周期，不仅激发了读者对 API 攻防的深入探索欲望，还点燃了读者对合法的API目标应用新知识的热情。本书从基础概念到案例分析，再到工具解析与应用详解，为读者提供了全面而深入的知识体系。本书是API安全领域的宝贵资源，特别适合那些致力于应对高级对抗性研究、进行安全评估或DevSecOps挑战的专业人士阅读。

——Chris Roberts，Ethopass战略顾问，国际虚拟首席信息安全官

本书为渗透测试人员提供了全面的指导和支持，帮助他们更好地理解和应对现代Web应用中的API安全挑战。无论你是刚入行的新手，还是已有一定经验的安全专家，本书都能提供极大的帮助。本书详细介绍了 API 测试的工具和技巧，帮助读者迅速掌握API安全的核心要点。同时，书中还提供了众多实用的自动化方法和绕过防护策略，帮助读者在渗透测试中取得更佳成效。在阅读本书后，读者会全面提升渗透测试技能，能为保障Web应用安全做出重要贡献。

——Vickie Li，《漏洞赏金训练营》作者

本书为API安全领域提供了一份宝贵的入门指南，它以通俗易懂的方式深入解析了API安全这一复杂而关键的主题。书中重点关注访问控制的核心议题，通过讲解真实案例，帮助读者全面理解API安全的各个方面。无论是追求高额漏洞赏金的安全研究人员，还是希望提升组织API安全性的决策者，都能从本书中获得实用且坚实的指导方法和建议。

——Inon Shkedy，Traceable AI安全研究员，OWASP API安全项目负责人

尽管互联网上充斥着有关网络安全的各种话题，但仍难以找到关于如何成功对 API进行渗透测试的深刻见解。本书无疑满足了这一需求。本书既适合网络安全的初学者学习参考，也适合经验丰富的专业人士阅读。

——Cristi Vlad，网络安全分析师和渗透测试人员

译 者 序

在数字化浪潮的推动下，应用程序接口（application program interface，API）不仅仅是连接不同软件、服务和数据的纽带，更是现代信息技术架构中不可或缺的一环。无论API的来源或用途如何，网络安全始终是组织必须严肃对待的核心议题。一旦API遭受恶意攻击，可能引发一系列严重网络安全问题，例如数据泄露、系统入侵、业务中断，甚至可能产生经济损失。攻击者可能会利用API的漏洞进行未授权访问，窃取敏感信息，甚至控制整个信息系统，最终导致整个信息系统的崩溃。

在着手翻译本书之前，我们对国内IT行业进行了深入的调研。调研结果显示，相较于传统网络安全漏洞，大多数企业对API安全的重视程度远远不够。我们期望通过翻译本书，填补国内在API安全领域的知识空白，推动API安全技术的发展与应用，并助力国内网络安全行业与国际标准接轨。在翻译过程中，我们力求精准传递书中的技术细节和知识，同时还融入了国内网络安全从业者的专业见解和技术经验，以期最大限度地展现本书的深层价值。愿每一位读者都能从本书中获得宝贵的知识和启发，共同为构建更加安全、稳固的数字世界贡献力量。

最后，向人民邮电出版社的编辑单瑞婷表示衷心的感谢，您精心的指导和专业的建议为本书的完成提供了坚实的基础。同时，衷心感谢那些在翻译过程中给予我们巨大支持与鼓励的家人和朋友们（按拼音顺序排列）：杜安琪、窦冰玉、呼和、冀伟、李国聪、王杰、王鲲、吴焕亮、朱国明、朱楠。正是因为有了你们的理解与帮助，这本书才得以顺利完成。

序

设想一下，如果想给朋友转账，不仅仅是打开一个应用程序后单击几下屏幕那么简单。又或者说，如果我们要查看每日步数、运动数据和营养信息，需要分别打开3个不同的应用程序。再比如说，如果要比较飞机票价，需要访问不同航空公司的网站。

当然，构想这样一个世界并非难事，毕竟我们不久前尚处于其中。然而，应用程序接口（API）的出现彻底改变了这一切。API就像一种黏合剂，促进了不同企业间的协作，彻底改变了企业构建和运行应用程序的方式。事实上，API已变得无处不在。根据2018年10月Akamai发布的一份报告，API请求已占所有应用请求的83%。

然而，正如互联网上的许多事物一样，一旦有好东西出现，便会立即吸引犯罪分子的注意。对这些犯罪分子来说，API是一片肥沃且有利可图的土地，其原因不言自明。API具备两个极为诱人的特点：其一，API是敏感信息的丰富来源；其二，API频繁暴露出安全漏洞。

让我们思考一下API在典型应用架构中扮演的角色。当你在手机应用程序上查询银行卡余额时，后台的一个API会请求这些信息，并将这些信息发送到应用程序上。同样，当你申请贷款时，API允许银行请求你的信用记录。API处于用户和后端敏感系统之间的关键位置。一旦犯罪分子能够破坏API，他们就可能直接获取极具价值的信息。

尽管API的普及程度达到了前所未有的水平，但其安全性却远远落后。在与一家有着百年历史的能源公司首席信息安全官的交流中，我惊讶地发现该公司在其组织内部广泛使用了API。然而，他迅速补充说到：“每当我们深入研究时，不难发现这些API往往被赋予了过大的权限。”

此现象并不罕见。开发者们持续承受着巨大的压力，他们需要修复漏洞、向消费者发布新版本，并为服务添加新功能。他们不得不夜以继日地进行构建和提交工作，而不是每隔数月才发布一次。实际上，他们并没有充足的时间去考虑每一个改变所带来的安全影响，因此，一些未被发现的漏洞可能会隐藏在产品之中。

不幸的是，如果不对API实施安全措施，那么会导致不可预见的后果。以美国邮政服务（USPS）为例，该机构推出了一个名为Informed Visibility的API，旨在允许组织和用户追踪包裹。该API规定用户必须经过身份验证和认证程序，才能通过该API获取所需信息。然而，由于该机构未对API使用权限进行限制，因此，一旦用户通过了认证，他们就可以查看其他用户的账户信息，这导致了超过6000万用户信息的泄露。

健身公司Peloton也通过API为其应用程序（甚至其设备）提供支持。然而，由于该公司的一个API在执行调用并从Peloton服务器接收响应的过程中无须进行身份验证，这导致了请求者可以查看大约400万台Peloton设备的账户信息，包括可能敏感的个人信息。

再举一个例子，电子支付公司Venmo借助API技术推动其应用程序的运行，并实现与金融机构的连接。该公司的一个API通过展示近期的匿名交易信息来实现营销功能。尽管用户界面会过滤掉所有敏感信息，但当API被直接调用时，它会返回全部交易细节。不幸的是，有一个恶意用户通过这个API收集了约两亿笔交易数据。

此类安全事件已变得极为普遍。Gartner预测，到2022年，API攻击将成为“最常见的攻击手段”。同时，IBM的报告也指出，三分之二的云安全漏洞是API配置不当造成的。这些安全漏洞也凸显了推出保护API的新方法的必要性。过去的应用程序安全解决方案只关注最常见的攻击类型和漏洞。例如，自动化扫描器会在通用漏洞和曝光（CVE）数据库中寻找IT系统的缺陷，而Web应用程序防火墙则会实时监控流量，以拦截包含已知漏洞的恶意请求。这些工具对于识别传统威胁极为有效，但它们未能解决API面临的核心安全问题。

API漏洞并不常见。API漏洞不仅在不同API之间存在显著差异，而且与在传统应用程序中发现的漏洞也迥然不同。USPS的漏洞并不是一个安全配置错误，而是一个业务逻辑错误。也就是说，应用程序逻辑中存在一个未被预料到的漏洞，使得经过认证的有效用户能够访问其他用户的数据。这种缺陷被称为对象级授权缺陷，其成因在于应用程序逻辑未能妥善控制授权用户能够访问的数据范围。

简而言之，这些独特的API漏洞实际上构成了零日漏洞，每个漏洞只属于特定的API。考虑到这些漏洞的广泛性，本书对培养渗透测试人员以及对维护API安全有兴趣的漏洞赏金猎人来说至关重要。此外，随着安全工程和开发流程的“左移”，API安全已不再局限于公司信息安全部门的职责范畴。本书可作为现代IT工程团队的实用指南，将安全测试、功能测试和单元测试融合到一起。

如果执行得当，API的安全测试计划应该是持续且全面的。偶尔进行的安全测试无法跟上新版本快速迭代的步伐。相反，安全测试应该成为开发周期的一部分，确保每个版本在进入生产环境之前都经过审计，并且覆盖API的全部功能范围。发现API漏洞需要新的技能、新的工具和新的方法。现在，我们比以往更迫切需要《API攻防：Web API安全指南》这本书。

达恩·巴拉奥纳（Dan Barahona）

APIsec公司首席战略官

美国加利福尼亚州旧金山市

关于作者

科里·鲍尔（Corey Ball）是Moss Adams的网络安全咨询经理，也是渗透测试服务部门的负责人。他在信息技术和网络安全领域积累了超过10年的丰富经验，涉及多个行业，包括航空航天、农业、能源、金融科技、政府服务以及医疗保健等。他曾在萨克拉门托州立大学取得英语与哲学双学士学位，他还持有OSCP、CCISO、CEH、CISA、CISM、CRISC和CGEIT等专业资格认证。

关于技术审稿人

亚历克斯·里夫曼（Alex Rifman）是一位资深的安全行业专业人士，他在防护策略、事件响应与缓解、威胁情报及风险管理等方面拥有丰富经验。目前，他担任APIsec公司的客户成功部门负责人，专攻API安全领域。

关于译者

皇智远（陈殷），呼和浩特市公安局网络安全专家，中国电子劳动学会专家委员会成员。长期从事网络安全领域的研究和打击网络犯罪的工作，曾负责国内外多个千万级安全项目。曾受邀在互联网安全大会（ISC）、网络安全创新大会（FCIS）等多个行业会议中发表演讲。微信公众号：过度遐想。

孔韬循（K0r4dji），安恒信息数字人才创研院北区运营总监，广州大学方滨兴院士预备班专家委员会委员，破晓团队（Pox Team）创始人，Defcon Group 86024发起人，Hacking Group网安图书专委会秘书长，《Web代码安全漏洞深度剖析》作者。拥有网络安全行业十余年从业经验，曾多次受邀在国内多个安全会议及安全竞赛中发表演讲，同时承担会务顾问、论坛主持人、赛事解说员等关键职责。

献  辞

致我挚爱的妻子Kristin，以及我们的3个优秀的女儿，Vivian、Charlise与Ruby。你们的陪伴让我的日常生活充满欢乐，或许也为世界减少了数次数据泄露。你们是我生命中的璀璨之光，我爱你们。

前  言

如今，根据研究人员的估算，API请求在所有应用请求中的占比已超过80%。因此，对业务至关重要的资产可能潜藏着毁灭性的漏洞。

经过深入研究和详细分析，我们发现API是一个极具潜力的攻击媒介。鉴于其设计初衷是向其他应用程序传递信息，这无疑为潜在的攻击者提供了一定的便利。值得注意的是，为了获取组织内部最为敏感的数据，攻击者可能并不需要采取复杂的网络穿透策略，亦无须规避尖端防病毒软件的监测，甚至无须利用尚未被公众发现的零日漏洞。相反，他们可能仅需向特定的API端点发送一个精心构造的请求，便有可能完成攻击。

本书旨在全面介绍Web API，详细阐述如何对其进行测试以揭示潜在的漏洞。本书主要测试REST API的安全性，REST API是Web应用程序中广泛使用的API格式，同时也会测试GraphQL API的安全性。你将先学习运用API所需的工具和技术。随后，我们将引导你探测潜在的漏洞，并指导你如何利用这些漏洞。最后，你将学会如何报告所发现的问题，从而防止下一次数据泄露。

攻击Web API的诱惑

2017年，《经济学人》杂志（国际商业领域的主要信息来源）发布了一篇文章，指出：“在当今世界，数据的价值已超越了石油。”API作为数字时代的桥梁，使得各种宝贵的信息能够迅速在全球范围内流通。简而言之，API是一种技术，它促进了不同应用程序之间的有效沟通。例如，当Python应用程序需要与Java应用程序的功能进行交互时，情况可能变得复杂。然而，通过利用API，开发人员得以构建模块化的应用程序，并能充分利用其他应用程序的专业功能。因此，他们无须从零开始开发地图、支付处理器、机器学习算法或认证流程。

因此，众多现代Web应用程序纷纷采用API。然而，在新技术发展进步的同时，网络安全问题亦随之而来。API大大扩展了这些应用程序的攻击面，其防御机制往往不够健全，使得攻击者能够轻易利用它们获取数据。此外，许多API缺乏与其他攻击向量相同的安全控制措施，从而成为企业的潜在风险点。

不仅如此，早在多年前，Gartner已做出预测，到2022年，API将成为主要的攻击目标。因此，作为网络安全专家，我们必须紧跟技术创新的步伐，采取有效的防护措施来保护API。通过发现API的潜在漏洞，及时报告并向企业传达相关风险，我们可以为遏制网络犯罪做出积极贡献。

本书组织结构

攻击API并不像你想象的那样充满挑战性。一旦了解了它们的运作原理，黑客只需要发送正确的HTTP请求，就可以发起API攻击。然而，通常用于漏洞挖掘和Web应用程序渗透测试的工具和技术并不适用于API测试。例如，你不能只是对一个API进行通用漏洞扫描，就期待能得到有用的结果。我经常对易受攻击的API进行扫描，结果却为虚假阴性。当API未得到充分测试时，组织会产生虚假安全感，从而面临入侵风险。

本书各部分均以前一部分为基础。

第一部分：Web API安全的原理

第一部分包含第0章～第3章。在该部分中，先介绍安全测试的预备知识，再介绍Web应用程序及驱动它们的Web API的基本知识，包括本书主题之一的REST API和越来越受欢迎的GraphQL，还将探讨常见的API漏洞。

第二部分：搭建API测试实验室

第二部分包含第4章和第5章。在该部分中，主要介绍如何搭建自己的API测试实验室，还介绍了相关工具，如Burp Suite、Postman等，还将建立一个易受攻击的API目标实验室，帮助你进行攻击实践。

第三部分：攻击API

第三部分包含第6章～第12章。在该部分中，探讨主要介绍攻击API的方法论，指导你执行针对 API 的常见攻击。你将学习通过开源情报技术发现API，分析它们以了解它们的攻击面，深入了解针对API的攻击方法。你还将学会逆向工程API、绕过身份验证，并对安全问题进行模糊测试。

第四部分：真实世界的API攻击

第四部分包含第13章～第15章。在该部分中，主要介绍API漏洞如何在数据泄露和漏洞赏金中被利用。你将了解如何运用应用规避技术，并进行速率限制测试。你还将了解针对GraphQL的攻击示例，将所学技术应用于GraphQL格式。

实验部分

本书第二部分和第三部分的每一章均包含实验部分，供你实践本书技术。你可使用除本书介绍的工具之外的其他工具完成实验。

本书适合对Web应用程序攻击感兴趣的人，以及希望增加一项技能的渗透测试人员和漏洞赏金猎人阅读。本书的设计旨在方便初学者在第一部分学习Web API的基本知识，在第二部分搭建黑客实验室，在第三部分开始攻击。

攻击API餐厅

在我们开始学习之前，让我用一个比喻来帮助大家理解。想象一下，一个应用程序就像一家餐厅，API 文档就像菜单，告诉你可以点什么样的菜品。作为顾客与厨师之间的联络人，服务员就像API本身。你可以根据菜单向服务员提出请求，服务员把你点的菜品端上来。

至关重要的是，API用户无须了解厨师如何烹饪佳肴，或后台程序如何运作。相反，他们应遵循一套指令来发出请求，并接收相应的响应。随后，开发人员可以根据需求编写应用程序，以满足各种请求。

作为一名API黑客，你需要深入探索餐厅的每个角落，了解餐厅的运营方式。你可能会尝试绕过它的“保镖”，或提供一个被盗用的身份验证令牌。此外，你还需要分析菜单，寻找诱使API向你提供未经授权数据的方法，例如欺骗服务员把所有的菜品都端上来，你甚至可能说服餐厅所有者将整个餐厅的钥匙交给你。

本书引导你探讨以下主题，以全面的方式来攻击API：

● 理解Web应用程序的工作原理以及Web API的结构；

● 从黑客的角度掌握顶级API漏洞；

● 学习最有效的API黑客工具；

● 进行被动和主动的API侦察，以发现API的存在，找到暴露的秘密，并分析API的功能；

● 与API进行交互，并利用模糊测试功能测试它们；

● 通过利用你发现的API漏洞，执行各种攻击。

在本书中，我们将采用对抗性思维来充分利用各类API的功能与特性。我们越能模拟潜在对手，就越能发现可以报告给API提供商的潜在漏洞。我认为，我们甚至可以共同防止下一场大规模的API数据泄露事件。

资源与支持

资源获取

本书提供如下资源：

● 本书配套视频；

● 本书思维导图；

● 异步社区7天会员。

要获得以上资源，您可以扫描右方二维码，根据指引领取。

提交勘误

作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。

当您发现错误时，请登录异步社区（https://www.epubit.com），按书名搜索，进入本书页面，单击“发表勘误”，输入勘误信息，单击“提交勘误”按钮即可（见右图）。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。

与我们联系

我们的联系邮箱是shanruiting@ptpress.com.cn。

如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。

如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们。

如果您所在的学校、培训机构或企业想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。

如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。

关于异步社区和异步图书

“异步社区”（www.epubit.com）是由人民邮电出版社创办的IT专业图书社区，于2015年 8 月上线运营，致力于优质内容的出版和分享，为读者提供高品质的学习内容，为作译者提供专业的出版服务，实现作者与读者在线交流互动，以及传统出版与数字出版的融合发展。

“异步图书”是异步社区策划出版的精品IT图书的品牌，依托于人民邮电出版社在计算机图书领域多年的发展与积淀。异步图书面向IT行业以及各行业使用IT技术的用户。

第0章 为安全测试做准备

API安全测试不同于一般的渗透测试，也不属于网络应用渗透测试的范畴。由于许多组织的API攻击面具有庞大的规模和复杂性，API安全测试成为一项独特的服务。　

本章将探讨在进行API安全测试时，应纳入测试范围并进行记录的API特性，以及在进行攻击前需要准备的事项。相关内容将有助于读者评估参与此项活动的相关工作量，以确保全面测试目标API的各个方面并避免一些潜在的困扰。

在进行API安全测试时，需要明确界定测试范围，或者列出一份允许测试的目标和特性清单，这样做是为了确保客户和测试人员对API安全测试有一致的理解。界定一个API安全测试的参与范围，主要取决于 6 个因素：测试方法论、测试范围、目标特性、测试限制、报告要求，以及是否计划进行修复后的二次测试。

0.1　获得授权

在进行API安全测试之前，必须签订正式的合同，以明确界定参与测试的资产范围，并在约定的时间段内授权工程师对客户的资源进行攻击。这样做旨在确保业务的正常运行和测试操作的合规性。合同应详细规定测试的范围、目标特性、测试限制、报告要求，以及是否计划在修复后进行二次测试，确保客户和测试者对API安全测试有共同的理解。

一份严谨的工作声明有助于明确双方职责，确保客户与测试团队对所提供服务的内容、范围及目标达成一致。同时，在合同中应详细列明批准的目标，明确测试API的具体方面，排除不适宜测试的内容，并设定一个双方约定的测试执行时间表。

在合同签署前的审核过程中，测试团队需要核实签署人是否为具备相应权限的测试目标客户代表。同时，需确认客户为资产的合法所有者，否则应将相关信息传达至实际所有者。在此基础上，还需考虑客户的API托管位置以及其是否拥有授权测试软件和硬件的权限。

某些组织在确定项目范围时可能过于严谨。若客户倾向于缩小范围进行测试，可以温和措辞向其阐述网络犯罪分子在实际攻击中是没有范围或限制可言的。真正的网络犯罪分子不会考虑其他项目对IT资源的占用，他们不会回避包含敏感生产服务器的子网，也不会在非高峰时段规避黑客攻击。

在与客户会晤时，务必明确阐述各项检测措施及其后续相关流程，并确保在合同、电子邮件或笔记中予以精确记录。若客户坚持采用书面协议，应在合法合规且遵循道德原则的前提下进行操作。为进一步降低风险，可征求律师或法务部门的建议。

0.2　API测试的威胁建模

威胁建模是对API提供商所面临的威胁进行映射的过程，通过此过程，可以针对性地选择合适的攻击技术和工具，对API渗透测试流程进行优化。对API提供商实际可能遭受的威胁进行相关的测试，无疑是最佳的选择。

威胁行为者即潜在的API攻击者，其覆盖范围非常广泛，从对API知之甚少的普通用户，到熟悉应用程序的客户、不可靠的商业伙伴，乃至了解应用程序详情的开发人员。为了实现对API安全性的最有效测试，在理想状况下，我们应能映射出可能的威胁行为者及其所采用的黑客技术手段。

渗透测试方法论应基于威胁行为者的视角来构建，因为这一视角直接影响获取目标信息的策略选择。如果威胁行为者对API缺乏了解，那么他们需通过深入研究来识别针对应用程序的有效攻击手段。另外，若存在不可靠的商业伙伴或内部威胁，他们可能已对应用程序有深入的了解，因此可能无须进行前期的侦察工作。为了应对这些不同的情境，可以采用3种基本的渗透测试方法，即黑盒测试、灰盒测试和白盒测试。

黑盒测试模拟了一种情境，即一个随机发现目标组织或其API的攻击者。在此类测试中，客户不对测试者提供任何关于攻击面的信息。测试可能始于一个签署业务范围说明的公司名称。随后，测试人员运用开源情报（OSINT）进行侦察，尽可能全面地了解目标组织的相关信息。这包括利用搜索引擎、社交媒体、公共财务记录和DNS信息等手段，分析组织的域名。关于黑盒测试的详细工具和技术，详见第 6 章。进行OSINT侦察后，测试工程师会整理出目标的IP地址、URL和API端点等列表，然后提交给客户审查。客户在审查目标列表后，再授权给工程师进行测试。

灰盒测试是一种更具策略性的测试方法，旨在将节省的时间投入主动测试以优化侦察过程。在进行灰盒测试时，测试者通常可向客户获取目标范围、API操作文档以及基本用户账户的访问权限等信息。此外，测试人员可能会被纳入安全设备白名单中，以便进行深度测试。

漏洞赏金计划属于黑盒测试与灰盒测试的范畴，这些漏洞赏金计划一般由企业发起，邀请白帽子黑客对其指定的Web应用程序进行安全检测。白帽子在发现漏洞后，会把漏洞报告提交给企业以获得企业提供的相应奖励。相较于黑盒测试，漏洞赏金计划为赏金猎人提供了明确的目标范围、奖励的漏洞类型以及允许的攻击类型等资讯，使猎人可以根据自身资源和策略，衡量在侦察方面投入的时间和精力。对于热衷于获取漏洞赏金的读者，强烈推荐阅读Vickie Li所著的《漏洞赏金训练营》（Bug Bounty Bootcamp）。

在白盒测试中，客户会最大限度地提供关于其内部环境的相关信息。除了为灰盒测试提供的资料外，这些信息可能还包括应用程序源代码、设计资料，以及用于开发应用程序的软件开发工具包（SDK）等资源的访问权限。白盒测试模拟了内部攻击者（一个熟悉组织内部运作并能够接触实际源代码的攻击者）的威胁。在白盒测试过程中，测试人员获取的信息越多，受测试的目标就会受到更为深入的检验。

在选择白盒测试、黑盒测试，或是二者的结合策略时，客户需要基于威胁模型和威胁情报来做出决策。通过威胁建模，我们将结合客户的实际情况，为潜在的攻击者构建画像。举例来说，如果一家小型企业不是供应链的关键环节，也不提供基础服务，那么将其攻击者设想为拥有雄厚资金的、能够持续发动高级持续性威胁（APT）的国家，显然是不切实际的。对于此类小型企业，采用APT技术就如同使用战斗机去打击一个小偷一样，显得过于夸张和不切实际。因此，我们应通过威胁建模，构建一个更符合实际情况的威胁模型，以便为客户提供最具价值的建议。在此情境下，最有可能的攻击者可能是一名偶然的机会主义者，即掌握中等安全测试技能的个体，他们在偶然发现组织网站后，可能只会针对已知的漏洞使用已发布的攻击手段。因此，采用有限黑盒测试将是一个更为合适的机会主义攻击者的测试方法。

为了为客户构建高效的威胁模型，测试团队有必要开展深入的调查。调查范围包括客户在攻击中的暴露程度、经济影响、政治参与度、供应链关联、基础服务供应状况，以及是否存在其他潜在的犯罪动机等。可以研发专门的调查工具，或整合现有的专业资源，如MITRE ATT&CK或OWASP，协助完成此项工作。

我们选择的测试方法将在很大程度上决定后限范围界定工作的难易程度。鉴于黑盒测试人员提供的关于系统范围的信息相对有限，剩余范围的项目更适合采用灰盒测试和白盒测试。

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所示。

图0-1　Twitter的HTTP状态码

0.4　限制和排除

在没有特定授权文件规定的情况下，测试人员应默认不执行拒绝服务（DoS）和分布式拒绝服务（DDoS）攻击。从经验来看，此类攻击的授权执行情况实属罕见。当获得DoS攻击授权时，通常会在正式文件中明确说明。此外，除非特定项目需求，渗透测试与社会工程学实践通常相互独立。同时，在渗透测试中，应始终检查你是否可以使用社会工程学攻击（如语音网络钓鱼、短信网络钓鱼）的可行性。

在默认情况下，漏洞赏金计划都不会接受针对社会工程学攻击、DoS或DDoS攻击、攻击客户以及访问客户数据的尝试。在特定情况下，当允许对用户实施攻击时，通常建议采取创建多个账户的策略，并在适当的时间对自身的测试账户展开攻击。

此外，部分程序或客户可能会详细阐述已知的问题。API的某些方面可能被视为安全问题，但也可能是为了提供便利而设的功能。例如，密码找回功能可能会展示一条信息，告知终端用户其电子邮件地址或密码是否错误。然而，这一功能也可能赋予攻击者暴力破解有效用户名和电子邮件地址的权限。组织可能已决定接受这一风险，并不愿对其进行修正。

请在合同中的任何排除或限制方面保持谨慎。针对API，程序可能允许测试特定部分，同时可能限制某些路径。例如，银行API提供商可能与第三方共享资源，未经授权不允许测试。因此，他们可能会明确指出可以攻击 /api/accounts端点，但禁止攻击/api/shared/accounts。或者，目标的身份验证过程可能通过未被授权攻击的第三方进行。你需要密切关注测试范围，以便进行合法的授权测试。

0.4.1　安全测试云API

现代Web应用程序普遍部署在云端。针对云端Web应用程序的攻击，实质上是对云服务提供商物理服务器（如亚马逊、谷歌或微软等）的攻击。各个云服务提供商均具有独特的渗透测试条款和服务，了解这些条款和服务至关重要。截至2021年，云服务提供商普遍对渗透测试人员持友好的态度，且很少需要授权申请。然而，部分云端Web应用程序和API（如组织使用的Salesforce API）可能需要获取渗透测试授权。

在展开攻击之前，务必充分了解目标云服务提供商的现行规定。以下是对若干主流提供商政策的具体阐述。

● 亚马逊网络服务（AWS）：至撰写本书时，AWS允许客户执行多种安全测试，但DNS区域遍历、DoS或DDoS攻击、模拟DoS或DDoS攻击、端口洪泛、协议洪泛及请求洪泛等除外。针对此类特殊情况，客户需通过电子邮件联系AWS申请测试权限。若申请例外情况，请确保提供测试日期、涉及账户、资产、联系电话以及拟议攻击描述。

● 谷歌云平台（GCP）：谷歌明确表示，客户可自行执行渗透测试，无须申请许可或通知公司。然而，客户需遵守可接受使用政策（AUP）和服务条款（TOS），并在授权范围内开展活动。AUP和TOS禁止非法行为、钓鱼、垃圾邮件、分发恶意或破坏性文件（如病毒、蠕虫和木马），以及对GCP服务的中断。

● 微软Azure：微软采用友好型黑客策略，无须在测试前通知公司。同时，微软设有“渗透测试规则”页面，详细说明允许进行的渗透测试类型。当前，云服务提供商对渗透测试活动持积极态度。只要客户了解提供商条款，合法攻击授权目标，并避免导致服务中断的攻击，即可顺利进行渗透测试。

0.4.2　DoS测试

先前的论述中强调了DoS攻击普遍而言是不能被接受的。在与客户进行合作时，需充分了解他们对潜在风险的承受能力。将DoS测试视为一项可供希望评估其基础设施性能和可靠性的客户选择的服务。否则，便与客户协同探讨，了解他们所能接受的限度。

DoS攻击对API安全构成重大威胁。无论是故意还是无意引发的DoS攻击，都将破坏目标组织所提供的服务，导致API或Web应用程序无法访问。这种未经计划的业务中断往往成为组织寻求法律救济的导火索。因此，务必确保仅实施经授权的测试！

最终，客户是否将DoS测试纳入评估范围，取决于组织的风险承受能力，即在实现组织目标的过程中，组织愿意承担的风险程度。理解组织的风险承受能力有助于制定针对性强的测试方案。倘若某一组织位居行业前列，且对自身安全性充满信心，则其可能具备较高的风险承受能力。为高风险承受能力量身定制的项目，将涵盖连接的各功能并实施所需的各类攻击。而风险规避的另一极端则是那些行事谨慎的组织。针对这类组织的评估项目，必须要如履薄冰、小心翼翼。此类项目在评估范围中将充满细致入微的细节，即把所有可能遭受攻击的设备都明确列出，并在实施某些攻击前征求许可。

0.5　报告和修复测试

对客户而言，测试的核心价值在于我们提供的详尽报告，该报告能够精确反映API安全控制的效能。在报告中，我们应该逐一列出在测试过程中识别的安全漏洞，并针对每个漏洞提供具体的修复建议，从而帮助客户加强其API的安全性。

在规划测试范围时，我们会与客户确认是否需要进行后续的修复验证测试。一旦报告完成并交付给客户，我们就会建议客户尽快实施修复措施。随后，我们会进行再次测试，以验证之前的漏洞是否已得到妥善修复。这样的重新测试可以是有针对性的，也可以是对整个API的全面复测，以确保所有变更都没有引入新的安全风险。

0.6　关于漏洞赏金范围的说明

倘若读者期望在专业层面涉足黑客领域，成为一名漏洞赏金猎人无疑是最佳的入门途径。BugCrowd与HackerOne等机构构建了相应平台，使得任何人都能轻易创建账户并着手开展漏洞挖掘工作。同时，众多企业也自行运营漏洞赏金计划，其中包括谷歌、微软、苹果、Twitter和GitHub等知名公司。这些计划中包含大量的API漏洞赏金，部分甚至还提供额外的奖励。以BugCrowd托管的Files.com漏洞赏金计划为例，其中便包括API专属的奖励，如图0-2所示。

图0-2　漏洞赏金计划包括API专属的奖励

在漏洞赏金计划中，参与者需关注两份合约：漏洞赏金提供商的服务条款和计划的范围。违反任一合约均可能被禁止参与漏洞赏金计划，甚至引发法律纠纷。服务条款中详细阐述了关于赏金获取、漏洞报告以及参与者（包括提供商、测试人员、研究人员及黑客）之间的关系等重要事项。而范围部分则明确了目标API、描述、奖励金额、参与规则、报告要求及限制等内容。

针对API漏洞赏金，范围通常包括API文档或文档链接。表0-1整理了在进行测试前需关注的一些主要漏洞赏金考量因素。

表0-1　漏洞赏金考量因素

在你投入时间和精力之前，务必了解不同类型漏洞所能获得的潜在奖励（如果有的话）。举例来说，我曾目睹有人因有效利用速率限制而获得漏洞赏金，但漏洞赏金提供方却将其视为垃圾信息。因此，查阅过去的披露提交信息，了解组织对峙是否具有对抗性或不愿支付看似有效的漏洞赏金。同时，重点关注成功获得赏金的漏洞信息，思考漏洞猎人提交了何种证据以及他们如何报告发现的证据，以便组织能轻易确认漏洞的有效性。

0.7　小结

在本章中，我们了解了API安全测试范围的组成部分。确定API接入的范围应有助于你了解部署测试的方法及接入的规模。你还应了解可以测试和不能测试的内容，以及在接入过程中将采用哪些工具和技术。若测试方面已明确规定，并在相应规范内进行测试，将为成功的API安全测试奠定基础。

在第1章中，我们将探讨Web应用程序功能，以便更好地理解Web API的工作原理。若已掌握Web应用程序基础知识，请继续阅读第2章，我们将深入剖析Web API的技术。

第1章　Web应用程序是如何运行的

在着手探索API之前，对支持其运作的技术有全面的认识至关重要。本章将涵盖所有关于Web应用程序的内容，包括超文本传输协议（HTTP）的基本原理、身份验证与授权机制，以及常见的Web服务器数据库。Web API依赖于这些技术，掌握这些基础知识将有助于你更好地运用和攻击API。

1.1　Web应用程序基础

Web应用程序的运行基础是客户端/服务器架构。在此架构中，用户的Web浏览器，即客户端，会生成对特定资源的请求，并将这些请求发送至被称为Web服务器的计算机设备上。随后，Web服务器会通过网络将请求的资源传给客户端。术语“Web应用程序”通常用于指代那些在Web服务器上运行的软件程序，如维基百科、LinkedIn、Twitter、Gmail、GitHub和Reddit等。

尤为重要的是，Web应用程序针对终端用户进行了精心设计。相较于仅具备单向通信功能的网站，即从Web服务器传输至客户端，Web应用程序实现了双向通信，涵盖从服务器到客户端，以及从客户端至服务器的信息流动。以Reddit为例，这是一款充当互联网信息流动新闻源的Web应用程序。倘若它仅止于网站形态，访问者所能获取的仅限于网站背后组织提供的内容。然而，Reddit不同于静态网站，它赋予了用户通过发布、点赞、跟帖、评论、分享、举报不良帖子以及定制所需子社区等功能，与网站上的信息进行互动。

为了促使终端用户启用Web应用程序，必须实现Web浏览器与Web服务器之间的交互。终端用户通过在浏览器地址栏中输入URL来启动此交互。在1.1.1节中，我们将探讨后续操作。

1.1.1　URL

你可能已经知道统一资源定位符（URL）是用于定位互联网上唯一资源的地址。这个URL包含几个组成部分，在后面的章节中，当你构造API请求时，理解这些组成部分会很有帮助。所有的URL都包括使用的协议、主机名、端口、路径和任何查询参数，如下所示：

Protocol://hostname[:port number]/[path]/[?query][parameters]

协议是计算机通信所遵循的一套规则。URL中主要涉及的协议包括用于网页的HTTP、HTTPS和用于文件传输的FTP。

端口是用于指定通信通道的数字，仅在主机无法自动解析请求至正确端口时才会出现。通常情况下，HTTP通信发生在端口80上；HTTPS，即加密版的HTTP，使用端口443；而FTP则使用端口21。若要访问运行在非标准端口上的Web应用程序，可在URL中加入端口号，例如：https://www.example.com:8443（端口8080和8443分别是HTTP和HTTPS的常见替代端口）。

Web服务器上的文件目录路径用于指示URL中所指定的网页和文件位置。URL中所使用的路径与在计算机上定位文件的路径相似。

查询是URL的可选组件，具有执行搜索、过滤和翻译请求信息等功能。Web应用程序提供商亦可利用查询字符串来追踪特定信息，如引荐用户至网页的URL、会话ID或电子邮件。查询字符串以问号（？）开头，包含一组服务器编程处理的标识符。最后，查询参数为描述针对给定查询应执行操作的值。例如，跟随查询页面后的？lang=en可能表示向Web服务器指示应以英文提供所请求的页面。这些参数由Web服务器处理的另一组字符串组成。一个查询可包含多个由“&”分隔的参数。

为了使这些信息更具针对性，请参考URL（https://twitter.com/search?q=hacking&src=typed_query）。在此示例中，协议为https，主机名为twitter.com，路径为search，查询符号为?q（表示查询），查询参数为hacking，src=typed_query则是一个追踪参数。该URL是在Twitter Web应用程序的搜索栏中输入搜索词“hacking”并按下Enter键后自动生成的。浏览器被编程为以Twitter Web服务器可识别的方式构建URL，并收集一些追踪信息作为src参数。Web服务器将接收关于hacking内容的请求，并针对与hacking相关的信息做出响应。

1.1.2　HTTP请求

当终端用户通过Web浏览器访问特定URL时，浏览器会自动生成一个HTTP请求以获取相应的资源。所请求的资源通常是构成网页的文件，这些文件包含被请求的信息。此请求将通过互联网或网络路由发送至Web服务器，并在该处进行首次处理。若请求构造正确，Web服务器将把请求转发给Web应用程序。

代码清单1-1显示了对twitter.com进行身份验证时发送的HTTP请求。

代码清单1-1　对twitter.com进行身份验证时发送的HTTP请求

POST❶ /sessions❷ HTTP/1.1❸ 
Host: twitter.com❹ 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 444
Cookie: _personalization_id=GA1.2.1451399206.1606701545; dnt=1;
　
username_or_email%5D=hAPI_hacker& ❺password%5D=NotMyPassword❻ %21❼

HTTP请求由方法❶、资源路径❷和协议版本❸组成。方法部分将在后续的“HTTP方法”一节中进行详细描述，它表达了客户端对服务器的需求。在此，使用POST方法将登录凭证发送至服务器。路径可以包含整个URL、绝对路径或相对路径中的一个资源。此请求中，路径/sessions指明了处理Twitter认证请求的页面。

请求中包含一系列标头，这些键值对用于在客户端与Web服务器之间传递特定信息。标头以标头名称为始，后跟一个冒号（:），接着是标头的值。Host标头❹指定了域名主机，即twitter.com。User-Agent标头描述了客户端的浏览器和操作系统。Accept标头列出了浏览器能接收Web应用程序响应的各类内容。并非所有标头都是必需的，根据请求的需要，客户端和服务器可能包含其他未在此展示的标头。例如，此请求中包含一个Cookie标头，用于在客户端和服务器之间建立有状态的连接（关于此点，后续章节将有更多介绍）。欲了解更多关于各类标头的信息，请查阅Mozilla开发者页面关于标头的更多内容。

标头以下的部分为消息主体，即请求者试图让Web应用程序处理的信息。在此例中，主体包含用于认证Twitter账户的用户名❺和密码❻。主体中的某些字符会被自动编码，如感叹号（!）被编码为%21❼。对字符进行编码，是Web应用程序用来安全处理那些可能引发问题的字符的一种手段。

1.1.3　HTTP响应

Web服务器在接收到HTTP请求后，会依据一系列因素，如资源的可获取性、用户访问资源的授权状态、服务器的健康情况等，对该请求进行相应处理并返回响应。这些响应可能因各种条件的不同而有所差异。例如，代码清单1-2展示了对代码清单1-1中提出的请求的HTTP响应示例。

代码清单1-2　向twitter.com进行身份验证时的HTTP响应示例

HTTP/1.1❶ 302 Found❷
content-security-policy: default-src 'none'; connect-src 'self'
location: https://twitter.com/
pragma: no-cache
server: tsa_a
set-cookie: auth_token=8ff3f2424f8ac1c4ec635b4adb52cddf28ec18b8; Max-Age=157680000;
Expires=Mon, 01 Dec 2025 16:42:40 GMT; Path=/; Domain=.twitter.com; Secure; HTTPOnly;
SameSite=None
　
<html><body>You are being <a href="https://twitter.com/">redirected</a>.</body></html>

Web 服务器首先根据当前使用的协议版本（在本例中为HTTP/1.1❶）发出响应。HTTP 1.1是目前所采用的标准HTTP版本。状态码和状态信息❷将在1.1.4节中进行详细阐述，此处暂且为302 Found。302响应码意味着客户端成功通过身份验证，并将被重定向至客户端有权访问的目标页面。

注意，在HTTP中，响应部分亦包含响应标头，其作用在于为浏览器提供处理响应以及遵循安全要求的指导。set-cookie标头则是表明身份验证请求成功的另一项指标，由于Web服务器已发出一个包含auth_token的Cookie，客户端可以据此访问特定资源。响应消息主体位于响应标头之后。在此例中，Web服务器发送了一个HTML消息，提示客户端即将跳转至新页面。

所展示的请求与响应示例阐述了Web应用程序如何通过身份验证和授权来约束对其资源进行访问的普遍方法。Web身份验证是一个向Web服务器证实自身身份的过程，常见的验证形式包括提交密码、令牌或生物识别信息（如指纹）。若Web服务器接收了身份验证请求，它将通过赋予经过验证的用户访问特定资源的权限来表示授权。

在代码清单1-1中，我们观察到一个将用户名和密码发送至Twitter Web服务器（采用POST请求）的身份验证请求。Twitter Web服务器对成功的身份验证请求产生了302 Found的响应（见代码清单1-2）。set-cookie响应标头中的会话auth_token用于授权访问与hAPI_hacker Twitter账户相关联的资源。

注：

HTTP流量以明文形式传输，这意味着它在任何情况下都无法隐藏或加密。任何拦截代码清单1-1中的身份验证请求的人都可以阅读用户名和密码。为确保敏感信息的安全，HTTP请求可采用传输层安全性（TLS）进行加密，从而形成HTTPS。

1.1.4　HTTP状态码

在Web服务器对请求做出响应时，它会输出一个响应码和相应的响应消息。响应码用以表示Web服务器对请求的处理结果。事实上，响应码决定了客户端是否具备访问资源的权限。同时，它还可用于表明资源不存在、Web服务器存在故障，或请求的资源被重定向至其他位置等情况。代码清单 1-3 和代码清单 1-4 分别展示了200响应码与404响应码之间的差异。

代码清单1-3　200响应码的示例

HTTP/1.1 200 OK
Server: tsa_a
Content-length: 6552
　
<!DOCTYPE html>
<html dir="ltr" lang="en">
[...]

代码清单1-4　404响应码的示例

HTTP/1.1 404 Not Found
Server: tsa_a
Content-length: 0

200响应码表示客户端成功获取了所请求的资源，而404响应码则表明未找到所请求的资源，此时服务器可能会返回一个错误页面或空白页面。

由于Web API主要依赖于HTTP进行功能实现，因此了解从Web服务器接收到的响应码至关重要。HTTP响应码范围如表1-1所示。关于单一响应码或Web技术的其他信息，读者可查阅Mozilla的Web文档。Mozilla提供了大量关于Web应用程序架构的实用信息。

表1-1　HTTP响应码范围

1.1.5　HTTP请求方法

HTTP请求方法用于向Web服务器发起信息请求。此类请求方法亦被称为HTTP动词，包括GET、POST、PUT、HEAD、PATCH、OPTIONS、TRACE、CONNECT和DELETE等。

GET和POST分别为最常用的两种请求方法。GET请求旨在从Web服务器获取资源，而POST请求则用于向Web服务器递交数据。表1-2详细阐述了各个HTTP请求方法的相关信息。

表1-2　HTTP请求方法

一些请求方法具有幂等特性，即多次发送相同的请求不会改变Web服务器上资源的状态。举例来说，当执行开启灯光的操作时，灯光便会亮起。若灯光已处于开启状态，再次尝试开启开关，则开关仍保持开启，无任何变化。GET、PUT、HEAD、OPTIONS和DELETE等请求方法具有幂等特性。

相对而言，非幂等方法能够动态地改变服务器上资源的结果。非幂等方法包括POST、PATCH和CONNECT。POST是最常用于改变Web服务器资源的方法，用于在Web服务器上创建新资源。因此，若提交10次POST请求，将在Web服务器上创建10个新资源。反之，若使用具有幂等特性的PUT（通常用于更新资源）操作10次，则会对单个资源覆盖10次。

DELETE方法同样具有幂等特性，若发送10次删除资源的请求，资源仅会被删除一次，后续的请求则不会发生任何变化。Web API通常仅使用POST、GET、PUT、DELETE等方法，其中POST为非幂等方法。

1.1.6　有状态和无状态的HTTP

HTTP作为一种无状态协议，其在请求间并不保留任何跟踪信息。然而，在Web应用程序中，为确保用户能获得持续且一致的体验，Web 服务器有必要记录与客户端的HTTP 会话中的部分信息。例如，当用户登录账户并把若干项目添加至购物车时，Web应用程序需追踪终端用户购物车状态。否则，一旦用户浏览到其他Web页面，购物车将会被清空。

有状态连接使得服务器能够追踪客户端的操作、配置文件、图像、偏好等信息。此类连接采用名为Cookie的小型文本文件在客户端存储数据。Cookie可能保存站点特定设置、安全设置以及身份验证相关信息。与此同时，服务器通常会将数据存储在自身、缓存或后端数据库中。为了维持会话，浏览器会在请求中携带存储的Cookie。然而，在黑客攻击Web应用程序时，攻击者有可能通过窃取或伪造Cookie冒充终端用户。

在保持服务器与客户端有状态连接的过程中，存在一定的扩展限制。这种连接关系仅在创建状态时存在于特定的浏览器与服务器之间。若用户从一台计算机的浏览器切换至移动设备上的浏览器，客户端需要重新进行身份验证，并与服务器重新建立连接。此外，有状态连接要求客户端持续向服务器发送请求。当众多客户端与同一服务器维持状态时，服务器所能处理的计算资源便成为一大挑战。此类问题可通过无状态应用程序解决。

无状态通信不需要管理会话所需的服务器资源。在无状态通信中，服务器不保存会话信息，因此发送的每个无状态请求都必须包含足够的信息，使Web服务器能够判断请求者是否具备访问特定资源的权限。这类无状态请求可包含一个密钥或某种形式的授权标头，以实现与有状态连接相近的体验。与Web应用程序服务器上的会话数据不同，这些连接利用后端数据库来保存相关信息。

在购物车示例中，一种无状态应用程序可以通过修改包含特定令牌的请求所对应的数据库或缓存来追踪用户购物车的内容。虽然终端用户体验并未发生变化，但Web服务器处理请求的方式却有显著差异。由于维持了状态，每个客户端发出的请求所需的信息都可以在不丢失有状态连接中的信息的前提下，实现无状态应用程序的扩展。反之，只要请求中包含所有必要的信息，并且这些信息可以在后端数据库中查找，便可使用任意数量的服务器来处理请求。

在黑客攻击API时，攻击者可能通过窃取或伪造终端用户的令牌来实现冒充。API通信具有无状态特性，这是下一章将详细探讨的主题。

1.2　Web服务器数据库

数据库在现代服务器应用中发挥着重要作用，它使得服务器能够高效地存储资源和快速提供资源给客户端。例如，各类社交媒体平台在运营过程中均借助数据库来保存用户上传的状态更新、图片和视频等内容。这些数据库可能由平台自身负责维护，也可能作为服务提供给平台。

在Web应用程序中，用户资源通常通过前端代码传递至后端数据库来实现存储。前端代码是用户交互的部分，决定了应用的视觉和交互效果，包括按钮、链接、视频和字体等元素。前端代码通常用HTML、CSS和JavaScript编写，同时也可能采用AngularJS、ReactJS和Bootstrap等Web应用程序框架。后端由支撑前端运行的技术组成，包括服务器、应用程序和相应的数据库。后端编程语言多样，如JavaScript、Python、Ruby、Golang、PHP、Java、C#和Perl等。

在安全的Web应用程序中，用户与后端数据库之间的交互会受到多种限制。直接访问数据库将消除一道防护层，从而使数据库暴露于更为严重的攻击风险之中。当技术面向终端用户展示时，Web应用程序提供商扩大了受攻击的潜在范围，这一范围被称为攻击面。限制对数据库的直接访问有助于减小攻击面。

现代Web应用程序通常采用SQL（关系型）数据库或NoSQL（非关系型）数据库。理解SQL数据库与NoSQL数据库之间的差异，将有助于读者在后续调整API注入攻击的防范策略。

1.2.1　SQL

结构化查询语言（SQL）所涉及的数据库属于关系数据库，其中数据以表格形式进行组织。表格中的行称为记录，用于标识具有不同数据类型的数据，如用户名、电子邮件地址或权限级别等。而表格的列则代表数据的属性，涵盖所有用户名、电子邮件地址及权限级别等信息。在表1-3至表1-5中，UserID、Username、Email和Privilege均为数据类型。表格的行则代表了给定表格中的数据。

表1-3　关系User表

表1-4　关系Email表

表1-5　关系Privilege表

要在SQL数据库中检索数据，应用程序需编写相应的SQL查询语句。一个典型的SQL查询示例旨在查找UserID为111的客户记录，如下所示：

SELECT * FROM Email WHERE UserID = 111;

该查询语句旨在从Email表中选取UserID列值为111的所有记录。SELECT语句用于从数据库检索信息，星号（*）为通配符，表示选取表中的所有列；FROM子句用于指定所使用的表；WHERE子句则用于筛选特定结果。

SQL数据库尽管存在多种类型，但其查询方式大致相同。常见的SQL数据库包括MySQL、Microsoft SQL Server、PostgreSQL、Oracle以及MariaDB等。

后续章节将阐述如何通过发送API请求来检测SQL注入等注入漏洞。SQL注入作为一种经典的Web应用程序攻击手段，已存在20多年，但在API领域仍需保持警惕。

1.2.2　NoSQL

NoSQL数据库，又称为分布式数据库，是非关系数据库，表示其不遵循关系数据库的结构。这类数据库通常是开源工具，用于处理非结构化数据，并以文档形式存储数据。与关系数据库不同的是，NoSQL数据库采用键值对形式存储信息，而非关系。与SQL数据库相比，不同类型的NoSQL数据库具有各自的结构特点、查询方式以及潜在漏洞和利用手段。以下为一个使用MongoDB的查询示例，MongoDB目前位居NoSQL数据库市场之首：

db.collection.find({"UserID": 111})

在此示例中，db.collection.find()是用于在文档中查找UserID为111相关信息的方法。MongoDB中有若干个运算符。

● $eq：匹配等于指定值的值。

● $gt：匹配大于指定值的值。

● $lt：匹配小于指定值的值。

● $ne：匹配所有不等于指定值的值。

在NoSQL查询中，这些运算符可帮助我们筛选和选取所需的信息。在不知道确切的UserID的情况下，我们可以采用上述运算符进行查询，如下所示：

db.collection.find({"UserID": {$gt:110}})

这个查询将筛选出所有UserID大于110的记录。理解这些运算符对于后续深入学习NoSQL注入攻击至关重要。

NoSQL数据库家族庞大，包括MongoDB、Couchbase、Cassandra、IBM的Domino、Oracle的NoSQL Database、Redis和Elasticsearch等数据库。

1.3　API如何融入整体架构

Web应用程序能够实现更为卓越的功能，前提是其能充分利用其他应用程序的特性。应用程序编程接口（API）是一种推动应用程序之间互动的技术。特别是，Web API通过HTTP实现机器间的通信，为连接各类应用程序提供了便捷的途径。

这个功能为应用程序提供商开启了一扇大门，开发人员无须成为为终端用户提供各种功能的专家。以共享乘车应用程序为例，该应用程序需要地图帮助司机在城市中导航，一种处理支付事宜的方式以及一种司机与客户之间通信的手段。开发人员可以借助Google Maps API实现地图功能，借助Stripe API处理支付事宜，以及借助Twilio API实现短信通信，而非针对每个特定功能进行专业化处理。开发人员可以整合这些API以创建全新的应用程序。

这项技术的直接影响表现在两个方面。首先，信息交换得以简化。通过采用HTTP，Web API可以利用标准方法、状态码以及客户端/服务器关系，使开发人员能够编写能自动处理数据的代码。其次，API允许Web应用程序提供商实现专业化，因为他们不再需要亲自打造Web应用程序的每一个环节。

API是一项具有全球影响力的非凡技术。然而，正如后续章节所阐述的，它们也极大地扩大了互联网上使用这些API的每个应用程序的潜在攻击面。

1.4　小结

在本章中，我们探讨了Web应用程序的基本要素。若你对HTTP请求与响应、身份验证/授权以及数据库的一般功能有所了解，那么理解Web API将不再困难，因为Web应用程序的基础技术与Web API的基础技术密切相关。在第2章中，我们将深入探讨API的结构。

本章的目标是让你具备足够的知识，成为一个敏锐的API研究者，而非开发人员或应用程序架构师。