适用于移动和web的安全API

Question

我有三份申请：

• REST API
• 单页Web应用程序
• 本机移动应用程序。

• 基于令牌的身份验证
• 基于会话/cookie的身份验证（安全且仅限于HTTP)

Cookie容易受到CSRF攻击，因此为了防止这种攻击，我需要实现CSRF令牌或类似的保护策略。为了一个安全的CSRF令牌实现，我还应该设置适当的CORS策略，这样外国站点就不能从API获得CSRF令牌。这对web应用程序也很好，但对移动应用程序不可能，因为移动应用程序不支持CORS（它现在有域或起源标题）。

另一种方法是基于令牌的身份验证，它适用于移动应用程序，并且不需要CSRF令牌，因为它们本身可以验证请求的真实性。然而，没有安全的方法将令牌存储在单页Web应用程序中（区域设置/Web存储不安全，如果我使用cookie，我们基本上回到了我们的第一个问题）。

Answer 1

另一种方法是基于令牌的身份验证，它适用于移动应用程序，并且不需要CSRF令牌，因为它们本身可以验证请求的真实性。

不能信任Auth令牌来验证请求的真实性，因为它们只识别用户，而不是真正的移动应用程序执行请求。

控制运行移动应用程序的设备的攻击者可以提取auth令牌，以自动化对API服务器的请求。攻击者使用的另一种技术是为免费wifi（机场、火车站和其他公共场所）创建一个虚假的俘获门户，在那里他们欺骗登录者在其移动设备中安装自定义ssl证书，这样攻击者就可以解密https通信量，从而窃取auth令牌，并代表用户执行对API服务器的自动请求。

我目前的想法是实现这两种策略，但只允许在origin不存在时使用令牌auth，只允许在origin header存在且CORS策略允许时使用会话/cookie auth。

攻击者可以很容易地绕过并自动执行此操作。因此，攻击者只使用窃取的令牌进行请求，而不使用请求头中的源码，从而避免了web的安全性，也绕过了移动应用程序的安全性。

但我现在是这方面的专家，可能很容易误解什么。任何建议或进一步的解释将非常欢迎：）！

使用Strict Transport Policy标头确保web应用程序始终通过HTTPS加载。

您的web应用程序应该使用CSP（内容安全策略）和报告服务，当任何策略被违反时，报告服务将让您实时知道。

如果使用cookie，您应该启用httponly标志，以保护它们不被通过JavaScript访问。此外，您还希望启用仅发送Cookie的安全标志，以悬停https连接。还要尝试通过cookie所属的路径对cookie进行作用，即登录页面的cookie应作用于/login路径，因此不会为web应用程序的其他页面或资产（图像、css等）发送cookie。

我们很高兴推出reCAPTCHA v3，它可以帮助您在没有任何用户摩擦的情况下检测网站上的滥用流量。它根据与网站的交互返回一个分数，并为您提供更多的灵活性来采取适当的行动。

这一分数将允许对阻止非人类交通有一定程度的信心。如果您需要更多的信心，那么您可能还想使用用户行为分析(UBA)解决方案，该解决方案可能使用机器学习和人工智能来进一步分析传入的流量和检测滥用流量。由于web的工作方式，reCaptcha V3和UBA都不能提供防弹解决方案来验证请求是否合法。

对于移动应用程序：

现在，应用程序必须与每个API调用一起发送请求头中的JWT令牌。这将允许API服务器仅在能够验证JWT令牌中的签名和过期时间时提供请求，并在验证失败时拒绝这些请求。

一旦移动应用程序不知道移动应用程序认证服务使用的秘密，即使应用程序被篡改、在根设备中运行或通过中间攻击者的目标连接进行通信，也不可能在运行时对其进行反向工程。

移动应用认证服务已经作为SAAS解决方案存在于Approov（我在这里工作），它为几个平台提供SDK，包括iOS、Android、React Native和其他平台。集成还需要在API服务器代码中进行一个小检查，以验证云服务发出的JWT令牌。这种检查对于API服务器能够决定服务哪些请求和拒绝哪些请求是必要的。

对于web应用程序：

• OpenID或OAUTH2，适用于移动和web应用程序，可能使用cookie存储auth令牌，范围由url路径限定，启用httpOnly和secure标志。
• 进一步使用严格的CSP策略以及CORS、CSFR、严格的传输策略和现在可能缺少的任何其他策略。
• 谷歌reCaptcha v3.

对于手机App：

null

虽然web请求是在尽最大努力的基础上进行验证的，但来自受移动认证服务保护的移动应用程序的请求只有两种可能的结果，有效或无效。