欢迎大家围观小阑精心整理的API安全最新资讯，在这里你能看到最专业、最前沿的API安全技术和产业资讯，我们提供关于全球API安全资讯与信息安全深度观察。
本周，我们带来的分享如下：
-
DevOps团队如何防御API攻击
-
对API开发人员的同理心
-
提高API安全性的八项安全措施
-
为什么您的API网关不足以保证API安全
-
2022年移动应用安全状况
DevOps 团队如何防御 API 攻击
本周，我们有一篇来自 DevOps.com 的优秀文章，讨论了 DevOps 团队如何参与到 API 防御攻击中。作者提出了一个新颖的观点：
“ DevOps 团队已经采用的用于防御勒索软件的安全实践也可以重新用于提供 API 安全性——只需进行一些调整。”
防御 API 的第一个建议是防止横向移动：虽然无法阻止 API 威胁到达您的外围，但可以通过防止攻击者转向其他内部系统来限制其传播和影响。这种方法的关键是早期检测初始恶意活动，因为早期检测可以预防。
作者最突出的观察是 DevOps 团队专注于数据安全——最终，攻击者的目标是获取有价值的公司数据。与勒索软件的情况非常相似，攻击者以数据为目标并让组织因访问该数据而勒索赎金。对于 API，威胁更大：数据可能被泄露并出售以获取利润或损害组织的声誉。应采用数据保护实践，包括对数据的严格和细化的访问控制，以及内部和外部 API 之间的访问分段。
作者强调了基于签名的检测方法的无效性，因为这些方法往往不受零日攻击或未知攻击的影响。通过使用行为安全模型，防御团队可以对标准 API 行为和使用模式进行建模，以便能够检测到这种行为的异常，这可能表明存在妥协。API 往往以标准模式访问，因此可以检测人类对手等异常行为。
作者建议不要过度依赖基于边界的防御——正如本时事通讯和其他地方所记录的那样，众所周知，防火墙和 WAF 在防止集中的 API 攻击方面效率低下。
最后，作者强调了超越表面的重要性：使用分层防御机制并了解攻击者可能如何攻击您的 API 资产，例如，选择将您的 API 置于非标准端口或协议后面。
这里有一些关于如何使用现有保护机制来保护 API 的非常有见地的建议。
对 API 开发人员的同理心
在 DevOps.com 上，作者讨论为 API 开发人员培养同理心以实现更好的 API 安全结果的重要性。
首先，让我们首先了解为什么存在不安全代码：软件开发是一项复杂的工作，充满了许多引入弱点和漏洞的机会。
其中一些原因包括：
• 开发人员过于乐观——他们是创造性的问题解决者，并不总是期待意外。
• 过度自信——开发人员通常认为他们对复杂软件框架的理解比实际情况更好，从而导致无意中不安全的软件。
• 坏事只会发生在其他开发人员身上——把这看作是开发人员的一种幸灾乐祸。
• 走捷径——我们都做过，缺少空指针检查，或者未处理的错误情况。这些可能会产生重大的安全影响。
• 技术债务或遗留代码——这可能是导致软件不安全的第一大原因。
• 这很困难——开发人员在许多方面都承受着压力，而安全性只是他们的考虑因素之一。
API 安全提供了一些独特的机会来打破开发人员和安全团队之间的这些障碍
• 首先，积极的安全模型允许对 API 的预期行为进行更精确的定义——传统的安全工具（WAF、防火墙、SAST）试图防止或检测已知的不良行为，这些不良行为 可以导致高假阳性和高假阴性。这会导致安全团队和开发人员感到沮丧，因为他们觉得自己肩负着不必要的补救工作。
• 其次，使用基于 OpenAPI 定义的设计优先方法允许将安全策略作为代码注入 CI/CD 流程中。开发人员不再需要尝试和猜测适用的策略，而是可以用代码简洁地表达这些。
这一切都归结为：“帮助开发人员通过建立同理心并与他们合作而不是反对他们来帮助自己。”
提高 API 安全性的八项安全措施
应用程序接口 (API) 形成应用程序之间的桥梁，使程序能够跨不同的代码库和硬件相互通信。但在坏人手中，API 可能会造成潜在的巨大损害。
企业应用程序形成了越来越大的攻击面，但真正漏洞所在的往往是 API。虽然可以通过标准防火墙和SIEM 工具检测和阻止许多攻击，但通过 API 进行的攻击更加隐蔽，因为它们通常利用 API 已经允许的访问权限。这些漏洞远远超出了企业领域，甚至可能影响您的个人车辆。不安全的 API 无处不在，甚至被用来破解 Teslas。
关于提高 API 安全性的安全措施的文章中。
作者确定了以下八个重点提高 API 安全性的领域：
• 为未来用户构建，而不是当前用户：设计 API 一开始就考虑到安全性——常见的陷阱包括在开发中没有实施适当的访问控制，只是发现 API 在没有必要控制的情况下发布到生产环境中。
• 限制用户：通过限制有权访问 API 的用户数量（例如，通过使用具有有限范围或有效期的令牌）来减少攻击面。
• 限制数据：避免收集和聚合比 API 函数所需的更多数据，以最大程度地减少意外泄漏比您打算公开的更多数据的危险。
• 加密数据：很明显，但要确保所有数据都经过加密，无论是静态数据还是传输数据（在所有情况下都使用 TLS）。
• 制定分页限制：通过在 API 级别使用精心设计的分页控件，可以防止过度数据泄露。
• 在 SQL 查询中使用准备好的语句：尽管已有二十多年的历史，但 SQL 注入攻击仍然很普遍，并且可以通过在 SQL 查询中使用准备好的语句完全避免。
• 加强最终用户和应用程序身份验证：使用最佳实践进行身份验证，包括密码和令牌轮换和撤销，以及有限的范围和角色。
• 施加速率限制：另一个明显的问题是在敏感 API 端点上明智地使用速率限制，例如密码重置或注册方法。
API 安全没有灵丹妙药，但良好的分层防御方法可以消除许多基本攻击向量。
为什么您的 API 网关不足以保证 API 安全
讨论 API 安全性时常有的热门话题是 API 网关的作用，本周 HelpNetSecurity 提供了他们对这个话题的看法。作者的观点是 API 网关服务于特定目的：将 API 流量从外部接口路由到相应的内部服务。因此，这些 API 网关的设计并未将 API 安全性放在需求列表的顶部。
一个很好的例子是令牌泄漏或盗窃：一旦攻击者获取 API 令牌，API 网关就无法阻止使用该令牌的攻击，因为这些攻击与正常请求无法区分。此外，API 网关可能会提供一种错误的安全感：并非所有 API 都通过网关进行路由，这意味着网关不可见的其他攻击面确实存在。许多 API 攻击非常复杂，依赖于 API 后端中的编码或逻辑错误，网关根本无法抵御这些更复杂的攻击。
作者推荐使用更现代的WAAP（Web Application and API Protection）技术来提供API保护；然而，这些有其缺点，建立在消极的安全模型之上。本周即将举行的专题网络研讨会讨论了积极的安全模型如何克服这些限制。
2022年移动应用安全状况
一份关于 2022 年移动应用程序安全状况的报告。不出所料，该报告强调了糟糕的 API 安全性对移动应用程序的整体安全性造成的有害影响。攻击者经常使用移动 API 作为主要攻击媒介，而不是移动应用程序本身。
从 API 安全的角度来看，有以下发现：
• 75% 的组织对导致移动应用程序无法运行的 API 进行运行时攻击证明代价高昂。
• 超过 60% 的组织缺乏对针对移动应用程序和 API 的运行时威胁的可见性。
• 减少由硬编码 API 密钥导致的威胁是当务之急——报告研究的移动应用程序中有超过一半使用嵌入在应用程序中的硬编码密钥。
• 第三方 API 为威胁参与者创建了路径——通常移动应用程序依赖于 30 多个第三方 API！
该报告很好地说明了 API 安全性如何支撑应用程序堆栈更高层的安全性——当攻击者可以直接进入 API 层时，他们根本不会费心攻击应用程序层。
关注“星阑科技”公众号
后台回复“移动应用安全报告”可获取报告全文
感谢 APIsecurity.io 提供相关内容
关于星阑
星阑科技基于AI深度感知和强大的自适应机器学习技术，帮助用户迅速发现并解决面临的安全风险和外部威胁，并凭借持续的创新理念和以实战攻防为核心的安全能力，发展成为国内人工智能、信息安全领域的双料科技公司。为解决API安全问题，公司从攻防能力、大数据分析能力及云原生技术体系出发，提供全景化API识别、API高级威胁检测、复杂行为分析等能力，构建API Runtime Protection体系。
星阑科技产品——萤火 (API Intelligence) 拥有不同应用场景的解决方案，适配服务器、容器集群、微服务架构以及云平台等多种架构。通过API资产梳理、漏洞管理、威胁监测、运营与响应能力，解决企业API漏洞入侵、数据泄露两大核心风险。
往期 · 推荐
原文始发于微信公众号（星阑科技）：API NEWS | 2022年移动应用安全状况（附报告下载）
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论