问题描述
我已经设置了带有身份验证的API，但是我只允许某些应用程序和网站访问它.我该怎么办?
我已经为只能访问API的登录用户设置了身份验证，但是，如何防止他们仅从任何地方登录?
在我回答您的问题之前，我认为重要的是，首先我们要消除开发人员之间关于 WHO 和什么正在访问API.
谁与您的API服务器进行通信之间的差异
要更好地了解 WHO 和 What 在访问您的移动应用之间的区别，请使用此图片:
目标通信渠道表示您的移动设备正由合法用户使用，没有任何恶意意图，正当使用您的移动设备，该版本未修改的移动应用程序直接与您的API服务器通信，而不会受到中间人的攻击.
实际渠道可能代表几种不同的情况，例如具有恶意意图的合法用户可能正在使用移动应用程序的重新打包版本，黑客使用了移动应用程序的真实版本，而中间人则在攻击它以了解如何完成移动应用程序与API服务器之间的通信，以便能够自动对您的API进行攻击.可能还有许多其他情况，但是我们在这里不逐一列举.
我希望到现在为止您可能已经知道为什么 WHO 和 What 不相同的原因，但是如果不一样，那一会儿就会弄清楚.
WHO 是我们可以通过多种方式(例如使用OpenID Connect或OAUTH2流)进行身份验证，授权和标识的移动应用程序的用户.
尽管用户身份验证可能会让您的API服务器知道 WHO 正在使用API，但不能保证请求来自您期望的移动应用 .
现在，我们需要一种方法来识别正在调用您的API服务器的内容，这比大多数开发人员想象的要棘手得多. 内容是向API服务器发出请求的内容.它确实是您的移动应用程序的真正实例，还是机器人，自动脚本或攻击者使用诸如Postman之类的工具在您的API服务器上手动戳戳?
令您惊讶的是，您可能最终发现它可能是您的合法用户之一，使用重新打包的移动应用程序版本或自动脚本来游戏化并利用您的服务.
好吧，为了确定内容，开发人员倾向于求助于通常会在其移动应用程序代码中进行硬编码的API密钥.一些开发人员会花更多的精力并在移动应用程序中在运行时计算密钥，因此，与在代码中嵌入静态机密的前一种方法相反，它成为一种运行时机密.
以上文章摘录自我写的一篇文章，标题为《 为什么您的移动应用程序需要API密钥?"，因此您可以完整阅读此处，这是有关API的系列文章中的第一篇键.
您的问题
如果通过logging in from anywhere表示任何物理位置，则可以使用@hanshenrik建议的通过IP地址进行阻止，但是如果您表示要阻止从其他应用程序登录，则不是您已发布API的应用程序键，那么您手中有一个非常棘手的问题需要解决，这会引出您的第一个问题:
这取决于要访问的API 是Web还是移动应用程序.
Web应用程序
在网络应用中，我们只需要使用浏览器开发工具检查源代码，或者右键单击查看页面源并搜索API密钥，然后在任何工具(例如Postman或任何种类的工具)中使用它即可我们希望实现自动化，只需复制呼叫即可，就像我们在浏览器的网络"标签中看到的那样.
对于服务于网络应用程序的API，您可以采用多个密集层，从 reCaptcha V3 ，然后是 Web应用防火墙(WAF)，最后如果可以的话为其提供用户行为分析(UBA)解决方案.
Google reCAPTCHA V3 :
所有这些解决方案都基于否定识别模型，换句话说，他们通过识别什么是不好的，而不是 What 来尽最大的努力来区分优劣.很好，因此尽管其中一些机器使用了诸如机器学习和人工智能之类的先进技术，他们还是容易产生误报.
因此，您可能经常会发现自己不必放松放松如何阻止对API服务器的访问，以免影响良好的用户.这也意味着，此解决方案需要不断监控，以确认误报不会阻止您的合法用户，同时又能正确阻止未经授权的用户.
移动应用程序
从您对评论的回复:
有些人可能认为，以二进制格式发布移动应用程序后，其API密钥将是安全的，但事实并非如此，从二进制文件中提取它有时几乎与从网络中提取它一样容易.应用程序.
通过大量开放源代码工具(例如，移动安全框架(MobSF)，Frida，XPosed，MitmProxy等)，可以轻松地对移动应用程序进行逆向工程，但是您可以在本文 ，则可以使用MobSF或普通Linux发行版中安装的strings实用程序来完成.
关于为移动应用程序提供服务的API，可以通过使用移动应用程序证明解决方案来使用肯定的识别模型，该解决方案向API服务器保证所做的请求可以被信任，而不会出现虚假的情况肯定的.
移动应用证明
移动应用程序证明服务的作用是在运行时通过在后台运行将与云中运行的服务进行通信的SDK来确保您的移动应用程序未被篡改或未在有根设备中运行证明移动应用程序和设备正在运行的完整性.
在成功证明移动应用程序完整性之后，将发布并使用一个秘密的短期生存JWT令牌进行签名，该秘密仅可识别云中的API服务器和移动应用程序证明服务.如果移动应用程序证明失败，则会使用API服务器不知道的秘密对JWT令牌进行签名.
现在，应用程序必须与每个API一起发送，并在请求的标头中调用JWT令牌.这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时才服务请求，而在验证失败时拒绝请求.
一旦移动应用程序不知道移动应用程序证明服务使用的机密，即使在应用程序被篡改，在有根设备中运行或通过连接进行通信时，也无法在运行时对其进行反向工程成为中间攻击中一名男子的目标.
移动应用程序证明服务已经作为SAAS解决方案存在于 Approov (我在这里工作)为多个平台提供SDK，包括iOS，Android，React Native等.集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌.对于API服务器来说，必须进行此检查才能决定要处理的请求和拒绝的请求.
结论
最后，必须根据要保护的内容的价值以及此类数据的法律要求(例如欧洲的GDPR法规)来选择用于保护API服务器的解决方案./p>
因此，使用API钥匙听起来就像锁上了房屋的门，将钥匙留在了垫子下，但不使用它们就像是在门关闭的情况下将车停在停车场，而钥匙却在点火开关中.
I've set up an API with authentication but I want to only allow certain applications and websites to access it. What do I do?
I've got authentication set up for users that are Logged in only being able to access the API, however, how do I prevent them from just logging in from anywhere?
Before I address your question, I think is important that first we clear a common misconception among developers, regarding WHO and WHAT is accessing an API.
THE DIFFERENCE BETWEEN WHO AND WHAT IS COMMUNICATING WITH YOUR API SERVER
To better understand the differences between the WHO and the WHAT are accessing your mobile app, let’s use this picture:
The Intended Communication Channel represents your mobile being used as you expected, by a legit user without any malicious intentions, using an untampered version of your mobile app, and communicating directly with your API server without being man in the middle attacked.
The actual channel may represent several different scenarios, like a legit user with malicious intentions that may be using a repackaged version of your mobile app, a hacker using the genuine version of you mobile app while man in the middle attacking it to understand how the communication between the mobile app and the API server is being done in order to be able to automate attacks against your API. Many other scenarios are possible, but we will not enumerate each one here.
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.
The WHO is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
While user authentication may let your API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, your mobile app.
Now we need a way to identify WHAT is calling your 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 your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
For your surprise you may end up discovering that It can be one of your legit users using a repackaged version of your mobile app or an automated script trying to gamify and take advantage of your service.
Well, to identify the WHAT, developers tend to resort to an API key that usually they hard-code in the code of their mobile app. Some developers go the extra mile and compute the key at run-time in the mobile app, thus it becomes a runtime secret as opposed to the former approach when a static secret is embedded in the code.
The above write-up was extracted from an article I wrote, entitled WHY DOES YOUR MOBILE APP NEED AN API KEY?, and that you can read in full here, that is the first article in a series of articles about API keys.
YOUR QUESTIONS
If by logging in from anywhere you mean any physical location, then you can use blocking by IP address as already suggested by @hanshenrik, but if you mean blocking from logging from other applications, that are not the ones you have issued the API keys for, then you have a very hard problem in your hands to solve, that leads to your first question:
This will depend if WHAT is accessing the API is a web or a mobile application.
Web application
In a web app we only need to inspect the source code with the browser dev tools or by right click on view page source and search for the API key, and then use it in any tool, like Postman or in any kind of automation we want, just by replicating the calls as we saw them being made in the network tab of the browser.
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:
WAF - Web Application Firewall:
UBA - User Behavior Analytics:
All this 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 of the advanced technology used by some of them, like machine learning and artificial intelligence.
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 this solutions require constant monitoring to validate that the false positives are not blocking your legit users and that at same time they are properly keeping at bay the unauthorized ones.
Mobile Application
From your reply to a comment:
Some may think that once a mobile app is released in a binary format that their API key will be safe, but turns out that is not true, and extracting it from a binary is sometimes almost as easy as extracting it from a web application.
Reverse engineering a mobile app is made easy by plethora of open source tools, like the Mobile Security Framework(MobSF), Frida, XPosed, MitmProxy, and many other more, but as you can see in this article, it can be done with MobSF or with the strings utility that is installed in a normal Linux distribution.
Regarding APIs serving mobile apps a positive identification model can be used by using a Mobile App Attestation solution that guarantees to the API server that WHAT is making the requests can be trusted, without the possibility of false positives.
The Mobile App Attestation
The role of a Mobile App Attestation service is to guarantee at run-time that your mobile app was not tampered or is not running in a rooted device by running a SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and device is running on.
On successful attestation of the mobile app integrity a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.
Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.
Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
The Mobile App Attestation service already exists as a SAAS solution at Approov(I work here) that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.
CONCLUSION
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.
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.
这篇关于如何保护REST-API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！