将登录页面包含在单页应用程序中是否不安全? [英] Is it insecure to include your login page in your single page application?

问题描述

我的理解是，如果您将登录页面包含在SPA中，那么用户将在验证所有代码之前就收到您的所有代码.但是，这似乎是非常普遍的做法.这不是令人难以置信的不安全吗?为什么或为什么不呢?

My understanding is that, if you include your login page in your SPA, then the user is receiving all of your code before they're even authenticated. And yet, it seems to be a very common practice. Isn't this incredibly insecure?? Why or why not?

推荐答案

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

An SPA would have all the page structures (html and javascript code for the design of pages), but obviously not data. Data would be downloaded in subsequent ajax requests, and that is the point. To download actual data, a user would have to be authenticated to the server, and all security would then be implemented server-side. An unauthorized user should not be able to access data from the server. But the idea is that how pages look is not a secret, anybody can have a look at pages of the SPA without data, and that's fine.

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

Well, and here comes the catch that people often overlook. Html is one thing, but there is all the javascript in an SPA that can access all the data. Basically the code of the SPA is an API documentation if you like, a list of possible queries that the backend can handle. Sure, it should all be secure server-side, but that's not always the case, people make mistakes. With such a "documentation" that an SPA is, it can be much easier for an attacker to evaluate server-side security and find authorization / access-control flaws in server-side code which may enable access to data that should not be accessible to the attacker.

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

So in short, having access to how pages look (without data) should be ok. However, giving away how exactly the API works can in certain scenarios help an attacker, and therefore adds some risk, which is inherent to SPAs.

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

It must be noted though that it should not matter. As security by obscurity should not be used (ie. it should not be a secret how things work, only things like credentials should be secrets), it should be fine to let anyone know all the javascript, or the full API documentation. However, the real world is not always so idealistic. Often attackers don't know how stuff works, and it can be of real help to be able to for example analyze an SPA, because people that write the backend code do make mistakes. In other cases the API is public and documented anyway, in which case having an SPA presents no further risk.

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

If you put the SPA behind authentication (only authenticated users can download the SPA code), that complicates CDN access a lot, though some content delivery networks do support some level of authentication I think.

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

Yet there is a real benefit of having a separate (plain old html) login page outside the SPA. If you have the login page in the SPA, you can only get an access token (session id, whatever) in javascript, which means it will be accessible to javascript, and you can only store it in localStorage, or a plain non-httpOnly cookie. This may easily result in the authentication token being stolen via cross-site scripting (XSS). A more secure option is to have a separate login page, which sets the authentication token as a httpOnly cookie, inaccessible to any javascript, and as such, safe from XSS. Note though that this brings the risk of CSRF, which you wil lhave to deal with then, as opposed to the token/session id being sent as something like a request header.

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

In many cases, having the login in the SPA and storing the authentication token in localStorage is acceptable, but this should be an informed decision, and you should be aware of the risk (XSS, vs CSRF in the other case).

这篇关于将登录页面包含在单页应用程序中是否不安全?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！