通常，您将提供一个后端服务，该服务将公开一些API供您的应用程序使用

例如，您可以在myserver.com/something上使用API，这将是PHP脚本或其他服务器端语言。这将返回应用程序需要显示的数据。您可以使用JSON之类的数据对数据进行编码，应用程序可以使用合适的库读取数据。

发送数据的工作原理类似，创建一个可以通过HTTP接受POST请求并将其存储回数据库的API。登录名和SQL应该都在服务器端。

例如，应用程序使用参数someInfo =“ hello world”将请求发送到server.com/storeInformation

然后，服务器端（例如php）执行查询INSERT INTO myTable VALUES（...无论如何。）

重点是客户端应用程序永远不需要直接发送SQL（因为它不能被信任），而是应该发送想要完成的事情，然后服务器决定如何完成。

通常，请记住永远不要信任客户端。任何人都可以使用任何参数调用您的服务器API。

我知道将带有凭据，API-Key等的数据库连接字符串放入其中确实很糟糕，因为您可以对其进行反编译以查看其值...

是的，对于任何类型的应用程序来说，这都是非常糟糕的，无论是移动，Web还是物联网应用程序。

那么，一切都需要在API后面吗？

是的，您的应用程序必须尽可能的笨。换句话说，您的应用程序中的代码应仅尽可能地与表示有关，任何业务逻辑都应委派给API服务器。这种方法的巨大优势在于，只要有错误，就只需要更新API服务器，而无需更新应用程序本身，然后等待所有客户端在其移动设备中对其进行更新。对于Web应用程序，您不想向在浏览器中按F12键并开始在开发人员工具面板中调试代码的任何人透露您的业务逻辑。

是否需要将SQL查询放在Web服务后面，或者我们可以对存储过程进行参数化查询，那可以吗？

正如我之前所说，APP必须尽可能地愚蠢，并且永远不要从客户端向任何类型的后端执行SQL查询，否则您的服务将面临巨大的安全漏洞。

从客户端到后端的任何内容都必须被视为潜在恶意，因为即使您认为知道 WHO 正在发出请求，您也可能不知道做到了。为了更好地了解 WHO 和 What 正在访问您的服务器之间的区别，请阅读这张图片所在部分的this article：

Man in the Middle Attack

所以简而言之， WHO 表示用户， What 表示正在执行请求的应用程序/设备，如图所示，它可能被攻击者篡改与一名中间人袭击。

我假设这也需要在Web服务之后，并且只返回JSON数组等内容。

Json是最常用的从API返回响应的格式，因为它易于被人和机器读取，但是还存在其他格式。

我还没有真正查看过关于不应该为移动应用程序提供网络服务的内容的清单。

虽然您要查询的列表可能不存在（因为范围很广），但可以从避免在移动应用中使用OWASP Mobile Security Project - Top 10 risks开始。

我来自Web开发职位，所以到目前为止，这并不是真正的问题。

虽然您可能未在Web应用程序中使用API密钥，但是如果您从它们中进行SQL查询，则您将面临SQL注入的风险，这是暴露于Internet的任何应用程序中最常见的风险，即继续位于OWASP Top 10 - 2017（pdf）的第一位置。

我们是否基本上需要通过网络服务来运行我们的应用程序

是的，您需要通过API服务器运行移动应用。

如果是的话，我们该如何将Web服务与应用程序合并，因为我们一开始就无法对Web服务的密钥进行硬编码？

正如我在文章How to Extract an API Key from a Mobile App by Static binary analysis中所演示的那样，可以借助几种开放源代码工具来提取它，例如使用Mobile Security Framework，但是您也可以通过MitM攻击来获取API密钥，正如我在文章Steal that API Key with a Man in the Middle Attack中展示的那样，它使用了开源工具MiTM Proxy。

那么，现在......如果我使用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功能。

所有这些解决方案都基于否定性识别模型，换句话说，他们通过识别出什么是不好的而不是什么是好的来尽最大的努力将好与坏区别开来，因此尽管存在以下缺点，它们还是容易出现误报的情况其中一些人使用了先进的技术，例如机器学习和人工智能。

因此，您可能经常会发现自己不必放松放松如何阻止对API服务器的访问以不影响良好用户。这也意味着该解决方案需要进行持续监控，以验证误报不会阻止您的合法用户，同时又能正确阻止未经授权的用户。

关于为移动应用程序提供服务的API，可以通过使用移动应用程序证明解决方案来使用肯定的识别模型，该解决方案向API服务器保证可以信任请求，而不会产生误报。

移动应用证明

使用移动应用证明解决方案，使API服务器能够知道仅接收到来自真正移动应用的请求。

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

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

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

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

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

回复您的摘要

我们是否需要创建一个全面的Web服务，以便在数据库和android应用客户端之间进行交换，而对于任何第三方API来说都是相同的？

是的，您应该始终将访问权委托给任何类型的应用程序，移动设备，Web或IOT应用程序中的第三方服务，否则，当攻击者获取凭据以访问它们并开始在您的设备上使用它们时，您会遇到麻烦代表，而您将是支付账单的人。

此外，由于此Web服务的目的是从一开始就防止硬编码密钥，因此我们如何授权android应用与我们的Web服务交互？

移动应用证明解决方案在这里看起来最合适。

总结

任何在客户端运行的，需要一些秘密才能访问API的内容都可能以不同的方式被滥用，并且您必须将对所有第三方API的访问权限委派给您所控制的后端，以便减少攻击面，并同时保护他们的秘密，以免被公众窥探。

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

在Android应用程序中不要硬编码的内容

2 个答案:

移动应用证明

回复您的摘要

总结