将登录页面包含在单页应用程序中是否不安全？

Question

我的理解是，如果您将登录页面包含在SPA中，那么用户甚至在通过身份验证之前都会收到您的所有代码。但是，这似乎是非常普遍的做法。这不是非常不安全吗？为什么或者为什么不？

Answer 1

SPA将具有所有页面结构（用于页面设计的html和javascript代码），但显然没有数据。数据将在后续的ajax请求中下载，这就是重点。要下载实际数据，必须向服务器验证用户身份，然后在服务器端实现所有安全性。未经授权的用户不应能够从服务器访问数据。但是想法是页面的外观不是秘密，任何人都可以在没有数据的情况下查看SPA的页面，这很好。

好吧，这就是人们经常忽略的问题。HTML是一回事，但是SPA中的所有javascript都可以访问所有数据。基本上，SPA的代码是一个API文档（如果您愿意），是后端可以处理的可能查询的列表。当然，应该在服务器端都是安全的，但并非总是如此，人们会犯错误。有了SPA这样的“文档”，攻击者可以更轻松地评估服务器端的安全性并在服务器端代码中查找授权/访问控制漏洞，从而可以访问不应被访问的数据攻击者。

简而言之，访问页面外观（无数据）应该没问题。但是，在某些情况下放弃API的确切工作方式可以帮助攻击者，因此会增加SPA固有的风险。

必须指出的是，这并不重要。由于不应使用默默无闻的安全性（即，事情的工作方式不应作为秘密，只有凭据之类的事情才应该是秘密），最好让任何人都知道所有javascript或完整的API文档。但是，现实世界并不总是那么理想化。攻击者通常不知道这些东西是如何工作的，并且能够例如分析SPA确实有帮助，因为编写后端代码的人确实会犯错误。在其他情况下，API是公开的，并且无论如何都要记录在案，在这种情况下，拥有SPA不会带来进一步的风险。

如果您将SPA放在身份验证后面（只有经过身份验证的用户才能下载SPA代码），尽管我认为某些内容交付网络确实支持某种级别的身份验证，但这会使CDN访问变得非常复杂。

但是，在SPA之外有一个单独的（纯旧html）登录页面确实有好处。如果您在 SPA中有登录页面，则只能在javascript中获取访问令牌（会话ID，无论如何），这意味着javascript可以访问它，并且您只能将其存储在localStorage或普通的非httpOnly中曲奇饼。这很容易导致身份验证令牌通过跨站点脚本（XSS）被盗。一个更安全的选择是拥有一个单独的登录页面，该页面将身份验证令牌设置为httpOnly cookie，任何javascript都无法访问它，因此可以安全地使用XSS。请注意，尽管这样做会带来CSRF的风险，而您将不得不面对CSRF的风险，这与令牌/会话ID作为请求标头的形式发送来的相反。

在许多情况下，可以在SPA中进行登录并将身份验证令牌存储在localStorage中，但这是明智的决定，并且您应该意识到这种风险（在其他情况下，XSS与CSRF相比）。