如何保护REST-API? [英] How do I secure a REST-API?
问题描述
我已经设置了带有身份验证的API，但是我只允许某些应用程序和网站访问它.我该怎么办?
我已经为只能访问API的登录用户设置了身份验证，但是，如何防止他们仅从任何地方登录?
在我回答您的问题之前，我认为重要的是，首先我们要消除开发人员之间关于 WHO 和什么正在访问API.
谁与您的API服务器进行通信之间的差异
要更好地了解 WHO 和 What 在访问您的移动应用之间的区别，请使用此图片:
目标通信渠道表示您的移动设备正由合法用户使用，没有任何恶意意图，正当使用您的移动设备，该版本未修改的移动应用程序直接与您的API服务器通信，而不会受到中间人的攻击.
实际渠道可能代表几种不同的情况，例如具有恶意意图的合法用户可能正在使用移动应用程序的重新打包版本，黑客使用了移动应用程序的真实版本，而中间人则在攻击它以了解如何完成移动应用程序与API服务器之间的通信，以便能够自动对您的API进行攻击.可能还有许多其他情况，但是我们在这里不逐一列举.
我希望到现在为止您可能已经知道为什么 WHO 和 What 不相同的原因，但是如果不一样，那一会儿就会弄清楚.
WHO 是我们可以通过多种方式(例如使用OpenID Connect或OAUTH2流)进行身份验证，授权和标识的移动应用程序的用户.
通常，OAuth向客户端提供安全委派访问"权限，以确保安全性.代表资源所有者来服务器资源.它为资源所有者指定了一种在不共享其凭据的情况下授权第三方访问其服务器资源的过程. OAuth专为与超文本传输协议(HTTP)配合使用而设计，本质上允许在资源所有者的批准下，授权服务器将访问令牌发布给第三方客户端.然后，第三方使用访问令牌访问资源服务器托管的受保护资源.
OpenID Connect 1.0是OAuth 2.0协议之上的一个简单身份层.它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终用户的基本配置文件信息.
尽管用户身份验证可能会让您的API服务器知道 WHO 正在使用API，但不能保证请求来自您期望的移动应用 .
现在，我们需要一种方法来识别正在调用您的API服务器的内容，这比大多数开发人员想象的要棘手得多. 内容是向API服务器发出请求的内容.它确实是您的移动应用程序的真正实例，还是机器人，自动脚本或攻击者使用诸如Postman之类的工具在您的API服务器上手动戳戳?
令您惊讶的是，您可能最终发现它可能是您的合法用户之一，使用重新打包的移动应用程序版本或自动脚本来游戏化并利用您的服务.
好吧，为了确定内容，开发人员倾向于求助于通常会在其移动应用程序代码中进行硬编码的API密钥.一些开发人员会花更多的精力并在移动应用程序中在运行时计算密钥，因此，与在代码中嵌入静态机密的前一种方法相反，它成为一种运行时机密.
以上文章摘录自我写的一篇文章，标题为《 为什么您的移动应用程序需要API密钥?"，因此您可以完整阅读
对于服务于网络应用程序的API，您可以采用多个密集层，从 reCaptcha V3 ，然后是 Web应用防火墙(WAF)，最后如果可以的话为其提供用户行为分析(UBA)解决方案. Google reCAPTCHA V3 : reCAPTCHA是一项免费服务，可保护您的网站免受垃圾邮件和滥用的侵害. reCAPTCHA使用先进的风险分析引擎和适应性挑战，以防止自动化软件参与您网站上的滥用行为.这样做是为了让您的有效用户轻松通过. ...可帮助您检测网站上的滥用流量，而不会引起用户的摩擦.它会根据与您网站的互动情况返回得分，并为您提供更大的灵活性以采取适当的措施. Web应用程序防火墙(或WAF)过滤，监视和阻止与Web应用程序之间的HTTP通信. WAF与常规防火墙的区别在于，WAF能够过滤特定Web应用程序的内容，而常规防火墙充当服务器之间的安全门.通过检查HTTP流量，它可以防止Web应用程序安全漏洞(例如SQL注入，跨站点脚本(XSS)，文件包含和安全性错误配置)引起的攻击.</p>
Gartner定义的用户行为分析(UBA)是一个有关检测内部威胁，针对性攻击和财务欺诈的网络安全流程. UBA解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测出有意义的异常，即表明潜在威胁的异常. UBA不会跟踪设备或安全事件，而是跟踪系统的用户.像Apache Hadoop这样的大数据平台通过允许它们分析PB级数据来检测内部威胁和高级持久威胁，正在增强UBA功能. 所有这些解决方案都基于否定识别模型，换句话说，他们通过识别什么是不好的，而不是 What 来尽最大的努力来区分优劣.很好，因此尽管其中一些机器使用了诸如机器学习和人工智能之类的先进技术，他们还是容易产生误报. 因此，您可能经常会发现自己不必放松放松如何阻止对API服务器的访问，以免影响良好的用户.这也意味着，此解决方案需要不断监控，以确认误报不会阻止您的合法用户，同时又能正确阻止未经授权的用户. 从您对评论的回复: 移动应用程序如何? 有些人可能认为，以二进制格式发布移动应用程序后，其API密钥将是安全的，但事实并非如此，从二进制文件中提取它有时几乎与从网络中提取它一样容易.应用程序. 通过大量开放源代码工具(例如，移动安全框架(MobSF)，Frida，XPosed，MitmProxy等)，可以轻松地对移动应用程序进行逆向工程，但是您可以在移动安全框架 Mobile Security Framework是一个自动化的多合一移动应用程序(Android/iOS/Windows)笔测试框架，能够执行静态分析，动态分析，恶意软件分析和Web API测试. 将您自己的脚本注入黑匣子进程.挂钩任何功能，监视加密API或跟踪私有应用程序代码，不需要任何源代码.编辑，点击保存，立即查看结果.全部没有编译步骤或程序重新启动. Xposed是用于模块的框架，可以在不触摸任何APK的情况下更改系统和应用程序的行为.太好了，因为这意味着模块可以在不进行任何更改的情况下适用于不同版本甚至ROM(只要原始代码的更改不太多).撤消操作也很容易. 面向渗透测试人员和软件开发人员的交互式TLS拦截HTTP代理. 关于为移动应用程序提供服务的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. 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. 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 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. 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.
移动应用程序
移动应用证明
结论
THE DIFFERENCE BETWEEN WHO AND WHAT IS COMMUNICATING WITH YOUR API SERVER
YOUR QUESTIONS
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?
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:
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?
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:
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.
WAF - Web Application Firewall:
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.
UBA - User Behavior Analytics:
User behavior analytics (UBA) as defined by Gartner is a cybersecurity process about 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 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:
What about for mobile applications?
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.
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
Xposed is a framework for modules that can change the behavior of the system and apps without touching any APKs. That's great because it means that modules can work for different versions and even ROMs without any changes (as long as the original code was not changed too much). It's also easy to undo.
An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
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?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
