OWASP API TOP 10介绍

黎鲈

Open Web Application Security Project (OWASP) 是 OWASP Top 10 背后的一个非营利性协作在线社区。他们制作文章、方法论、文档、工具和技术来提高应用程序安全性。

自 2003 年以来，OWASP Top 10 项目一直是 Web 应用程序漏洞流行信息及其缓解方法的权威列表。然而，API 的兴起已经——而且正在——从根本上改变安全格局，以至于需要一种新的方法。因此，在 2019 年，OWASP 开始努力创建专门针对 API 安全性的 Top 10 版本。第一个 OWASP API 安全 10 强名单于 2019 年 12 月 31 日发布。

Web 应用程序安全与 API 安全
虽然 REST API 与 Web 应用程序有许多相似之处，但也存在根本差异。

在传统的 Web 应用程序中，数据处理是在服务器端完成的，然后将生成的网页发送到客户端浏览器进行渲染。因此，通过在应用服务器前设置 Web 应用防火墙 (WAF) 来保护业务网络架构的入口点相对较少且直接。

现代基于 API 的应用程序非常不同。越来越多的 UI 使用 API 来发送和接收来自后端服务器的数据，以提供应用程序的功能。现在是客户端进行渲染并维护状态。

再加上将单个应用程序组件变成 API 的微服务架构，你会看到一个截然不同的世界，攻击面显着扩大。现在，网络架构的入口点是大量调用后端或网络中东西方向的 API。

由于网络架构中通常分布着如此多的入口点，在服务器前放置防火墙已不足以确保所有入口点都受到保护。此外，传统的基于 WAF 的解决方案无法区分黑客 API 调用和合法 API 流量。

本质上，API 会暴露应用程序逻辑和敏感数据，例如个人身份信息 (PII)，因此越来越成为攻击者的目标。API 提供了合约，但它们本身并没有包含足够的措施来确保合约得到遵守，这给 API 连接的后端服务带来了严重的安全风险。

所有这一切意味着 API 安全需要自己的安全品牌，专注于策略和解决方案，以了解和减轻 API 的独特漏洞和安全风险。

API1:2019 — 损坏的对象级授权
攻击者将 API 调用中自己资源的 ID 替换为属于另一个用户的资源 ID。缺乏适当的授权检查允许攻击者访问指定的资源。这种攻击也称为 IDOR（不安全的直接对象引用）。

IDOR 攻击允许攻击者访问与他们预期不同的资源。

用例
API 调用参数使用通过 API 访问的资源的 ID /api/shop1/financial_info。
攻击者将其资源的 ID 替换为他们猜测的不同 ID 。 /api/shop2/financial_info
API 不检查权限并允许调用通过。
如果可以枚举 ID，则问题会更加严重/api/123/financial_info。
如何预防
使用用户策略和层次结构实施授权检查。
不要依赖客户端发送的 ID。请改用存储在会话对象中的 ID。
检查每个客户端请求访问数据库的授权。
使用无法猜测的随机 ID (UUID)。

API2:2019 — 损坏的身份验证
实施不当的 API 身份验证允许攻击者假设其他用户的身份。

在 API 前破坏身份验证可以为攻击者提供访问它的密钥。

用例
被视为“内部”的未受保护的 API
不遵循行业最佳实践的弱身份验证
未轮换的弱 API 密钥
弱密码、纯文本密码、加密密码、散列不佳的密码、共享密码或默认密码
身份验证容易受到蛮力攻击和凭证填充
URL 中包含的凭据和密钥
缺乏访问令牌验证（包括 JWT 验证）
未签名或弱签名的非过期 JWT
如何预防
检查对所有 API 进行身份验证的所有可能方法。
用于密码重置和一次性链接的 API 也允许用户进行身份验证，并且应该受到同样严格的保护。
使用标准身份验证、令牌生成、密码存储和多因素身份验证 (MFA)。
使用短期访问令牌。
验证您的应用程序（以便您知道谁在与您交谈）。
对身份验证使用更严格的速率限制，并实施锁定策略和弱密码检查。

API3:2019 — 过度的数据暴露
API 可能会公开比客户端合法需要的数据多得多的数据，依赖于客户端进行过滤。如果攻击者直接访问 API，他们就拥有了一切。

如果您绕过 UI，则 API 从后端返回的原始数据都可供获取。

用例
API 返回存储在后端数据库中的完整数据对象。
客户端应用程序过滤响应，只显示用户真正需要查看的数据。
攻击者直接调用 API 并获取 UI 会过滤掉的敏感数据。
如何预防
永远不要依赖客户端来过滤数据！
查看所有 API 响应并调整它们以匹配 API 使用者的真正需要。
仔细定义所有 API 响应的模式。
不要忘记错误响应，还要定义正确的模式。
识别所有敏感数据或个人身份信息 (PII)，并证明其使用的合理性。
强制执行响应检查以防止数据意外泄漏或异常。

API4:2019 — 缺乏资源和速率限制
API 不受过多调用或负载大小的保护。攻击者可以将其用于拒绝服务 (DoS) 和暴力攻击等身份验证缺陷。

使用过多请求或过大有效载荷轰炸 API 可能会导致 API 崩溃，并可能导致意外结果。

