我正在构建一个B2B服务,其API可以由第三方基于订阅来访问。基本上,我们提供了一个可定制的小部件,客户可以将其嵌入到他们的网站上,以使其对客户可用(例如,打开模式的按钮)。虽然很清楚如何在传统的Web应用程序中实现此功能,但我不确定如何在单页应用程序中保证这一点。如果没有OAuth中使用的重定向URI,是否完全可以进行这项工作?也就是说,模式触发了对我们API的AJAX请求,我们希望确保它来自授权来源 重定向的脚本。我们当然可以简单地检查Origin报头,但是有什么方法可以防止某人在其后端手动构造带有此类报头的请求,即使他们无法在浏览器中完成请求。
答案 0 :(得分:1)
虽然很清楚如何在传统的Web应用程序中实现此功能,但我不确定如何在单页应用程序中保证这一点。
从Web应用程序中,您只需要查看html源代码就能找到API密钥或其他机密。即使您使用传统的Web服务器,也可以获取Cookie来自动对其进行攻击。
尽管有关移动API安全技术的文章中的this series是在移动设备的上下文中,但是所使用的某些技术在其他类型的API中也有效,例如Web / SPAs应用程序的API,您可以看到如何将API密钥,OUATH令牌和HMAC机密用于保护API并被绕过。
您可以尝试使用Javascript Obfuscator来查找API密钥,但是要记住,这只会延迟攻击者的成功。
残酷的事实是……你不能!
但是您可以尝试使用Google提供的reCAPTCHA V3在后台运行,因此不需要用户交互。这里的缺点是您所有的B2B客户都需要在其网站的所有页面上实施它,因此可能不是您的用例的方法...
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这样的大数据平台通过允许它们分析PB级的数据来检测内部威胁和高级持久威胁,正在增强UBA功能。
最终,您只能尽最大努力保护B2B后端,该后端必须与其为企业持有的价值成正比。
由于它的设计工作方式,Web尚不存在100%的解决方案!
答案 1 :(得分:0)
请求来自哪里或谁在发出请求有关系吗?如果后者需要确认,那么您可以在请求中要求授权令牌。通常,您将以一种方式来执行此操作,即可以解码令牌并确认与授权方的匹配。
答案 2 :(得分:0)
因此,基本上,您想要系统安全性,可以使用Oauth2.0授予类型=客户端凭据。这将确保仅授权客户端使用您的api。
工作非常简单,客户端使用client_id和client_pass命中Oauth2.0服务器,并且Oauth服务器返回您一个令牌,相同的令牌客户端将传递给服务器,并且当您通过以下方式访问Oauth服务器来验证该令牌时: server_id,server_pass + token到Oauth服务器,它返回带有客户端ID的验证,并基于此可以公开您的服务。 您无需担心重定向,因为客户端凭据不需要这样做。
答案 3 :(得分:0)
我建议在 PKCE 中使用 OAuth2 身份验证代码。它旨在允许从 SPA(和本机应用程序)安全地调用 API。基本上,它依赖于这样一个事实,即调用您的 API 的 SPA 具有一些众所周知的 URL,这就是不允许在您的 SPA 之外使用它的原因。