上一篇学习了OWASP API 安全top10的前5个漏洞，下面继续讨论后面5个漏洞及其潜在影响和缓解措施。
API6:2019 批量分配
API7:2019 安全配置错误
API8:2019 注入
API9:2019 资产处理不当
API10:2019 日志记录和监控不足

API6:2019 批量分配

这是怎么发生的
批量分配反映了客户端数据自动与服务器端对象或类变量绑定的场景。然而，黑客通过首先了解应用程序的业务逻辑并向服务器发送特制数据、获取管理访问权限或插入篡改数据来利用该功能。此功能在 Laravel、Code Ignitor 等最新框架中得到了广泛利用。
考虑用户的 个人资料仪表板，用户可以在其中更新其个人资料，例如关联的电子邮件、姓名、地址等。用户的用户名是只读属性，无法更改；但是，恶意行为者可以编辑用户名并提交表单。如果服务器端（模型）没有启用必要的过滤，它将简单地插入/更新数据库中的数据。 
可能的影响 
该攻击可能会导致数据篡改以及从普通用户到管理员的权限提升。
攻击场景示例
现在有一个API端点/apirule6/user ，该端点将名称、用户名和密码作为输入参数 (POST)。用户的表有一个credit column默认值为50。用户将升级会员资格以获得更大的信用值。开发者没有在服务器端进行任何过滤。由于使用了批量分配功能，他还在数据库中插入信用值（恶意行为者可以更新该值）

缓解措施
在使用任何框架之前，必须研究后端插入和更新是如何进行的。在 Laravel 框架中，可填充数组和受保护数组缓解了上述情况。 
避免使用将客户端输入自动绑定到代码变量的函数。
仅将那些需要从客户端更新的属性列入白名单。

API7:2019 安全配置错误

这是怎么发生的
安全配置错误描述了安全控制的实施不正确且配置不当，从而危及整个API的安全。有多种因素可能导致安全配置错误，包括不正确/不完整的默认配置、可公开访问的云存储、跨源资源共享 (CORS)以及与敏感数据一起显示的错误消息。入侵者可以利用这些错误配置来执行详细的侦察并获得对系统的未经授权的访问。 
安全错误配置通常由漏洞扫描器或审核工具检测到，因此可以在初始级别进行限制。API文档、端点列表、错误日志等不得公开访问，以确保安全，防止安全配置错误。通常，公司会部署 Web 应用程序防火墙等安全控制措施，但这些控制措施不会配置为阻止不需要的请求和攻击。
可能的影响
安全配置错误可能会让入侵者完全了解API组件。首先，它允许入侵者绕过安全机制。堆栈跟踪或其他详细错误可以让恶意行为者访问机密数据和基本系统详细信息，进一步帮助入侵者分析系统并获得进入权限。  
攻击场景示例
现在有一个API端点/apirule7/ping_v(GET)，该端点将共享有关服务器运行状况和状态的详细信息。如果调用不成功，服务器会发送完整的堆栈跟踪作为响应，其中包含函数名称、控制器和路由信息、文件路径等。攻击者可以使用这些信息来分析和准备对环境的特定攻击。

缓解措施
限制授权用户对管理界面的访问，并禁用其他用户的访问权限。 
禁用面向公众的设备（路由器、Web 应用程序防火墙等）的默认用户名和密码。
禁用目录列表并为每个文件和文件夹设置适当的权限。 
删除不必要的代码片段、错误日志等，并在代码处于生产状态时关闭调试。

API8:2019 注入

