1。如何仅通过移动伴侣应用程序和外部Web服务器后端提供对我的api的公共访问？

简而言之：您不能。

您可以做的是使用混淆的序列化格式，将所有内容包装在加密中，并将应用程序密钥隐藏在二进制代码的深处。但是，归根结底，只要攻击者可以访问您的应用程序可执行代码，就始终可以对它进行反向工程，以达到可以对应用程序与服务器之间的通信进行真实仿真的程度。

2。如何处理api的匿名（未经身份验证的用户）使用情况？

仅在用户身份验证后才允许访问API。

然后如何进行身份验证：对应用程序使用令牌，对用户使用令牌？

同样，如果用户有权访问应用程序的可执行文件，则始终可以提取应用程序的“令牌”。

通常，您只能验证网络上的参与者，而不能验证参与者正在使用的“齿轮”。

在尝试解决您的问题之前，我想明确区分 WHO 和正在访问API服务器的内容。

谁和什么来访问API服务器

WHO 是移动应用程序的用户，您可以通过多种方式（例如使用OpenID或OAUTH2流）进行身份验证，授权和标识。

OAuth2

OAuth 2.0是用于授权的行业标准协议。 OAuth 2.0取代了在2006年创建的原始OAuth协议上所做的工作。OAuth2.0专注于简化客户端开发人员，同时为Web应用程序，桌面应用程序，移动电话和客厅设备提供特定的授权流。该规范及其扩展名正在IETF OAuth Working Group中开发。

OpenID Connect

OpenID Connect 1.0是OAuth 2.0协议之上的简单身份层。它允许客户端基于授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终用户的基本配置文件信息。 OpenID Connect执行许多与OpenID 2.0相同的任务，但是这样做的方式是API友好的，并且可由本机和移动应用程序使用。 OpenID Connect定义了用于可靠签名和加密的可选机制。 OAuth 1.0a和OpenID 2.0的集成需要扩展，而在OpenID Connect中，OAuth 2.0的功能与协议本身集成在一起。

现在，您需要一种方法来识别正在调用API服务器的什么，这比大多数开发人员想象的要棘手得多。什么是向API服务器发出请求的东西，是真的是您真正的移动应用程序，还是机器人，自动脚本或攻击者使用诸如Postman之类的工具手动在您的API服务器上乱逛？

可以识别什么的开发人员倾向于使用API密钥，这些密钥通常会在其移动应用程序的代码中进行硬编码，有些则花了很多功夫并在运行时计算移动应用程序因此成为动态的秘密，与以前的方法相反，后者是嵌入代码中的静态秘密。

您的问题

如何仅通过移动伴侣应用程序和外部Web服务器后端提供对我的api的公共访问权限？

对于Web服务器后端

在这种情况下，内容不在客户端，因此您可以使用证书固定在Web服务器后端与API服务器之间，以确保 API服务器可以信任来自受信任源的传入请求。

Certificate Pinning

固定是将主机与其预期的X509证书或公钥关联的过程。一旦知道或看到了主机的证书或公钥，便会将证书或公钥关联或“固定”到主机。如果可以接受多个证书或公钥，则该程序将保留一个密码集（取自Jon Larimer和Kenny Root Google I / O谈话）。在这种情况下，所宣传的身份必须与引脚集中的元素之一匹配。

对于移动应用

在这种情况下，移动应用程序在客户端运行，因此需要保密识别正在访问的内容，您可以在this series的有关移动API安全技术的文章中了解更多信息，以了解如何使用API密钥，用户访问令牌，HMAC和证书固定保护API以及如何绕过它们。

对移动应用程序二进制文件进行反向工程很容易

事实是，在客户端运行的任何东西都可以进行反向工程容易受到攻击者在他控制的设备上的攻击。他将使用Frida或xPosed之类的自省框架在运行时拦截移动应用程序的运行代码，或者使用MiTM Proxy这样的代理工具来监视移动应用程序与移动应用程序之间的通信。 API服务器。通常，他们对移动应用程序进行反向工程的第一步是使用Mobile Security Framework对您的移动应用程序的二进制文件进行反向工程，以提取所有静态机密并确定攻击媒介。

