【问题标题】:How to secure a web API from being accessed from unauthorized SPAs如何保护 Web API 不被未经授权的 SPA 访问
【发布时间】:2020-12-30 21:34:31
【问题描述】:

我正在构建一个 B2B 服务,第三方可以通过订阅访问其 API。基本上,我们提供了一个可定制的小部件,我们的客户可以将其嵌入到他们的网站上,以便他们的客户可以使用它(例如,一个打开模式的按钮)。虽然很清楚如何在传统的 Web 应用程序中实现这一点,但我不确定如何在单页应用程序中保证这一点。是否有可能在没有 OAuth 中使用的重定向 URI 的情况下完成这项工作?也就是说,模态会触发对我们 API 的 AJAX 请求,我们希望确保它来自授权来源的脚本没有重定向。我们当然可以简单地检查 Origin 标头,但是有什么可以防止有人在他们的后端手动构建带有这样的标头的请求,即使他们不能在浏览器中这样做。

【问题讨论】:

    标签: javascript web-services security oauth-2.0


    【解决方案1】:

    问题

    虽然很清楚如何在传统的网络应用中实现这一点,但我不确定如何在单页应用中保证这一点。

    从网络应用程序中,您只需查看 html 源代码即可找到 API 密钥或其他机密。即使您使用传统的 Web 服务器,也可以获取 cookie 来自动对其进行攻击。

    虽然 this series 有关移动 API 安全技术的文章是在移动设备的上下文中使用的,但所使用的一些技术在其他类型的 API 中也有效,例如用于 Web/SPA 应用程序的 API,您可以查看 API 如何密钥、OUATH 令牌和 HMAC 机密可用于保护 API 并被绕过。

    可能的解决方案

    您可以尝试使用Javascript Obfuscator 使查找 API 密钥变得困难,但请记住,这只会延迟攻击者的成功。

    那么,我该如何阻止攻击者呢?

    好吧,残酷的事实是……你不能!!!

    但您可以尝试使用来自 Google 的 reCAPTCHA V3,它在后台运行,因此不需要用户交互。这里的缺点是您的所有 B2B 客户都需要在其网站的所有页面上实施它,因此可能不适合您的用例...

    reCAPTCHA V3:

    reCAPTCHA 是一项免费服务,可保护您的网站免受垃圾邮件和滥用。 reCAPTCHA 使用高级风险分析引擎和自适应挑战来防止自动化软件参与您网站上的滥用活动。它在让您的有效用户轻松通过的同时做到这一点。

    如果您的 B2B 解决方案确实需要不惜一切代价保护它,那么您需要使用 Web 应用程序防火墙 (WAF) 和用户行为分析解决方案,也称为 UBA,它们使用人工智能和机器学习来防止滥用,但是一旦更多他们不能保证 100% 阻止并且两者都有误报。

    WAF:

    Web 应用程序防火墙(或 WAF)过滤、监控和阻止进出 Web 应用程序的 HTTP 流量。 WAF 与常规防火墙的区别在于,WAF 能够过滤特定 Web 应用程序的内容,而常规防火墙充当服务器之间的安全门。通过检查 HTTP 流量,它可以防止源自 Web 应用程序安全漏洞的攻击,例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全错误配置。

    UBA:

    Gartner 定义的用户行为分析 (UBA) 是一个关于检测内部威胁、针对性攻击和金融欺诈的网络安全流程。 UBA 解决方案着眼于人类行为模式,然后应用算法和统计分析从这些模式中检测出有意义的异常——表明潜在威胁的异常。 UBA 不是跟踪设备或安全事件,而是跟踪系统的用户。 Apache Hadoop 等大数据平台正在增加 UBA 功能,允许它们分析 PB 级的数据以检测内部威胁和高级持续性威胁。

    结论

    归根结底,您只能尽最大努力保护您的 B2B 后端,这必须与它为业务所持有的价值成正比。

    由于设计的工作方式,网络不存在 100% 的解决方案!!!

    【讨论】:

      【解决方案2】:

      请求来自何处或谁提出请求是否重要?如果后者需要确认,那么您可能需要一个授权令牌以及请求。通常,您可以通过解码令牌并与授权方确认匹配的方式执行此操作。

      【讨论】:

      • 对不起,我想我忘了提到这里的问题是单页应用程序。如果无法保密存储,我们如何向每个客户颁发用于获取授权令牌的客户端密码?
      • 是的,您需要安全地存储私钥。
      • 好的,但是如果我们的客户不能以这种方式存储它怎么办?
      • 由他们来保护他们的凭据。通过网络发送的任何内容都应假定为纯文本。我敢打赌,如果对安全性有足够的关注,那么可以找到一种方法来安全地加密而不泄露敏感信息。它一直在完成。
      【解决方案3】:

      所以基本上你想要系统安全,你可以使用 Oauth2.0 授权类型 = 客户端凭据。这将确保您的 api 仅由授权客户使用。

      它的工作非常简单,客户端使用 client_id 和 client_pass 访问 Oauth2.0 服务器,Oauth 服务器返回一个令牌,相同的令牌客户端将传递给服务器,当你通过访问 Oauth 服务器验证该令牌时server_id,server_pass+token 到 Oauth 服务器,它返回带有客户端 ID 的验证,并在此基础上您可以公开您的服务。 您无需担心重定向,因为客户端凭据不需要这样做。

      【讨论】:

      • 我知道 OAuth 授权类型。我关心的客户类型是SPA。它不能存储客户端密码。
      【解决方案4】:

      我建议将 OAuth2 Auth Code 与 PKCE 一起使用。它旨在允许从 SPA(和本机应用程序)安全地调用 API。基本上,它依赖于调用您的 API 的 SPA 具有一些众所周知的 URL,这就是不允许在您的 SPA 之外使用它的原因。

      【讨论】:

        猜你喜欢
        • 2019-06-05
        • 1970-01-01
        • 1970-01-01
        • 2018-05-20
        • 2019-02-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2017-02-08
        相关资源
        最近更新 更多