这是怎么发生的
注入攻击可能是最古老的基于 API/Web 的攻击之一，并且黑客仍在现实世界的应用程序上进行攻击。当用户输入未经过滤并直接由API处理时，会出现注入缺陷；从而使攻击者能够在未经授权的情况下执行非预期的API操作。注入可能来自结构查询语言 (SQL) 、操作系统 ( OS ) 命令、可扩展标记语言 (XML) 等 。如今，框架提供了通过自动清理数据来防止这种攻击的功能；然而，在核心PHP等自定义框架中构建的应用程序仍然容易受到此类攻击。 
可能的影响
注入缺陷可能会导致信息泄露、数据丢失、DoS和帐户完全被接管。成功的注入攻击还可能导致入侵者访问敏感数据，甚至创建新功能并执行远程代码执行。
攻击场景示例
现在有一个登录API端点/apirule8/user/login_v，该端点不会过滤用户输入。恶意攻击者需要目标的用户名和密码，他们可以使用有效负载' OR 1=1--' 并获取任何帐户的授权密钥。

缓解措施
确保使用众所周知的库进行客户端输入验证。
如果不使用框架，则必须首先验证所有客户端提供的数据，然后进行过滤和清理。 
向 Web 应用程序防火墙(WAF) 添加必要的安全规则。大多数时候，注入缺陷可以在网络级别得到缓解。
利用 Laravel、Code Ignitor 等框架中的内置过滤器来验证和过滤数据。

API9:2019 资产处理不当

这是怎么发生的
不适当的资产管理是指我们的系统中有两个版本的API可用的情况；我们将它们命名为API v1 和 APIv2。一切都完全切换到APIv2，但之前的版本APIv1还没有被删除。考虑到这一点，人们可能很容易猜测旧版本的 API（即 APIv1）没有更新或最新的安全功能。APIv1 的许多其他过时功能使得找到易受攻击的场景成为可能，这些场景可能会通过 API 版本之间的共享数据库导致数据泄漏和服务器接管。
它本质上是关于没有正确跟踪API端点。潜在的原因可能是 API 文档不完整或不符合软件开发生命周期。对于组织来说，正确维护、最新的API库存和适当的文档比基于硬件的安全控制更重要。
可能的影响 
较旧或未修补的API版本可能会允许入侵者未经授权访问机密数据，甚至完全控制系统。 
攻击场景示例
现在有2个API版本：v1和v2。该公司确保使用最新版本和 API 调用，但忘记从服务器中删除旧版本。旧的API调用会针对apirule9/v1/user/login登录的用户反回更多信息，例如余额、地址等。

缓解措施 
必须在网络级别阻止对先前开发的敏感和已弃用的API调用的访问。
为研发、质量保证、生产等开发的 API 必须隔离并托管在单独的服务器上。
确保所有API方面的文档，包括身份验证、重定向、错误、CORS 策略和速率限制。 
采用开放标准自动生成文档。

API10:2019 日志记录和监控不足

这是怎么发生的
日志记录和监控不足反映了攻击者在您的服务器上进行恶意活动的情况；然而，当你试图追踪黑客时，由于缺乏日志记录和监控机制，没有足够的证据。一些组织只关注基础设施日志记录，例如网络事件或服务器日志记录，但缺乏API日志记录和监控。访问者的 IP 地址、访问的端点、输入数据等信息以及时间戳可以识别威胁攻击模式。如果日志机制没有到位，那么识别攻击者及其详细信息将具有挑战性。 如今，最新的 Web 框架可以自动记录不同级别的请求，例如错误、调试、信息等。这些错误可以记录在数据库或文件中，甚至可以传递到SIEM 解决方案进行详细分析。
可能的影响 
无法识别攻击者或攻击背后的黑客。 
攻击场景示例
现在有一个API端点/apirule10/logging(GET)，用于记录用户的元数据（IP 地址、浏览器版本等）并将其保存在数据库中。

缓解措施 
确保使用安全信息和事件管理 ( SIEM ) 系统进行日志管理。 
使用SIEM导入的格式和足够的详细信息来跟踪所有被拒绝的访问、失败的身份验证尝试和输入验证错误，以识别入侵者。
将日志作为敏感数据处理，并确保其静态和传输时的完整性。此外，还实施自定义警报来检测可疑活动。