用例
攻击者通过发送超出 API 处理能力的请求使 API 过载。
攻击者以超过 API 处理速度的速率发送请求，从而阻塞了它。
请求的大小或其中的某些字段超出了 API 的处理能力。
“压缩炸弹”，归档文件被设计成解压它们会占用过多的资源并使 API 过载。
如何预防
定义适当的速率限制。
限制有效载荷大小。
调整速率限制以匹配 API 方法、客户端或地址需要或应该允许获取的内容。
添加对压缩率的检查。
定义容器资源的限制。

API5:2019 — 破坏功能级授权
API 依赖于客户端来使用用户级别或管理员级别的 API。攻击者找出“隐藏的”管理 API 方法并直接调用它们。

管理方法的任何授权都不允许任何人使用它们。

用例
一些管理功能作为 API 公开。
如果非特权用户知道如何使用，他们可以在未经授权的情况下访问这些功能。
可能是知道 URL 的问题，或者使用不同的动词或参数：
/api/users/v1/user/myinfo
/api/admins/v1/users/all
如何预防
不要依赖客户端来强制执行管理员访问。
默认拒绝所有访问。
只允许对属于相应组或角色的用户进行操作。
正确设计和测试授权。

API6:2019——批量赋值
API 获取客户端提供的数据并将其存储，而无需对列入白名单的属性进行适当的过滤。攻击者可以尝试猜测对象属性或在他们的请求中提供额外的对象属性、阅读文档或查看 API 端点以获取线索，以便在后端存储的数据对象上找到修改他们不应该修改的属性的开口。

API 在没有适当过滤的情况下处理数据结构，并盲目地将有效负载存储为对象。

用例
API 可以在没有适当过滤的情况下处理数据结构。
接收到的有效载荷被盲目地转换为对象并存储。
节点：
var user = new User(req.body);
user.save();
导轨：
@user = User.new(params[:user])
攻击者可以通过查看GET请求数据来猜测字段。
如何预防
不要自动绑定传入数据和内部对象。
明确定义您期望的所有参数和有效负载。
对于可以通过 API 检索但不应修改的所有属性，在对象架构中使用readOnly设置true为 的属性。
精确定义您将在设计时在请求中接受的架构、类型和模式，并在运行时强制执行它们。

API7:2019 — 安全配置错误
API 服务器的糟糕配置允许攻击者利用它们。

各种配置错误都会给 API 服务器的保护留下漏洞。

用例
未打补丁的系统
未受保护的文件和目录
未硬化的图像
TLS 丢失、过时或配置错误
暴露的存储或服务器管理面板
缺少 CORS 策略或安全标头
带有堆栈跟踪的错误消息
启用了不必要的功能
如何预防
建立可重复的强化和修补过程。
自动定位配置缺陷。
禁用不必要的功能。
限制管理访问。
定义并强制执行所有输出，包括错误。

PI8:2019 — 注入
攻击者构建的 API 调用包括 SQL、NoSQL、LDAP、OS 或 API 或其背后的后端盲目执行的其他命令。

对输入数据的验证不充分可能允许攻击者注入由您的 API 或其后端执行的恶意代码。

用例
攻击者发送恶意输入以转发给内部解释器：
SQL
无SQL
LDAP
操作系统命令
XML 解析器
对象关系映射 (ORM)
如何预防
永远不要相信您的 API 使用者，即使他们是内部使用者。
严格定义所有输入数据，例如模式、类型和字符串模式，并在运行时强制执行它们。
验证、过滤和清理所有传入数据。
定义、限制和强制执行 API 输出以防止数据泄漏。

API9:2019 — 资产管理不当
攻击者发现 API 的非生产版本（例如，暂存、测试、测试版或更早版本）的保护不如生产 API，并使用这些版本发起攻击。

通过较少受保护的 API 非生产版本进行身份验证可能会打开后门以访问生产 API。

用例
DevOps、云、容器和 Kubernetes 使多个部署变得容易（例如，开发、测试、分支、暂存、旧版本）。
希望保持向后兼容性迫使旧 API 继续运行。
旧版本或非生产版本没有得到妥善维护，但这些端点仍然可以访问生产数据。
一旦通过一个端点进行身份验证，攻击者就可以切换到另一个生产端点。
如何预防
保持所有 API 主机的最新清单。
限制对不应公开的任何内容的访问。
限制对生产数据的访问，并将对生产和非生产数据的访问分开。
实施额外的外部控制，例如 API 防火墙。
正确停用旧版本的 API 或向后移植安全修复程序。
实施严格的身份验证、重定向、CORS 等。

API10:2019 — 日志记录和监控不足
缺乏适当的日志记录、监控和警报会使攻击和攻击者被忽视。

适当的日志记录、监控和警报可以让您了解 API 的运行情况。

用例
日志不受完整性保护。
日志未集成到安全信息和事件管理 (SIEM) 系统中。
日志和警报的设计很差。
公司依赖手动而不是自动化系统。
如何预防
记录失败的尝试、拒绝访问、输入验证失败或安全策略检查中的任何失败。
确保日志已格式化，以便其他工具也可以使用它们。
保护诸如高度敏感信息之类的日志。
包括足够的细节来识别攻击者。
避免在日志中包含敏感数据——如果您需要这些信息用于调试目的，请对其进行部分编辑。
与 SIEM 和其他仪表板、监控和警报工具集成。

其中一些是翻译过来的，不过整体可以理解

H.U.C清风

谢谢分享，已回复