Mobile Security Framework

Mobile Security Framework是一个自动化的多合一移动应用程序（Android / iOS / Windows）笔测试框架，能够执行静态分析，动态分析，恶意软件分析和Web API测试。

Frida

将您自己的脚本注入黑盒进程。挂钩任何功能，监视加密API或跟踪私有应用程序代码，不需要任何源代码。编辑，点击保存，立即查看结果。全部没有编译步骤或程序重新启动。

xPosed

Xposed是用于模块的框架，可以在不触摸任何APK的情况下更改系统和应用程序的行为。太好了，因为这意味着模块可以用于不同版本甚至ROM，而无需进行任何更改（只要原始代码的更改不太多）。撤消操作也很容易。

MiTM Proxy

面向渗透测试人员和软件开发人员的交互式TLS拦截HTTP代理。

那么，现在...我注定要保护我的API服务器不被滥用吗？？没有安静，所以...希望仍然存在！

可能的解决方案

要解决什么正在访问您的移动应用程序的问题，您需要使用我上面提到的有关移动API安全技术的系列文章中提到的一个或所有解决方案，并接受它们可以只会使未经授权访问您的API服务器更加困难，但这并非不可能。

您可以使用WAF或UBA解决方案来尝试识别和阻止对API的滥用，但是这种方法会导致误报，因此需要一些宽松的规则和常数进行监控以确保真正的用户不会被阻止使用该API。

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功能。

通过使用移动应用程序证明解决方案，可以采用更好的解决方案，该解决方案将使API服务器能够知道仅接收到来自真正移动应用程序的请求。

移动应用证明

使用移动应用证明解决方案将使API服务器能够知道正在发送请求的内容，从而仅响应来自真正移动应用的请求，而拒绝来自不安全来源的所有其他请求。

移动应用程序证明服务的作用是在运行时通过在后台运行将与云中运行的服务进行通信的SDK来确保您的移动应用程序未被篡改或未在有根设备中运行证明移动应用程序和设备正在运行的完整性。

在成功证明移动应用程序完整性之后，将发布并使用一个秘密的短期生存JWT令牌进行签名，该秘密只有云中的API服务器和移动应用程序证明服务可以识别。如果移动应用程序证明失败，则会使用API服务器不知道的秘密对JWT令牌进行签名。

现在，应用程序必须随每个API一起发送，并在请求的标头中调用JWT令牌。这将允许API服务器仅在可以验证JWT令牌中的签名和到期时间时才处理请求，而在验证失败时拒绝它们。

一旦移动应用程序不知道移动应用程序证明服务使用的机密，即使在应用程序被篡改，在有根设备上运行或通过连接进行通信时，也无法在运行时对其进行反向工程成为中间攻击中一名男子的目标。

因此，该解决方案可在没有误报的积极检测模型中工作，从而不会阻止合法用户，同时又将坏人拒之门外。

移动应用程序认证服务已经作为Approov上的SAAS解决方案存在（我在这里工作），该服务提供了多个平台的SDK，包括iOS，Android，React Native等。集成还需要在API服务器代码中进行少量检查，以验证由云服务发出的JWT令牌。对于API服务器来说，必须进行此检查才能决定要处理的请求和拒绝的请求。

如何处理匿名（未经身份验证的用户）使用api？

所以在这里，您似乎只担心正在访问什么正在访问您的API，因此您需要从我针对问题1提到的解决方案中决定要使用的解决方案。

然后如何验证自己的身份：对应用程序使用令牌还是对用户使用令牌？

是的，您应该始终知道什么和 WHO 正在访问您的API服务器。所以对于 WHO 的用户，我建议使用OAUTH2或OpenID Connect，并且对于内容，移动应用和网络服务器，您只需要从我要使用的解决方案中选择要使用的解决方案提到问题1。

结论

最后，必须根据要保护的内容的价值以及此类数据的法律要求（例如欧洲的GDPR法规）来选择用于保护API服务器的解决方案。 / p>

如何正确保护我的api并提供身份验证？

2 个答案: