我已经设置了带有身份验证的API,但是我只允许某些应用程序和网站访问它。我该怎么办?
我已经为只能访问API的登录用户设置了身份验证,但是,如何防止他们仅从任何地方登录?
答案 0 :(得分:0)
在解决您的问题之前,我认为重要的是,首先我们要清除开发人员之间关于 WHO 和 What 正在访问API的常见误解。
为更好地了解 WHO 和 What 在访问您的移动应用之间的区别,请使用此图片:
预期的通信渠道表示您的移动设备正被合法用户无恶意使用,使用了您的移动应用程序的未修改版本,并直接与您的API服务器通信,而不会受到中间攻击。
/ p>
实际渠道可能代表几种不同的情况,例如具有恶意意图的合法用户可能正在使用移动应用程序的重新打包版本,黑客使用了移动应用程序的真实版本,而中间人则在攻击它以了解如何完成移动应用程序与API服务器之间的通信,以便能够自动对您的API进行攻击。可能还有许多其他情况,但是我们在这里不逐一列举。
我希望到现在为止您可能已经知道为什么 WHO 和 What 不同的地方,但是如果不一样的话,一会儿就会明白。
WHO 是我们可以通过多种方式(例如使用OpenID Connect或OAUTH2流)进行身份验证,授权和标识的移动应用程序的用户。
通常,OAuth代表资源所有者向客户端提供对服务器资源的“安全委派访问”。它为资源所有者指定了一个在不共享凭据的情况下授权第三方访问其服务器资源的过程。 OAuth专为与超文本传输协议(HTTP)配合使用而设计,实质上允许在资源所有者的批准下,授权服务器将访问令牌发布给第三方客户端。然后,第三方使用访问令牌访问资源服务器托管的受保护资源。
OpenID Connect 1.0是OAuth 2.0协议之上的简单身份层。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份,并以可互操作且类似于REST的方式获取有关最终用户的基本配置文件信息。
尽管用户身份验证可能会让您的API服务器知道 WHO 正在使用API,但不能保证请求来自您期望的移动应用 。< / p>
现在,我们需要一种方法来识别正在调用您的API服务器的内容,这比大多数开发人员想象的要棘手得多。 内容是向API服务器发出请求的内容。它确实是您的移动应用程序的真正实例,还是机器人,自动脚本还是攻击者使用诸如Postman之类的工具在您的API服务器上手动戳戳?
让您感到惊讶的是,您可能最终发现它可能是您的合法用户之一,使用重新打包的移动应用程序版本或自动脚本来游戏化并利用您的服务。
好吧,为了确定内容,开发人员倾向于求助于通常会在其移动应用程序代码中进行硬编码的API密钥。一些开发人员花了很多功夫,并在移动应用程序中在运行时计算密钥,因此与将静态机密嵌入代码中的前一种方法相反,它成为了运行时机密。
以上文章摘录自我写的一篇文章,题为《 为什么您的移动应用程序需要API密钥?”,因此您可以完整阅读here,即有关API密钥的系列文章中的第一篇。
我已经为只能访问API的登录用户设置了身份验证,但是,如何防止他们仅从任何地方登录?
如果用logging in from anywhere
表示任何物理位置,则可以按@hanshenrik的建议使用按IP地址进行阻止,但是如果要阻止其他应用程序的日志记录,则不是您已发布的应用程序API密钥,那么您将面临一个非常棘手的问题,这将导致您遇到的第一个问题:
我已经设置了带有身份验证的API,但是我只允许某些应用程序和网站访问它。我该怎么办?
这取决于要访问的API 是Web还是移动应用程序。
在网络应用中,我们只需要使用浏览器开发工具检查源代码,或者右键单击查看页面源并搜索API密钥,然后在任何工具(如Postman或任何种类的工具)中使用它即可只需复制呼叫,就像我们在浏览器的“网络”标签中看到的那样,即可实现自动化。
对于服务于网络应用的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功能。
所有这些解决方案都基于否定识别模型,换句话说,他们通过识别什么是不好的而不是 What 很好,因此尽管其中一些人使用了机器学习和人工智能等先进技术,但他们还是容易出现误报。
因此,您可能经常会发现自己不必放松放松如何阻止对API服务器的访问以不影响良好用户。这也意味着该解决方案需要进行持续监控,以验证误报不会阻止您的合法用户,同时又能正确阻止未经授权的用户。
从您对评论的回复:
对于移动应用程序呢?
有些人可能认为,以二进制格式发布移动应用程序后,其API密钥将是安全的,但事实并非如此,从二进制文件中提取它有时几乎与从网络中提取它一样容易。应用。
通过众多开源工具(例如,移动安全框架(MobSF),Frida,XPosed,MitmProxy等),可以轻松地对移动应用进行逆向工程,但是您可以在this article中看到,可以使用MobSF或普通Linux发行版中安装的strings
实用程序来完成。
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令牌中的签名和到期时间时才处理请求,而在验证失败时拒绝它们。
一旦移动应用程序不知道移动应用程序证明服务使用的机密,即使在应用程序被篡改,在有根设备上运行或通过连接进行通信时,也无法在运行时对其进行反向工程成为中间攻击中一名男子的目标。
移动应用程序认证服务已经作为Approov上的SAAS解决方案存在(我在这里工作),该服务提供了多个平台的SDK,包括iOS,Android,React Native等。集成还需要在API服务器代码中进行少量检查,以验证由云服务发出的JWT令牌。对于API服务器来说,必须进行此检查才能决定要处理的请求和拒绝的请求。
最后,必须根据要保护的内容的价值以及此类数据的法律要求(例如欧洲的GDPR法规)来选择用于保护API服务器的解决方案。 / p>
因此,使用API钥匙听起来就像锁上了房屋的门,将钥匙留在了垫子下面,但不使用它们就像是在门关闭的情况下将车停在停车场,而钥匙却在点火开关中。