存储api密钥 [英] Storing api keys
问题描述
我正在使用 Goodreads api 为我的本机应用程序获取书籍数据.我必须使用密钥才能使用 api.我可以将 api 密钥存储在应用程序本身上，还是应该将密钥放在将所有数据重定向到应用程序的服务器上?
我可以将 api 密钥存储在应用程序本身上
不，因为正如我在文章
通常，OAuth 向客户端提供安全委托访问".代表资源所有者服务器资源.它指定了资源所有者授权第三方访问其服务器资源而不共享其凭据的过程.OAuth 专为与超文本传输协议 (HTTP) 一起使用而设计，本质上允许授权服务器在资源所有者的批准下将访问令牌颁发给第三方客户端.然后第三方使用访问令牌访问资源服务器托管的受保护资源.
OpenID Connect 1.0 是 OAuth 2.0 协议之上的一个简单身份层.它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终用户的基本配置文件信息.
虽然用户身份验证可以让 API 服务器知道谁正在使用该 API，但它不能保证请求来自您期望的WHAT，原始版本的移动应用.
现在我们需要一种方法来识别什么正在调用 API 服务器，而这里的事情变得比大多数开发人员想象的更棘手.WHAT 是向 API 服务器发出请求的东西.它真的是移动应用程序的真实实例，还是机器人、自动化脚本或攻击者使用 Postman 之类的工具手动浏览 API 服务器?
令您惊讶的是，您最终可能会发现，它可能是合法用户之一，使用重新打包的移动应用版本或试图游戏化并利用应用提供的服务的自动化脚本.
>好吧，为了确定什么，开发人员倾向于求助于 API 密钥，通常他们在移动应用程序的代码中对其进行了硬编码.一些开发人员加倍努力并在移动应用程序中在运行时计算密钥，因此它成为运行时秘密，而不是将静态秘密嵌入代码中的前一种方法.
以上文章摘自我写的一篇文章，标题为为什么您的移动应用需要一个 API 密钥?，您可以阅读全文这里，这是 API 密钥系列文章的第一篇.
您的问题还没有解决
既然您知道了谁和什么访问您的 API 服务器的区别，您一定已经意识到您的 API 服务器仍然容易被攻击者滥用.
您现在可以采取多层防御措施，从 reCaptcha V3，然后是 Web 应用程序防火墙(WAF)，最后是 用户行为分析(UBA) 解决方案.
Google reCAPTCHA V3:
<块引用>reCAPTCHA 是一项免费服务，可保护您的网站免受垃圾邮件和滥用.reCAPTCHA 使用先进的风险分析引擎和自适应挑战来防止自动化软件在您的网站上从事滥用活动.它可以让您的有效用户轻松通过.
...帮助您检测网站上的滥用流量，而不会产生任何用户摩擦.它会根据与您网站的互动情况返回一个分数，让您可以更灵活地采取适当的行动.
<块引用>网络应用防火墙(或 WAF)过滤、监控和阻止进出网络应用的 HTTP 流量.WAF 与常规防火墙的区别在于 WAF 能够过滤特定 Web 应用程序的内容，而常规防火墙则充当服务器之间的安全门.通过检查 HTTP 流量，它可以防止源自 Web 应用安全缺陷的攻击，例如 SQL 注入、跨站点脚本 (XSS)、文件包含和安全配置错误.
<块引用>Gartner 定义的用户行为分析 (UBA) 是一种关于检测内部威胁、针对性攻击和金融欺诈的网络安全流程.UBA 解决方案着眼于人类行为模式，然后应用算法和统计分析从这些模式中检测有意义的异常——表明潜在威胁的异常.UBA 不跟踪设备或安全事件，而是跟踪系统的用户.Apache Hadoop 等大数据平台允许它们分析 PB 级数据以检测内部威胁和高级持续威胁，从而增强 UBA 功能.
所有这些解决方案都基于否定识别模型工作，换句话说，它们通过识别坏的而不是好的来尽力区分坏的和好的，因此尽管它们有误报其中一些使用的先进技术，如机器学习和人工智能.
因此，您可能会发现自己经常不得不放松阻止对 API 服务器的访问的方式，以免影响好用户.这也意味着该解决方案需要持续监控以验证误报不会阻止您的合法用户，同时他们会正确阻止未经授权的用户.
对于为移动应用提供服务的 API，可以通过使用移动应用证明解决方案来使用肯定的识别模型，该解决方案向 API 服务器保证请求可以被信任，而不会出现误报.
移动应用认证
使用移动应用证明解决方案让 API 服务器知道只接收来自正版移动应用的请求.
移动应用证明服务的作用是在运行时通过在后台运行 SDK 来保证您的移动应用没有被篡改或没有在有根设备上运行，该 SDK 将与在云中运行的服务进行通信证明运行的移动应用和设备的完整性.
在成功证明移动应用程序完整性后，将发布一个短期存在的 JWT 令牌，并使用只有 API 服务器和云中的移动应用程序证明服务知道的秘密进行签名.如果移动应用认证失败，JWT 令牌会使用 API 服务器不知道的秘密进行签名.
现在，应用程序必须随每个 API 调用发送请求标头中的 JWT 令牌.这将允许 API 服务器仅在可以验证 JWT 令牌中的签名和到期时间时才提供请求，并在验证失败时拒绝它们.
一旦移动应用证明服务使用的秘密不被移动应用知道，即使应用被篡改、在有根设备中运行或通过连接进行通信，也无法在运行时对其进行逆向工程正在成为中间人攻击的目标.
移动应用证明服务已经作为 Approov 的 SAAS 解决方案存在(我在这里工作)，它为多个平台提供 SDK，包括 iOS、Android、React Native 等.集成还需要对 API 服务器代码进行少量检查，以验证云服务发布的 JWT 令牌.此检查对于 API 服务器来说是必要的，以便能够决定提供哪些请求以及拒绝哪些请求.
总结
任何在客户端运行并需要一些秘密才能访问 API 的东西都可能以不同的方式被滥用，您必须将所有第三方 API 的访问权限委托给您控制的后端，以便减少攻击面，同时保护他们的秘密不被公众窥探.
最后，为了保护您的 API 服务器而使用的解决方案必须根据您要保护的内容的价值以及该类型数据的法律要求(例如欧洲的 GDPR 法规)来选择.
I am using the Goodreads api to get book data for my react native app. I have to use a key for using the api. Is it OK for me to store the api key on the app itself or should I put the key on a server that redirects all the data to the app?
Is it OK for me to store the api key on the app itself
No, because as I demonstrate in the article How to Extract an API Key from a Mobile App by Static binary analysis it can be extracted with the help of several open source tools, like by using the Mobile Security Framework, but you can also grab the API key with a MitM attack, as I show in the article Steal that API Key with a Man in the Middle Attack, that uses the open source tool MiTM Proxy.
If you leave a third party API key in the mobile app, then they are up for grabs from attackers, and when they start using it without your knowledge your bill in the third party provider may go through the roof before you acknowledge that something is wrong, and on that time the only solution is to revoke the API key, thus shutting down the use of the mobile app, and if you make a new release of your mobile app with a new API key it will be just a matter of hours until the attacker come back and steal the API key again.
or should I put the key on a server that redirects all the data to the app?
Yes, and this is a good approach, because now you have only one place to store and protect all third part API keys. This have the benefit to let you control and throttle the use of them as you see fit.
With this solution you still need an API key in your mobile app to allow access to your API server, but while you continue vulnerable for attackers to steal it, you are now in direct control of throttling the access to your API server and if you identify in each access the WHO and the WHAT is accessing the API server, then you have a more fine grade control, but attacker will continue to be able to slip between all our defenses, because is very hard to know WHAT is accessing the API server.
You may be thinking by now... do you mind to explain the WHO vs the WHAT?
The Difference Between WHO and WHAT is Accessing the API Server
To better understand the differences between the WHO and the WHAT are accessing an API server, let’s use this picture:
The Intended Communication Channel represents the mobile app being used as you expected, by a legit user without any malicious intentions, using an untampered version of the mobile app, and communicating directly with the 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 the mobile app, a hacker using the genuine version of the 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 the API server know WHO is using the API, it cannot guarantee that the requests have originated from WHAT you expect, the original version of the mobile app.
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 mobile app, or is a bot, an automated script or an attacker manually poking around with the API server, using a tool like Postman?
For your surprise you may end up discovering that It can be one of the legit users using a repackaged version of the mobile app or an automated script that is trying to gamify and take advantage of the service provided by the application.
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 problem is not solved yet
Now that you know the difference between WHO and WHAT is accessing your API server you must have realized that your API server is still vulnerable to be abused by attackers.
You can resort now to employ several layers of defense, 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.
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 the requests can be trusted without the possibility of false positives.
Mobile App Attestation
Use a Mobile App Attestation solution to enable the API server to know is receiving only requests from a genuine mobile app.
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.
Summary
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.
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密钥的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
