写在最后
还有一份JAVA核心知识点整理（PDF）：JVM，JAVA集合，JAVA多线程并发，JAVA基础，Spring原理，微服务，Netty与RPC，网络，日志，Zookeeper，Kafka，RabbitMQ，Hbase，MongoDB，Cassandra，设计模式，负载均衡，数据库，一致性哈希，JAVA算法，数据结构，加密算法，分布式缓存，Hadoop，Spark，Storm，YARN，机器学习，云计算…
图表：现代 Web 应用程序模型
相对SPA形式，现代Web应用程序模型是一个更好的解决方案，因为它更容易扩展并允许更专业的开发人员为项目工作，即前端开发人员只关注前端工作，而后端开发人员则在 API 上工作。这些应用程序也往往感觉更快速，因为不是每个请求都需要页面加载。
然而，同一页面的不同组件也会神奇地刷新，会给使用者一种与原生应用程序类似的感觉。这也使得这种模型也变得越来越流行，因为大量不同的前端 JavaScript 框架（React、Vue 和 Angular 等）已经出现。
这就是说——现代应用程序到处都有 API，所以我们应该学习如何破解和保护它们。
API测试配置
=======
Postman 是一个方便进行 API 安全测试的应用程序。你可以从其官方网站下载 Postman 。 本质上，Postman 只是另一个 HTTP 客户端，可用于轻松修改并向 API 发送请求。
如果你的文件中有一组 API 请求，可以通过单击应用程序左上角的“导入”按钮将它们导入 Postman ：
导入集合后，你将看到 Postman 中加载的 API 调用，如下所示：
通过单击单个 API 调用，将在右侧看到完整的 API 请求。同时，请求的不同部分将被分解为Params、Authorization、Headers、RequestBody等部分，这将帮助你轻松地处理每个部分。
你可以像在 BurpSuite 中一样修改请求标头和正文，分析对测试用例的响应，你只需点击右上角的发送按钮即可。
Postman 中的响应视图看起来像这样，响应也分为不同的部分，如正文、Cookie、标题等，你可以仔细分析每个部分。
由于 Postman 专门用于 API，因此有许多内置选项来测试 API 主要存在的功能。例如，通过单击请求方法旁边的下拉箭头，你可以看到大量不同的请求动词以进行测试：
对于 GET 请求，你可以通过Params选项卡添加/删除以及编辑参数。当你选中/取消选中参数时，你可以看到它们相应地出现在 URI 字段中。
在添加授权值时，Postman 为你提供了多种选项供你选择，你可以根据目标 API 处理授权的方式选择一个。
你还可以按照以下步骤将授权值添加到整个集合或子集合：
- 单击集合/子集合名称旁边的三个点，然后选择“编辑”选项
- 转到“授权”选项卡，选择身份验证类型并添加其值。
- 最后，转到单个 API 请求并选择Inherit auth from parent选项
这将为你省去为每个请求设置授权值的麻烦。
Postman 另一个方便的特性是它允许用户使用 BurpSuite 代理 API 请求。你可以执行以下步骤进行设置：
- 从右上角的下拉菜单中单击设置选项
- 转到代理选项卡并执行以下操作：
a) 关闭使用系统代理
b) 打开添加自定义代理配置
c) 设置了 代理服务器的IP地址和端口，以配合你打嗝套房代理设置。默认值为 127.0.0.1 和 8080。你的最终设置应该如下所示：
3. 在没有任何错误的情况下代理 HTTPS 请求，你可以在“常规”选项卡下关闭SSL 证书验证。
API漏洞类型
=======
API 有多种不同的形式，攻击 API 的方法会因这些形式的不同而有很大的差异。在一篇文章中涵盖所有攻击类型是不可能的，下面我重点介绍其中一部分。
API 暴露
与 Web 应用程序非常相似，API 可以具有不同级别的可见性。有些可以通过互联网访问，而有些则只能在内部使用。API 攻击方式之一就是简单地访问你应该无法访问的 API。这可以通过以下方法来达到访问目的，包括：
-
强制浏览：如果幸运的话，仅供内部使用的 API 可能会意外暴露在 Internet 上，这可能是由于配置错误导致，或者仅仅是因为假设没有人能够找到它。在API攻击时可以通过多种方式发现，比如分析 JavaScript 文件、分析暴露的源代码、观察主机名（例如api.internal.example.com）和 Google dorking等。
-
反射或旋转：比如在外部主机上发现像 SSRF 这样的漏洞可能允许你转向内部 API。
预防措施
有许多最佳实践可以帮助你减轻无意暴露 API 的风险，包括实施严格的部署实践、通过 IAM 和网络分段强制执行最小权限原则等。
错误配置的缓存
对于需要身份验证的 API，返回的数据通常是动态生成的，并且范围限定为每个 API 密钥。例如，/api/v1/userdetails以 Bob 身份访问应返回 Bob 的详细信息，而以 Jane 身份访问同一端点应返回 Jane 的详细信息。
当 API 不使用标准Authorization标头，而是使用自定义标头（如X-API-Key. 缓存服务器可能不会将此识别为经过身份验证的请求，并且可能会缓存它。
如果是这种情况，并且没有Cache-Control或Pragma标题，则简单地访问/api/v1/userdetails可能会泄露另一个用户的信息。
预防措施
对此问题的解决方法是实现Cache-Control或Pragma标头，并使用标准Authorization标头。
暴露的令牌
我们不应该忽视最基本的身份验证攻击，通过发现 API 密钥可能会获取 API 的访问权限。更糟糕的是，那些仅供内部使用的 API，通常不需要实现复杂的身份验证流程，通常实现静态令牌作为其身份验证，并将令牌存储在代码存储库、客户端 JavaScript、拦截流量等中。
预防措施
在DevOps 管道中，实施代码扫描检测 API 密钥部署到它们不应该存在的地方，在部署之前捕获它们。另外，一些代码存储库提供者（包括GitHub），在推送 API 密钥之前检测它们。
JWT的弱点
如果你的 API 令牌是由两个点 (.) 分隔的三个 base64blob构成，则它可能是一个JSON Web 令牌 (JWT)。这些令牌在理论上是安全的，但是有很多方法会以引入安全问题的方式来弄乱实现。在我们深入研究 JWT 攻击之前，我们将快速阅读 JWT 入门。
这是一个示例 JWT 令牌，根据你的阅读习惯进行了着色：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9。eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9liwiaWF0IjoxNTE2MjM5MDIyfQ . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
有三个由点分隔的 base64 编码字符串，第一部分（红色）是header. 第二个（紫色）是payload，第三个（蓝色）是signature。
如果我们解码第一部分，也称为标头，我们将看到以下内容：
{
“alg”: “HS256”,
“typ”: “JWT”
}
这就是令牌所使用的算法 (HS256) 和令牌类型 (JWT)，如果你之前没有使用过 JWT，你可能会想“为什么我们需要算法？”
令牌的第二部分也称为有效载荷，解码后我们将看到以下内容：
{
“sub”: “1234567890”,
“name”: “John Doe”,
“iat”: 1516239022
}
此部分可以包含任何内容，但至少需要包含用户标识符和超时服务 (iat)。
令牌的第三部分（也称为签名）用密钥对前两部分进行签名。在这种情况下，它使用 HS256 算法进行签名，它可以通过查看标头中的“alg”值来确定。一般来说私钥应该只为应用程序的所有者知道。当应用程序收到 JWT 令牌时，它可以通过解密签名并将其与标头和有效负载中的数据进行比较来验证令牌是否合法。如果数据匹配则验证数据，否则无效。
那么为什么会有人使用 JWT？这是因为它不需要服务器端会话管理。传统上，当用户登录时，应用程序会为用户分配一个秘密令牌并将该令牌存储在数据库中。每当用户使用他们的令牌发出请求时，应用程序需要检查令牌是否在数据库中。如果是，则允许用户继续，否则不允许。当我们使用 JWT 时，我们引入了一种信任从客户端发送的数据的方法，而不是仅仅信任存储在数据库中的信息。如果应用程序收到可以使用密钥验证的 JWT 令牌，则应用程序没有理由不信任它。
正如我们之前提到的，理论上 JWT 令牌是完全安全的。问题是它们通常以不安全的方式实施。这里有些例子：
-
None 算法：JWT 的一些实现将允许你指定“None”作为算法。如果算法为“无”，应用程序将不会检查签名的有效性，因此你可以简单地将有效负载更新为你想要的任何内容。最明显的利用是将用户 ID 更新为另一个用户以控制他们的帐户。
-
暴力破解：可以暴力破解 JWT 令牌的密钥。这种攻击的可行性将取决于密钥的强度。你可以尝试使用此工具破解 JWT 令牌。可以在Auth0 的博客上找到有关该方法的完整文章。
-
简单地改变有效载荷：在极少数情况下，服务器可能会完全跳过令牌验证并信任有效载荷中的数据。虽然我没有亲眼见过这种情况，但我已经读到它发生在野外！
-
将 RS 切换到 HS：一些较旧的 JWT 库存在一个缺陷，你可以在其中欺骗期望使用非对称加密签名的令牌的应用程序接受对称签名的令牌。最终被使用的对称签名令牌实际上是一个公钥，它通常可以以某种方式获得，或者从他们的 HTTPS 密钥中重用。有这种方法的一个伟大的书面记录在这里。
-
在超时未兑现，那么JWT令牌仍然有效，直到永远。
预防措施
JWT 弱点的最佳缓解方法是为所有 JWT 操作使用广泛使用的、信誉良好的 JWT 库。
授权问题/IDOR
授权是检查经过身份验证的用户是否有权访问特定用户的过程。与授权相关的常见漏洞称为不安全的直接对象引用 (IDOR)。例如，在发票应用程序的 API 中，我们可能有一个端点用于获取发票的详细信息：/api/v1/invoices/?id=1234
该id参数是应返回的发票的标识符，当这个端点是安全的，我应该只能获得属于我的发票的详细信息。例如，如果我创建了一个 ID 为 1234 的发票，那么它应该返回1234的详细信息；
如果我尝试访问不是通过浏览创建的发票/api/v1/invoices/?id=1233，它应该返回错误。如果我能够更改标识符并可以查看其他用户（如1233）的发票详细信息，那么这就是一个称为 IDOR 的漏洞。
为了解决 IDOR 问题，当今许多 API 都使用 UUID 作为对象标识符。UUID 如下所示：
f1af4910-e82f-11eb-beb2-0242ac130002
需要注意的是，使用 UUID 作为标识符并不是缓解 IDOR 问题的有效方法。事实上，UUID RFC特地将这一点称为：
不要假设 UUID 很难猜测；例如，它们不应该用作安全功能（仅拥有就可以访问的标识符）。可预测的随机数源会加剧这种情况。
虽然将 UUID 用作对象 ID 而不是整数是一种很好的做法，但它们永远不应用作抵御 IDOR 攻击的唯一保护措施。
预防措施
授权问题通常很难以自动化方式检测。代码库的结构一般难以在特定端点上发生授权错误的方式设置。为实现这一点，应尽可能在堆栈上实施授权措施。比如在类级别或使用中间件级别。
未记录的端点
在API攻击过程中，遇到没有API文档（或至少没有你可以访问的文档）的情况是很常见的。带有文档的 API 具有超出文档内容的其他访问端点也很常见。有时，这些端点的存在本身可能是一个安全问题——例如，端点可能是为管理目的而设计的，并允许你作为弱势用户执行管理任务。其他时候，这些端点可能会出现漏洞，因为它们没有像容易发现的端点那样经过彻底的测试。
我们可以利用以下几种方法来发现未记录的端点：
-
使用与 API 接口的应用程序并捕获流量。比如Burp Suite。
-
设置 Burp Suite 来代理应用程序流量
-
使用所有应用程序功能
-
通过查看目标选项卡检查使用的端点。
-
观察错误。许多 API 会给出足够详细的错误来枚举未记录的端点和参数。例如，向发送一个空白的 POST 请求/api/v1/randomstring可能会导致出现类似Invalid route, valid routes are [/users,/invoices,/customers].
-
分析客户端 JavaScript。如果你知道与 API 交互的应用程序，你可以分析该应用程序中的 JavaScript 以收集可访问的 API 端点列表。
-
使用Kiterunner，这是Assetnote的一个工具，专为 API 上的内容发现而设计
-
暴力猜测端点，Assetnote 网站上有一些优秀的API词表
预防措施
拥有一个强大的、结构化的方法和流程来记录 API 功能可以避免很多麻烦。
Swagger正是这一点的绝佳标准。此外，最好在编码之前用文档规划 API 功能，而不是相反。
不同API版本问题
当一个组织发布一个 API 时，它可能会与许多不同的应用程序接口。如果 API 在任何时候更新，它可能会为这些应用程序中的一个或多个API引入重大更改。出于这个原因，多个 API 版本通常被实现为支持旧的API 模式的一种方式，同时也随着时间的推移为新用户升级 API。
测试 API 的所有版本是一个值得投入的攻击方式。旧版本可能仍然存在已在新版本中修复的安全问题，而较新的/前沿/测试版可能引入了新的安全问题。
api 版本控制的常见模式是：
/api/v1/ /api/v2/ /api/beta/
检查非生产环境名称也是不错的选择，例如：
qa devenv devenv1 devenv2 preprod pre-prod test testing staging stage dev development deploy slave master review prod uat prep Version2
该词表取自DNSCewl 中的示例集。
预防措施
可以通过定义的生命周期支持 API 版本。例如，当你发布 API 的V2 版本时，你可能会通知你的用户V1版本将达到生命周期终止 (EoL) 并在未来的特定日期被弃用。预生产/测试版只有在经过彻底的安全问题测试后才能公开访问。
限速
大多数情况下，API 对用户可以请求它们的次数没有任何保护，这被称为“缺乏速率限制”，当攻击者可以调用 API 数千次以导致一些意外行为时，就会发生这种情况。服务器将尝试满足这些请求中的每一个，这可能会：
-
通过使用请求重载服务器来对服务器进行 DOS 处理
-
允许攻击者快速泄露敏感的用户信息，例如：用户 ID、用户名、电子邮件等。
-
通过强制登录 API 绕过身份验证
-
通过强制向受害者发送电子邮件/短信的功能来淹没受害者的收件箱
让我们看一个攻击场景，其中对检查凭据的 API 端点没有速率限制：
GET/api/v1/user/1234/login/?password=mypassword
通常，你不会看到这样在 GET 请求中发送的密码，但出于演示说明的目的，假设你看到了。为了在上面的端点中暴力破解密码，攻击者可以使用BurpSuite 的 Intruder工具。这个工具允许我们自定义不同类型的蛮力攻击，但在这个例子中，我们将提供一个简单的密码列表。
在几秒钟内，Intruder 将发出数百个 API 请求，对每个请求尝试不同的密码。
GET /api/v1/user/1234/login/?password=notmypassword1
GET /api/v1/user/1234/login/?password=notmypassword2
GET /api/v1/user/1234/login/?password=notmypassword3
.
.
GET /api/v1/user/1234/login/?password=correctpassword!
由于没有速率限制，服务器会响应所有请求，攻击者可以继续使用不同的密码进行暴力破解，直到找到正确的密码。
为了防止速率限制错误，应用程序应该对用户在特定时间范围内请求 API 的频率实施限制。设置的确切限制将取决于该 API 或端点的用例。
预防措施
速率限制可以通过许多不同的方式实现。每个帐户、每个 IP 地址、每个端点、整个 API 等。一些反向代理也可用于实现应用程序范围的节流，而无需额外开发。
具体你使用怎样的实现将取决于特定应用程序的要求。
竞争条件
竞争条件是在同一毫秒内向 API 发送两个或多个请求。当 API 没有处理这种竞争情况的机制时，可能会导致 API 以意外的方式处理请求。在易受攻击的电子商务应用程序上兑换折扣或促销码时，可能会出现竞争条件的潜在攻击场景。
POST /api/v1/discount
Target: www.ecommerce.com
Connection: close
{
“code”,“first10”,
“amount”:“10”
}
BurpSuite 有一个名为Turbo Intruder的扩展，它允许用户使用内置race.py脚本测试竞争条件。在 Turbo Intruder 中配置攻击后，攻击者可以向 API 发送多个并发请求以兑换此促销码。
POST /api/v1/discount 200 OK
POST /api/v1/discount 200 OK
POST /api/v1/discount 200 OK
POST /api/v1/discount 404NotFound
POST /api/v1/discount 404NotFound
如果 API 在收到第一个并发请求后没有立即使促销码失效，则折扣金额可能会增加一倍、三倍等。
这种攻击被称为“竞争条件”，因为它是攻击者发送修改资源请求的速度与应用程序更新该特定资源的速度之间的竞争。
预防措施
最后
针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。
下面的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题（都整理成文档，小部分截图）
最新整理电子书
1/discount 404NotFound
如果 API 在收到第一个并发请求后没有立即使促销码失效，则折扣金额可能会增加一倍、三倍等。
这种攻击被称为“竞争条件”，因为它是攻击者发送修改资源请求的速度与应用程序更新该特定资源的速度之间的竞争。
预防措施
最后
针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。
下面的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题（都整理成文档，小部分截图）
[外链图片转存中…(img-yKaftN8O-1715677630813)]
最新整理电子书
[外链图片转存中…(img-LGfuJWmL-1715677630813)]
扫一扫
816
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
