如何妥善保护机密? [英] How to protect secrets properly?
问题描述
我在前端和后端都使用HERE API.如果我尝试将我的app_id和app_code放入前端代码中，那么看到我的网站的任何人都可以使用它.
I am using HERE api in both frontend and backend. If I try to put my app_id and app_code into the frontend code, it will be available to anyone seeing my site.
我可以尝试创建一个域白名单，然后将我的域放入其中.但是，即使我将HTTP标头"Referer"设置为我的域，也可以从任何IP访问API.
I can try to create a domain whitelist and put my domain in this. But still, if I set the HTTP header "Referer" to my domain, I am able to access the API from any IP.
那我该怎么办?
推荐答案
WHO和访问API服务器的区别
在深入探讨您的问题之前，我想先消除对 WHO 和 What 正在访问API服务器的误解.
The Difference Between WHO and WHAT is Accessing the API Server
Before I dive into your problem I would like to first clear a misconception about WHO and WHAT is accessing an API server.
为了更好地理解 WHO 和 What 在访问API服务器之间的区别，让我们使用以下图片:
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
因此，将移动应用替换为网络应用，并继续遵循我对这张图片的类比.
So replace the mobile app by web app, and keep following my analogy around this picture.
预期的通信渠道表示合法用户在没有任何恶意意图的情况下按预期使用的Web应用程序，通过浏览器与API服务器进行通信，而不使用Postman或使用任何其他工具来执行中间操作(MitM)攻击.
The Intended Communication Channel represents the web app being used as you expected, by a legit user without any malicious intentions, communicating with the API server from the browser, not using Postman or using any other tool to perform a man in the middle(MitM) attack.
实际频道可能代表几种不同的情况，例如具有恶意意图的合法用户可能正在使用Curl或Postman等工具来执行请求，黑客使用MitM攻击工具(例如MitmProxy)来了解通信方式为了能够重播请求甚至自动对API服务器进行攻击，Web应用程序和API服务器之间的连接已完成.可能还有许多其他情况，但是我们在这里不逐一列举.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using Curl or a tool like Postman to perform the requests, a hacker using a MitM attack tool, like MitmProxy, to understand how the communication between the web app and the API server is being done in order to be able to replay the requests or even automate attacks against the API server. Many other scenarios are possible, but we will not enumerate each one here.
我希望到现在为止您可能已经知道为什么 WHO 和 What 不相同的原因，但是如果不一样，那一会儿就会弄清楚.
I hope that by now you may already have a clue why the WHO and the WHAT are not the same, but if not it will become clear in a moment.
WHO 是Web应用程序的用户，我们可以通过多种方式(例如使用OpenID Connect或OAUTH2流)进行身份验证，授权和标识.
The WHO is the user of the web app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
通常，OAuth向客户端提供安全委派访问"权限，以确保安全性.代表资源所有者来服务器资源.它为资源所有者指定了一种在不共享其凭据的情况下授权第三方访问其服务器资源的过程. OAuth专为与超文本传输协议(HTTP)配合使用而设计，本质上允许在资源所有者的批准下，授权服务器将访问令牌发布给第三方客户端.然后，第三方使用访问令牌访问资源服务器托管的受保护资源.
Generally, OAuth provides to clients a "secure delegated access" to server resources on behalf of a resource owner. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources hosted by the resource server.
OpenID Connect 1.0是OAuth 2.0协议之上的一个简单身份层.它允许客户端基于授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终用户的基本配置文件信息.
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
虽然用户身份验证可能会让API服务器知道 WHO 正在使用API，但不能保证请求源自您期望的 What ，而浏览器就是您的网络该应用程序应使用真实用户运行.
While user authentication may let the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the browser were your web app should be running from, with a real user.
现在，我们需要一种方法来识别正在调用什么的API服务器，这使得事情变得比大多数开发人员想象的要棘手. 内容是向API服务器发出请求的内容.它是Web应用程序的真正实例，还是使用诸如Postman之类的工具通过API服务器手动访问的机器人，自动脚本或攻击者?
Now we need a way to identify WHAT is calling the API server, and here things become more tricky than most developers may think. The WHAT is the thing making the request to the API server. Is it really a genuine instance of the web app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
令您惊讶的是，您可能最终发现它可能是手动处理请求的合法用户之一，或者是试图游戏化并利用Web应用程序提供的服务的自动脚本.
For your surprise, you may end up discovering that It can be one of the legit users manipulating manually the requests or an automated script that is trying to gamify and take advantage of the service provided by the web app.
好吧，为了确定内容，开发人员倾向于求助于通常在Web应用程序标头中发送的API密钥.一些开发人员会加倍努力，并在运行时在混淆了的javascript内的web应用程序中计算密钥，因此它成为运行时的秘密，可以通过除烟工具以及通过检查web应用程序与API之间的流量进行逆向工程F12或MitM工具的服务器.
Well, to identify the WHAT, developers tend to resort to an API key that usually is sent in the headers of the web app. Some developers go the extra mile and compute the key at run-time in the web app, inside obfuscated javascript, thus it becomes a runtime secret, that can be reverse engineered by deobusfaction tools, and by inspecting the traffic between the web app and API server with the F12 or MitM tools.
上面的文章摘录自我写的一篇文章，题为《 为什么您的移动应用程序需要API密钥?".在移动应用程序的上下文中，总体思想在Web应用程序的上下文中仍然有效.您希望可以在此处全文阅读文章，这是有关API密钥的系列文章中的第一篇.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?. While in the context of a Mobile App, the overall idea is still valid in the context of a web app. You wish you can read the article in full here, that is the first article in a series of articles about API keys.
我可以尝试创建一个域白名单，然后将我的域放入其中.但是，如果我将HTTP标头设置为"Referer"，到我的域，我可以从任何IP访问该API.
I can try to create a domain whitelist and put my domain in this. But still, if I set the HTTP header "Referer" to my domain, I am able to access the API from any IP.
因此，这似乎与使用HERE管理界面有关，在这里我无能为力...
So this seems to be related with using the HERE admin interface, and I cannot help you here...
那我该怎么办?
So, what do I do?
我在前端和后端都使用HERE API.
I am using HERE API in both frontend and backend.
前端必须始终将对第三方API的访问权限委派到受前端所有者控制的后端中，这样您就不会在前端中公开访问凭据来访问此第三方服务.
The frontend MUST always delegate access to third part APIs into a backend that is under the control of the owner of the frontend, this way you don't expose access credentials to access this third part services in your frontend.
所以区别在于，现在您可以直接控制如何防止滥用HERE API访问权限，因为您不再向公众公开HERE api_id和api_code，并且必须对其进行访问通过后端进行处理，在这里，您的访问秘密不会被撬开，而且您可以在这里轻松地监控和限制使用情况，然后再使用HERE API支付帐单.
So the difference is that now is under your direct control how you will protect against abuse of HERE API access, because you are no longer exposing to the public the HERE api_id and api_code, and access to it must be processed through your backend, where your access secrets are hidden from public pry eyes, and where you can easily monitor and throttle usage, before your bill skyrockets in the HERE API.
如果我尝试将我的app_id和app_code放入前端代码中，那么看到我的网站的任何人都可以使用它.
If I try to put my app_id and app_code into the frontend code, it will be available to anyone seeing my site.
总而言之，您应该在前端公开的唯一凭据是用于访问后端的凭据，通常的api-key和Authorization令牌，或者您想命名的任何内容，而不是api_id或api_code来访问HERE API.这种方法只给您一个保护的访问权限，而不是多个.
So to recap, the only credentials you SHOULD expose in your frontend is the ones to access your backend, the usual api-key and Authorization tokens, or whatsoever you want to name them, not the api_id or api_code to access the HERE API. This approach leaves you only with one access to protect, instead of multiple ones.
正如我已经说过的，但是要增强Web应用程序，应该只与您控制下的API服务器通信，对第三方API服务的任何访问都必须由您控制的同一API服务器来完成.通过这种方式，您可以将攻击面限制在一个地方，在那里您将采用防御所需要保护的多层防御系统.
As I already said, but want to reinforce a web app should only communicate with an API server that is under your control and any access to third part APIs services must be done by this same API server you control. This way you limit the attack surface to only one place, where you will employ as many layers of defence as what you are protecting is worth.
对于为网络应用程序提供服务的API，您可以使用从 reCaptcha V3 ，然后是 Web应用防火墙(WAF)，最后是可以负担得起用户行为分析(UBA)解决方案.
For an API serving a web app, you can employ several layers of dense, starting with reCaptcha V3, followed by Web Application Firewall(WAF) and finally if you can afford it a User Behavior Analytics(UBA) solution.
Google reCAPTCHA V3 :
reCAPTCHA是一项免费服务，可保护您的网站免受垃圾邮件和滥用的侵害. reCAPTCHA使用先进的风险分析引擎和适应性挑战，以防止自动化软件参与您网站上的滥用行为.这样做是为了让您的有效用户轻松通过.
reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive challenges to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.
...可帮助您检测网站上的滥用流量，而不会引起用户的摩擦.它会根据与您网站的互动情况返回得分，并为您提供更大的灵活性以采取适当的措施.
...helps you detect abusive traffic on your website without any user friction. It returns a score based on the interactions with your website and provides you more flexibility to take appropriate actions.
Web应用程序防火墙(或WAF)过滤，监视和阻止与Web应用程序之间的HTTP通信. WAF与常规防火墙的区别在于，WAF能够过滤特定Web应用程序的内容，而常规防火墙充当服务器之间的安全门.通过检查HTTP流量，它可以防止Web应用程序安全漏洞(例如SQL注入，跨站点脚本(XSS)，文件包含和安全性错误配置)引起的攻击.</p>
A web application firewall (or WAF) filters, monitors, and blocks HTTP traffic to and from a web application. A WAF is differentiated from a regular firewall in that a WAF is able to filter the content of specific web applications while regular firewalls serve as a safety gate between servers. By inspecting HTTP traffic, it can prevent attacks stemming from web application security flaws, such as SQL injection, cross-site scripting (XSS), file inclusion, and security misconfigurations.
Gartner定义的用户行为分析(UBA)是一个有关检测内部威胁，针对性攻击和财务欺诈的网络安全流程. UBA解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常，即表明潜在威胁的异常. UBA不会跟踪设备或安全事件，而是跟踪系统的用户.像Apache Hadoop这样的大数据平台通过允许它们分析PB级数据来检测内部威胁和高级持久威胁，正在增强UBA功能.
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about the detection of insider threats, targeted attacks, and financial fraud. UBA solutions look at patterns of human behavior, and then apply algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats. Instead of tracking devices or security events, UBA tracks a system's users. Big data platforms like Apache Hadoop are increasing UBA functionality by allowing them to analyze petabytes worth of data to detect insider threats and advanced persistent threats.
所有这些解决方案都基于否定性识别模型，换句话说，他们通过识别出什么是坏的而不是什么好，来尽最大的努力将坏与坏区别开来，因此尽管有先进的解决方案，它们还是容易产生误报其中一些人使用的技术，例如机器学习和人工智能.
All these solutions work based on a negative identification model, by other words they try their best to differentiate the bad from the good by identifying what is bad, not what is good, thus they are prone to false positives, despite the advanced technology used by some of them, like machine learning and artificial intelligence.
因此，您可能经常会发现自己不必放松放松如何阻止对API服务器的访问，以免影响良好的用户.这也意味着这些解决方案需要不断监控，以验证误报不会阻止您的合法用户，同时又能正确阻止未经授权的用户.
So you may find yourself more often than not in having to relax how you block the access to the API server in order to not affect the good users. This also means that these solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at the same time they are properly keeping at bay the unauthorized ones.
任何在客户端运行的，需要一些秘密才能访问API的内容都可能以不同的方式被滥用，并且您必须将对所有第三方API的访问权限委派给您所控制的后端，以减少攻击面，并同时保护他们的秘密，以免受到公众的窥探.
Anything that runs on the client side and needs some secret to access an API can be abused in different ways and you must delegate the access to all third part APIs to a backend under your control, so that you reduce the attack surface, and at the same time protect their secrets from public pry eyes.
最后，必须根据要保护的内容的价值以及此类数据的法律要求(例如欧洲的GDPR法规)来选择用于保护API服务器的解决方案.
In the end, the solution to use in order to protect your API server must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.
因此，使用API钥匙听起来就像锁上了房屋的门，将钥匙留在了垫子下，但不使用它们就像是在门关闭的情况下将车停在停车场，而钥匙却在点火开关中.
So using API keys may sound like locking the door of your home and leave the key under the mat, but not using them is liking leaving your car parked with the door closed, but the key in the ignition.
OWASP Top 10是一个功能强大的Web应用程序安全意识文档.它代表了对Web应用程序最严重的安全风险的广泛共识.该项目的成员包括来自世界各地的各种安全专家，他们分享了他们的专业知识，以编制此列表.
The OWASP Top 10 is a powerful awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. Project members include a variety of security experts from around the world who have shared their expertise to produce this list.
这篇关于如何妥善保护机密?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
