如何正确保护机密？

Question

我在前端和后端都使用HERE API。如果我尝试将我的app_id和app_code放入前端代码中，那么看到我的网站的任何人都可以使用它。

我可以尝试创建一个域白名单并将我的域放入其中。但是，即使我将HTTP标头“ Referer”设置为我的域，也可以从任何IP访问API。

那我该怎么办？

Answer 1

WHO和访问API服务器之间的区别

在深入探讨您的问题之前，我想先消除对 WHO 和什么正在访问API服务器的误解。

为了更好地了解 WHO 和 What 在访问API服务器之间的区别，让我们使用以下图片：

因此，将移动应用替换为网络应用，并继续按照我对此类图片的类比。

预期的通信渠道表示合法用户在没有任何恶意意图的情况下按预期使用的Web应用程序，通过浏览器与API服务器进行通信，而不使用Postman或使用任何其他工具来执行中间操作（MitM）攻击。

实际频道可能代表几种不同的情况，例如具有恶意意图的合法用户可能正在使用Curl或Postman等工具来执行请求，黑客使用MitM攻击工具（例如MitmProxy）来了解通信方式为了能够重播请求甚至自动对API服务器进行攻击，Web应用程序和API服务器之间的连接已完成。可能还有许多其他情况，但是我们在这里不逐一列举。

我希望到现在为止您可能已经知道为什么 WHO 和 What 不同的地方，但是如果不一样的话，一会儿就会明白。

WHO 是Web应用程序的用户，我们可以通过多种方式（例如使用OpenID Connect或OAUTH2流）进行身份验证，授权和标识。

  

OAUTH

     

通常，OAuth代表资源所有者向客户端提供对服务器资源的“安全委派访问”。它为资源所有者指定了一个在不共享凭据的情况下授权第三方访问其服务器资源的过程。 OAuth专为与超文本传输​​协议（HTTP）配合使用而设计，实质上允许在资源所有者的批准下，授权服务器将访问令牌发布给第三方客户端。然后，第三方使用访问令牌访问资源服务器托管的受保护资源。

     

OpenID Connect

     

OpenID Connect 1.0是OAuth 2.0协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终​​用户的基本配置文件信息。

尽管用户身份验证可能会让API服务器知道 WHO 正在使用API​​，但不能保证请求源自您期望的 What ，而浏览器就是您的网络应用程序应使用真实用户运行。

现在，我们需要一种方法来识别正在调用的API服务器，这使得事情变得比大多数开发人员想象的要棘手。 内容是向API服务器发出请求的内容。它是Web应用程序的真正实例，还是使用诸如Postman之类的工具通过API服务器手动访问的机器人，自动脚本或攻击者？

让您感到惊讶的是，您可能最终发现它可能是手动处理请求的合法用户之一，或者是试图游戏化并利用Web应用程序提供的服务的自动脚本。

好吧，为了确定内容，开发人员倾向于求助于通常在Web应用程序标头中发送的API密钥。一些开发人员会加倍努力，并在运行时在混淆的javascript内的web应用程序中计算密钥，因此它成为运行时的秘密，可以通过除臭工具以及检查Web应用程序与API之间的流量进行逆向工程F12或MitM工具的服务器。

以上文章摘录自我写的一篇文章，题为《 为什么您的移动应用程序需要API密钥？”。在移动应用程序的上下文中，总体思想在Web应用程序的上下文中仍然有效。您希望可以阅读完整的here文章，这是有关API密钥的一系列文章中的第一篇。

您的问题

  

我可以尝试创建一个域白名单并将我的域放入其中。但是，即使我将HTTP标头“ Referer”设置为我的域，也可以从任何IP访问API。

因此，这似乎与使用HERE管理界面有关，在这里我无能为力...

  

那我该怎么办？

     

我在前端和后端都使用HERE API。

前端必须始终将对第三方API的访问权限委派到受前端所有者控制的后端中，这样，您就不会在前端中公开访问凭据来访问第三方服务。

所以区别在于，现在您可以直接控制如何防止滥用HERE API访问权限，因为您不再向公众公开此处的api_id和api_code以及访问权限必须在您的后端进行处理，在这里，您的访问秘密不会被公开撬开，并且您可以在此处轻松地监控和限制使用，然后再使用HERE API支付帐单。

  

如果我尝试将我的app_id和app_code放入前端代码中，则看到我的网站的任何人都可以使用。

总而言之，您应该在前端公开的唯一凭证是用于访问后端的凭证，通常的api-key和Authorization令牌，或者您想命名的任何凭证，而不是{ {1}}或api_id来访问HERE API。这种方法只给您一个保护的访问权限，而不是多个。

捍卫API服务器

正如我已经说过的，但是要增强Web应用程序，应该只与您控制下的API服务器通信，对第三方API服务的任何访问都必须由您控制的同一API服务器来完成。通过这种方式，您可以将攻击面限制在一个地方，在那里您将采用防御所需要保护的多层防御系统。

对于服务于Web应用程序的API，您可以采用几层密集的结构，从reCaptcha V3开始，然后是Web Application Firewall（WAF），最后如果可以负担得起User Behavior Analytics （UBA）解决方案。

Google reCAPTCHA V3：

  

reCAPTCHA是一项免费服务，可保护您的网站免受垃圾邮件和滥用的侵害。 reCAPTCHA使用高级风险分析引擎和适应性挑战，以防止自动化软件参与您网站上的滥用行为。这样做是为了让您的有效用户轻松通过。

     

...可帮助您检测网站上的滥用流量，而不会引起用户的摩擦。它会根据与您网站的互动情况返回得分，并为您提供更大的灵活性以采取适当的措施。

WAF - Web Application Firewall：

  

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

UBA - User Behavior Analytics：

  

Gartner定义的用户行为分析（UBA）是一个有关检测内部威胁，针对性攻击和财务欺诈的网络安全流程。 UBA解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常，即表明潜在威胁的异常。 UBA不会跟踪设备或安全事件，而是跟踪系统的用户。像Apache Hadoop这样的大数据平台通过允许它们分析PB级的数据来检测内部威胁和高级持久威胁，正在增强UBA功能。

所有这些解决方案都基于否定性识别模型，换句话说，他们通过识别出什么是坏的而不是什么好，来尽最大的努力将坏与坏区分开，因此尽管有先进的解决方案，它们还是容易出现误报其中一些人使用的技术，例如机器学习和人工智能。

因此，您可能经常会发现自己不必放松放松如何阻止对API服务器的访问以不影响良好用户。这也意味着这些解决方案需要不断监控，以验证误报不会阻止您的合法用户，同时又能正确阻止未经授权的用户。

摘要

任何在客户端运行的，需要一些秘密才能访问API的内容都可能以不同的方式被滥用，并且您必须将对所有第三方API的访问权限委派给您所控制的后端，以便减少攻击面，并同时保护他们的秘密，以免被公众窥探。

最后，必须根据要保护的内容的价值以及此类数据的法律要求（例如欧洲的GDPR法规）来选择用于保护API服务器的解决方案。

因此，使用API​​钥匙听起来就像锁上了房屋的门，将钥匙留在了垫子下面，但不使用它们就像是在门关闭的情况下将车停在停车场，而钥匙却在点火开关中。

走额外的里程

OWASP Web Top 10 Risks

  

OWASP Top 10是一个功能强大的Web应用程序安全意识文档。它代表了对Web应用程序最严重的安全风险的广泛共识。该项目的成员包括来自世界各地的各种安全专家，他们分享了他们的专业知识，以编制此列表。