首页
学习
活动
专区
工具
TVP
发布
社区首页 >问答首页 >如何使用Cordova保护SPA和移动应用程序的REST API

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

Stack Overflow用户
提问于 2015-10-01 23:46:53
回答 1查看 2.1K关注 0票数 19

我围绕这一点做了很多关于“最佳实践”的研究,并阅读了一篇又一篇的博客文章,所以一个又一个的问题,以及OWASP文章一篇又一篇。我已经得到了一些明确的答案,但也有一些未知之处。

首先,"Do's":

使用JWT在HTTPOnly/ [2]

  • Store cookie中为我的REST API上的用户授权
  1. [1] JWT,并内置CSRF保护。[6])
  2. Verify the JWT [7]

的HTML5 [3] [4] [5] (实际上,这一点是有争议的,哪一个更容易保护

现在我开始假设有一个SPA (使用Angular构建)并使用HTML5 sessionStorage对于短暂的令牌来说是足够安全的,但是有一点需要指出的是,XSS攻击可能来自于从CDN加载的许多库中的一个“坏角色”。

对于我的特定用例,我不打算使用长期令牌-不使用10分钟后过期,但我仍在考虑是按会话跟踪过期还是使用刷新令牌- StormPath建议使用前者(不再是无状态的?)但我相信使用JWTs的大玩家使用刷新令牌(谷歌使用它们,但声明您需要将它们存储在安全的长期存储中,这意味着HTML5 localStorage也是不可能的)。

我想让我的用户在刷新页面时不必重新登录(因此需要在客户端存储令牌)。我还想在Cordova的帮助下将我的SPA用作“移动应用程序”。这里明显的缺陷是,如果我使用cookie,Cordova没有内置的cookie支持/存储,所以我被要求改用HTML5本地存储。因为在移动端我真的不需要担心刷新页面,所以我可以让我的令牌留在内存中,并使用我确定的策略过期。

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

总结一下上面一连串的想法:

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

我假设如果我在我的SPA上使用XSS是一个严重的风险,那么我需要一个经典的登录页面来设置正确的cookie,因为如果我通过SPA进行身份验证,那么任何XSS攻击都有可能拦截它(在移动和桌面上)!但是,在移动设备上,我需要将JWT注入到SPA中,可能是通过一些自定义的DOM元素(meta tag?),但在这一点上,我可以让SPA执行登录,而不是将XSS视为移动设备上的威胁。Cordova将所有资产打包到安装包中,这样会更好一些,但是为什么不在桌面版本上采用相同的方法呢?

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

除了为移动设备构建一个本地应用程序,而不是使用将我的SPA转换为移动应用程序之外,有没有其他安全的方法来确保这一点?我讨厌这种情况,但它很可能是这样的。

我会感激所有关于这件事的想法!

EN

回答 1

Stack Overflow用户

发布于 2016-10-21 19:49:52

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

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

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

  1. Generation/Validation/Invalidation:在您的服务器上生成令牌。使用一些技术/策略来确保没有碰撞或出血的可能性。此外,请确保您的策略允许您使服务器上的令牌无效,然后在进一步使用令牌时拒绝访问从服务器请求的数据。然后,当服务器拒绝访问资源时,由您在应用程序中处理用户UI过程。
  2. 您在设备上存储令牌的方式受设备操作系统提供给您的内容的限制。至于使用原生应用程序是否比跨平台更好,我认为如果用户对“开箱即用”的策略(如本地存储)不满意,可以创建一个原生-cordova插件来使用任何特定的原生策略来存储您的令牌,尽管根据我的经验,这通常是大材小用。很高兴在这个问题上得到纠正,如果任何人有不同的experience.
  3. Please,请无一例外地对所有Webservice端点通信使用HTTPS。HTTPS是万无一失的,不,但你不会建造一座没有前门的房子,仅仅因为专门的窃贼可以学会撬锁。这在很大程度上保证了传输机制的安全。

通常,这也是原生应用程序必须使用的全部内容。

票数 2
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/32891741

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档