常见API接口漏洞
相识接口常见漏洞，将帮助你在测试接口获取更多的思绪。
信息披露
信息可能会在 API 响应或公共来源（如代码存储库、搜刮效果、新闻、社交媒体、目标网站和公共 API 目录）中披露。
敏感数据可以包含攻击者可以利用的任何信息。
例如，利用WordPress API的网站可能会在不知不觉中与导航到API路径的任何人共享用户信息。/wp-json/wp/v2/users
- GET https://www.sitename.org/wp-json/wp/v2/users[{"id":1,"name":"Administrator", "slug":"admin"}],{"id":2,"name":"Vincent Valentine", "slug":"Vincent"}]
错误消息可帮助 API 利用者排查其与 API 的交互问题，并允许 API 提供者相识其应用程序的问题。但是，它也可以展现有关资源、用户和 API 底层体系结构（例如 Web 服务器或数据库的版本）的敏感信息。
通常，您可以通过与 API 终端节点交互并分析响应来收集最多信息。API 响应可以表现标头、参数和详细错误中的信息。其他良好的信息来源是在侦探期间收集的 API 文档和资源。
断开的对象级别授权
当 API 提供者允许 API 利用者访问他们无权访问的资源时，就会发生 BOLA 漏洞。
例如，假设我们被授权仅访问用户Cloud Strife。我们会向 https://bestgame.com/api/v3/users?id=5501 发送初始 GET 哀求
- { "id": "5501", "first_name": "Cloud", "last_name": "Strife", "link": "https://www.bestgame.com/user/strife.buster.97", "name": "Cloud Strife", "dob": "1997-01-31", "username": "strife.buster.97"}
通常，您可以通过相识 API 的资源结构并实验访问不应访问的资源来测试 BOLA。通过检测 API 路径和参数中的模式，您应该可以或许猜测其他潜在资源。
BOLA 可能是一个低悬的 API 漏洞，您可以利用模式识别轻松发现它，然后通过几个哀求来刺激它。其他时候，由于对象 ID 的复杂性以及用于获取其他用户资源的哀求，发现起来可能非常复杂。
用户身份验证停止
用户身份验证停止是指 API 身份验证过程中的任何弱点。当 API 提供程序未实现身份验证掩护机制或未精确实现机制时，通常会发生这些漏洞。
正如我们从第2章讨论的REST API的六个约束中知道的那样，RESTful API应该是无状态的。为了成为无状态的，提供者不必要记住从一个哀求到另一个哀求的利用者。要使此约束起作用，API 通常必要用户履历注册过程才能获得唯一的令牌。然后，用户可以在哀求中包含令牌，以证明他们有权发出此类哀求
例如，为了确定代币生成过程是否较弱，我们可以收集代币样本并分析它们的相似性。如果令牌生成过程不依靠于高级别 随机性或熵，我们有可能创建自己的令牌或劫持别人的令牌。
令牌处理可以是令牌的存储、通过网络传输令牌的方法、硬编码令牌的存在等。我们大概可以或许在 JavaScript 源文件中检测硬编码令牌，大概在分析 Web 应用程序时捕获它们。捕获令牌后，我们可以利用它来访问以前隐藏的终结点或绕过检测。如果 API 提供者将身份归因于令牌，我们将通过劫持被盗令牌来承担身份。
其他可能具有自己的一组漏洞的身份验证过程包括注册系统的各个方面，例如暗码重置和多重身份验证功能。例如，假设暗码重置功能要求您提供电子邮件地点和六位数代码来重置暗码。好吧，如果API允许您发出任意数目标哀求，则只需发出一百万个哀求即可猜测代码并重置任何用户的暗码。一个四位数的代码只必要 10，000 个哀求。
由于 REST API 的无状态性质，公开的 API 密钥等效于发现用户名和暗码。通过利用公开的 API 密钥，你将代入与该密钥关联的角色。
过度的数据泄露
过度数据泄露是指 API 端点响应的信息多于满足哀求所需的信息。
当存在此漏洞时，可能相当于向或人扣问其姓名，并让他们利用其姓名，出生日期，电子邮件地点，电话号码以及他们认识的每个人的身份举行响应。
假设我哀求了自己的帐户信息，并提出了以下哀求：
- GET /api/v3/account?name=Cloud+Strife# respone { "id": "5501", "first_name": "Cloud", "last_name": "Strife", "privilege": "user", "representative": [ "name": "Don Corneo", "id": "2203" "email": "dcorn@gmail.com", "privilege": "super-admin" "admin": true "two_factor_auth": false, }
缺乏资源和速率限定
速率限定在 API 的货币化和可用性中起着重要作用。如果不限定利用者可以发出的哀求数目，API 提供商的基础办法可能会被哀求淹没。没有充足资源的哀求过多将导致提供商的系统崩溃并变得不可用 - 例如，拒绝服务（DoS）状态RapidAPI允许每月免费500个哀求，但付费客户每月允许1，000个哀求。
一旦您被限定提出其他哀求，就该实验查看如何实验速率限定了。您可以通过添加或删除参数、利用其他客户端或更改 IP 地点来绕过它吗？
停止的功能级别授权
停止的功能级别授权 （BFLA） 是一个角色或组的用户可以或许访问另一个角色或组的 API 功能的漏洞。
BFLA 与 BOLA 类似，不同之处在于不是涉及访问资源的授权问题，而是执行操作的授权问题。
当 API 中存在 BOLA 漏洞时，您可能可以或许访问该信息 其他帐户，例如付款历史记录、用户名、电子邮件地点和帐号 如果存在 BFLA 漏洞，您可能可以或许转账并现实更新帐户信息。相反，该功能可以基于 HTTP 哀求方法，例如 、、 和 。如果提供程序不限定利用者可以利用的 HTTP 方法，则只需利用其他方法举行 a 即可指示 BFLA 漏洞。
- GET``POST``PUT``DELETE``unauthorized request
质量分配
当 API 利用者在其哀求中包含比应用程序预期更多的参数，并且应用程序将这些参数添加到代码变量或内部对象时，就会发生批量分配。“我以为这看起来像参数污染”
例如，应用程序可能具有帐户更新功能，用户应仅利用该功能来更新其用户名、暗码和地点。如果利用者可以在与其帐户相关的哀求中包含其他参数（如帐户权限级别或敏感信息（如帐户余额），并且应用程序担当这些参数而不根据允许操作的白名单检查它们，则利用者可以利用此弱点来更改这些值。
- // Imagine an API is called to create an account with parameters for "User" and "Password":{"User": "scuttleph1sh","Password": "GreatPassword123"}//While reading the API documentation regarding the account creation //process, suppose you discover that there is an additional key, "isAdmin", that //consumers can use to become administrators. You could use a tool like //Postman or Burp Suite to add the attribute to a request and set the value //to true:{"User": "scuttleph1sh","Password": "GreatPassword123","isAdmin": true}
安全配置错误
安全配置错误包括开辟职员在 API 的支持安全配置中可能犯的所有错误。例如，如果 API 的支持安全配置展现了未修补的漏洞，则攻击者有可能利用已发布的漏洞轻松“pwn”API 及其系统。
安全配置错误现实上是一组弱点，包括配置错误的标头、配置错误的传输加密、利用默认帐户、担当不须要的 HTTP 方法、缺乏输入整理和详细的错误消息。
缺乏输入整理可能允许攻击者将恶意负载上传到服务器。
例如，如果利用上传端点将上传的文件传递到 Web 目录，则它可能允许上传脚本。导航到文件所在的 URL 可以启动脚本， 导致对 Web 服务器的直接外壳访问。
API 提供程序利用标头为利用者提供处理响应和安全要求的说明。配置错误的标头可能导致敏感信息泄露、降级攻击和跨站点脚本攻击。
例如，采用以下响应：
- HTTP/ 200 OK--snip--X-Powered-By: VulnService 1.11 // reveal backend tech => search exploitsX-XSS-Protection: 0 // could be changed to 1X-Response-Time: 566.43//If the X-Response-Time header has a consistent response time for nonexistent records, for example, but increases // its response time for certain other records, this could be an indication that those records exist.HTTP/UserA 404 Not Found--snip--X-Response-Time: 25.5HTTP/UserB 404 Not Found--snip--X-Response-Time: 25.5HTTP/UserC 404 Not Found--snip--X-Response-Time: 510.00
例如，您知道像如许的虚伪帐户的平均X响应时间为ms。您还知道，您现有的帐户 /user/account/1021 收到的 X 响应时间为 。如果您随后发送了哀求，强制所有帐号从 到 ，您可以查看效果并查看哪些帐号导致响应时间大幅增加。/user/account/thisdefinitelydoesnotexist87625.5510.0010002000
任何向利用者提供敏感信息的 API 都应利用传输层安全性 （TLS） 来加密数据。即使 API 仅在内部、私有或合作同伴级别提供，利用 TLS（加密 HTTPS 流量的协议）也是确保 API 哀求和响应在通过网络传递时受到掩护的最基本方法之一。配置错误或缺少传输加密可能会导致 API 用户以明文情势跨网络传递敏感的 API 信息。然后攻击者可以利用MITM攻击来利用它。
当服务利用默认帐户和凭据并且默认值已知时，攻击者可以利用这些凭据代入该帐户的角色。这可能允许他们访问敏感信息或管理功能，可能导致 支持系统。
末了，如果 API 提供程序允许不须要的 HTTP 方法，则应用程序无法精确处理这些方法或导致敏感信息泄露的风险会增加。
您可以利用 Web 应用程序漏洞扫描程序（如 Nessus、Qualys、OWASP ZAP 和 Nikto）检测其中的几个安全错误配置。这些扫描程序将自动检查 Web 服务器版本信息、标头、cookie、传输加密配置和参数，以查看是否缺少预期的安全步伐。如果您知道要查找的内容，也可以通过检查标头、SSL 证书、cookie 和参数来手动检查这些安全配置错误。
注入
当哀求传递到 API 的支持基础结构并且 API 提供程序不筛选输入以删除不必要的字符（此过程称为输入整理）时，存在注入缺陷。详细的错误消息、HTTP 响应代码和不测的 API 举动都可能是您可能发现了注入缺陷的线索。
API 可能会将该有效负载直接传递到后端 SQL 数据库，其中 OR 1=0 语句将失败（由于 1 不即是 0），从而导致一些 SQL 错误：
- POST /api/v1/register HTTP 1.1Host: example.com--snip--{"Fname": "hAPI","Lname": "Hacker","Address": "' OR 1=0--",}
GET http://10.10.78.181:5000/api/v1/resources/books？show=/etc/passwd
- root:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews:x:9:9:news:/var/spool/news:/usr/sbin/nologin
资产管理不当
当构造公开 API 时，会发生不精确的资产管理 已停用或仍在开辟中。仍在开辟的 API 通常不如生产 API 对应项安全。
资产管理不当会导致其他漏洞，例如数据过度袒露、信息泄露、批量分配、速率限定不当和 API 注入等。
您可以通过密切关注堆栈中过期的 API 文档、更改日志和版本历史记录来发现不当的资产管理。
构造通常在其终结点名称中包含版本控制信息，以区分较旧版本和较新版本，例如 等。仍在开辟中的 API 通常利用诸如 .如果您知道 API 现在正在利用 apiv3.org/admin 但 API 文档的一部分提到了 apiv1.org/admin，则可以实验测试不同的端点以查看 apiv1 或 apiv2 是否仍处于运动状态。此外，构造的更新日志 可能会披露 v1 更新或停用的缘故原由。如果您有权访问 v1，则可以测试这些弱点/v1/, /v2/, /v3//alpha/, /beta/, /test/, /uat/, and /demo/
在利用文档之外，您还可以通过利用猜测、模糊测试或暴力哀求来发现不精确的资产管理漏洞。观察 API 文档或路径定名方案中的模式，然后根据您的假设发出哀求。
业务逻辑漏洞
业务逻辑漏洞（也称为业务逻辑缺陷或 BLF）是攻击者可以恶意利用的应用程序的预期功能。
例如，如果 API 具有不验证编码有效负载的上传功能，则只要任何文件已编码，用户就可以上传该文件。这将允许最终用户上传和执行任意代码，包括恶意负载。在这些环境下，构造基本上依靠于 信托作为一种安全控制，盼望消耗者采取仁慈的举动。不幸的是，即使是善良的 API 利用者也会犯错误，从而导致应用程序受损。
您可以在 API 文档中搜刮业务逻辑漏洞的迹象。像下面的陈述应该照亮你头顶的灯泡：
“仅使勤奋能 X 来执行功能 Y。” “不要对端点 Y 执行 X。” “只有管理员才能执行哀求 X。”
当您攻击他们的 API 时，请确保不平从此类哀求以测试是否存在安全控制。
例如，请考虑用户通常用来对其帐户举行身份验证的 Web 应用程序身份验证流派。假设 Web 应用程序发出了以下 API 哀求：
- POST /api/v1/login HTTP 1.1Host: example.com--snip--UserId=hapihacker&password=arealpassword!&MFA=true
测试业务逻辑缺陷可能具有寻衅性，由于每个业务都是独一无二的。自动扫描程序将很难检测到这些问题，由于这些缺陷是API预期用途的一部分。您必须相识业务和 API 的运作方式，然后考虑如何利用这些功能来发挥自己的优势。以对抗的心态研究应用程序的业务逻辑，并实验打破任何假设 被制造
总结
熟悉这些漏洞非常重要，如许您就可以轻松识别它们，在参与渗出测试期间利用它们，并将其报告给构造，以防止犯罪分子将您的客户拖入头条新闻。现在您已经熟悉了 Web 应用程序、API 及其弱点。
学习计划安排
我一共划分了六个阶段，但并不是说你得学完全部才能上手工作，对于一些初级岗位，学到第三四个阶段就足矣~
这里我整合并且整理成了一份【282G】的网络安全从零基础入门到进阶资料包，必要的小同伴可以扫描下方CSDN官方合作二维码免费领取哦，无偿分享！！！
如果你对网络安全入门感兴趣，那么你必要的话可以
点击这里 |
