如何使用 Cordova 保护 SPA 和移动应用程序的 REST API

Question

我对围绕此的“最佳实践”进行了大量研究，并阅读了一篇又一篇博客文章、一个又一个问题的 SO 问题，以及一个又一个 OWASP 文章的文章。我已经得出了一些明确的答案，但还有一些未知数。

首先，“做”：

1. 使用 JWT 在我的 REST API 上授权用户 [1] [2]
2. 将 JWT 存储在 HTTPOnly/Secure cookie 中并内置 CSRF 保护。不要存储在 HTML5 本地存储中[3][4][5]（其实这点值得商榷，是不是更容易防范 XSS 或 CSRF？[6]）
3. 验证JWT[7]的签名方式

现在我开始假设拥有 SPA（使用 Angular 构建）并使用 HTML5 sessionStorage 对于短期令牌来说足够安全，但有一点需要指出，XSS 攻击可能来自“不良行为者” " 源自从 CDN 加载的众多库之一。

对于我的特定用例，我不打算使用长期令牌 - 10 分钟不使用后过期，但我仍在考虑是否要按会话跟踪过期或使用刷新令牌 - StormPath 建议前者（不再是无状态的？），但我相信使用 JWT 的大玩家使用刷新令牌（Google 使用它们，但声明您需要将它们存储在安全的长期存储中，这意味着 HTML5 localStorage 又是不可能的）。

我想这样做，以便我的用户在刷新页面时不必重新登录（因此需要将令牌存储在客户端）。我还想在 Cordova 的帮助下将我的 SPA 用作“移动应用程序”。这里明显的缺陷是，如果我使用 cookie，Cordova 没有内置的 cookie 支持/存储，我被敦促改用 HTML5 本地存储。由于在移动设备上我真的不需要担心刷新页面，我可以让我的令牌存在于内存中，并随着我确定的策略过期。

如果我采用这种方法，桌面上基于 cookie 的 JWT，移动设备上的“Bearer”标头，我现在需要一个身份验证端点，它将以两种不同的方式提供令牌，当我在 REST API 端进行授权时，我需要同时支持基于 cookie 的 JWT（使用 CSRF）和基于标头的 JWT 验证。这种复杂性让我很担心，因为我不知道我是否可以准确地预见到这里的安全隐患。

总结一下上面的思路：

• 创建一个身份验证处理程序，该处理程序将通过 HttpOnly/Secure cookie 将令牌分发到桌面，并通过有效负载分发到移动设备。
• 在我的 REST API 上，支持两种验证方法 - 基于标头和基于 cookie - 包括对基于 cookie 方法的 CSRF 保护。

我有什么理由不想采用这种方法吗？我假设如果我将 SPA 上的 XSS 视为严重风险，那么我需要一个经典的登录页面来进行身份验证设置正确的 cookie，因为如果我通过 SPA 进行身份验证，那么任何 XSS 攻击也可能会拦截它（在移动设备和桌面设备上）！但是，在移动设备上，我需要将 JWT 注入 SPA，可能是通过一些自定义 DOM 元素（元标记？），但那时我可以让 SPA 执行登录，而不认为 XSS 对移动设备构成威胁. Cordova 将所有资产打包到安装包中，这样会更好一些，但为什么不在桌面版本上采用相同的方法呢？

我的应用程序需要很少的用户输入，它主要是一个仪表板/报告工具。将有一个“消息中心”，但其内容应始终由用户创建（仅由该用户创建）并进行清理。 那么在我的用例中，是否可以偏离“最佳实践”并依赖 localStorage 而不是将 XSS 视为我的 SPA 的严重风险？这将简化整个事情（使用 HTML5 sessionStorage按照最初的计划）并降低复杂性，这将减少潜在安全错误的攻击面。我只是想确保在继续之前了解风险。

除了为移动设备构建本机应用程序并且不使用 Cordova 将我的 SPA 转换为移动应用程序之外，没有其他安全方法可以确保安全吗？我不喜欢这样情况，但很可能是这样。

感谢您对此事的所有想法！

Answer 1

在考虑设计基于 javascript 的跨平台应用程序以运行移动设备时，设计基于常规 Web 浏览器的应用程序的许多注意事项不一定适用。

就安全性而言，无论您决定使用 JWT 还是简单的 OAuth 令牌，请确保您的所有通信都是通过 https 进行的。

请尽可能多地使用 localStorage。 如果您考虑一个 http 请求的结构，它实际上就是将一些基于文本的消息分为多个部分发送到服务器。请求的标头并不比它的任何其他部分（包括 cookie）更安全。因此，从安全角度来看，兴趣点是令牌的生成/验证/失效、令牌在设备上的存储以及请求的传输机制。

1. Generation/Validation/Invalidation：在您的服务器上生成令牌。使用一些技术/策略来确保不会发生碰撞或出血。此外，请确保您的策略将允许您使服务器上的令牌无效，然后拒绝访问从服务器请求的数据以进一步使用令牌。然后，当服务器拒绝访问资源时，由您在应用中处理用户 UI 旅程。

2. 在设备上存储令牌的方式受限于设备操作系统为您提供的内容。关于使用原生应用程序是否比跨平台更好，我认为如果对“开箱即用”的策略（例如本地存储）不满意，我认为创建一个原生科尔多瓦插件来使用任何特定的原生策略存储您的令牌是可能，尽管根据我的经验，这通常是矫枉过正的。如果有人有不同的经历，很高兴在这一点上得到纠正。

3. 对于所有 Web 服务端点通信，请始终使用 HTTPS，无一例外。 HTTPS 是万无一失的，不，但你不会仅仅因为专门的窃贼可以学会撬锁而建造没有前门的房子。这极大地保护了传输机制。

通常，这也是所有原生应用程序都必须使用的。