保护SPA后面的REST API免受数据窃贼的侵害 [英] Protecting REST API behind SPA against data thiefs

问题描述

我正在为Angular SPA编写REST Api网关，但是我面临着针对数据窃贼"保护SPA API公开的数据的问题.我知道我不能对HTML抓取做很多事情，但是至少我不想为这样的数据窃贼提供用户体验以及发送到SPA的JSON的全部功能.

I am writing a REST Api gateway for an Angular SPA and I am confronted with the problem of securing the data exposed by the API for the SPA against "data thiefs". I am aware that I can't do much against HTML scraping, but at least I don't want to offer such data thiefs the user experience and full power of our JSON sent to the SPA.

关于该主题的大多数教程"和主题之间的区别是，我将这些数据公开到一个公共网站(这意味着不需要用户身份验证)，该网站提供了有关视频游戏的有价值的统计信息.

The difference between most "tutorials" and threads about this topic is that I am exposing this data to a public website (which means no user authentication required) which offers valuable statistics about a video game.

关于如何保护用于SPA的Rest API的初步想法:

在任何地方都使用JWT.当访客首次打开网站时，SPA第一次从我的REST Api请求JWT并将其保存在HTTPS cookie中.对于所有请求，SPA必须使用JWT来获得响应.

Using JWTs everywhere. When a visitor opens the website the very first time the SPA requests a JWT from my REST Api and saves it in the HTTPS cookies. For all requests the SPA has to use the JWT to get a response.

该方法存在的问题

• 数据窃贼也可以简单地从我们的端点请求oauth令牌.我没有机会验证是否实际上已从我的SPA或数据小偷中请求了令牌?
• 即使我解决了攻击者可以从HTTPS cookie中读取保存的JWT并将其用于他自己的应用程序中的问题.当然，我可以为JWT添加时间到期

我的问题:

我觉得这是一个普遍的问题，因此我想知道，除了可以直接访问我的REST Api响应的SPA之外，还有什么好的解决方案可以防止其他人受到攻击?

I am under the impression that this is a common problem and therefore I am wondering if there are any good solutions to protect against others than the SPA having direct access to my REST Api responses?

推荐答案

从API的角度来看，您的SPA与任何其他客户端都没有什么不同.您显然不能在SPA中包含秘密，因为它会发送给任何人并且无法得到保护.同样，它对API的请求也可以很容易地被另一个客户端嗅探和复制.

From the API's point of view, your SPA is in no way different than any other client. You obviously can't include a secret in the SPA as it is sent to anybody and cannot be protected. Also the requests it makes to the API can be easily sniffed and copied by another client.

因此，简而言之，正如这里多次讨论的那样，您无法对客户端应用程序进行身份验证.任何人都可以根据需要创建其他客户端.

So in short, as diacussed many times here, you can't authenticate the client application. Anybody can create a different client if they want.

您可以实际要做的一件事是检查请求的引用/来源.如果客户端在浏览器中运行，则它可以发出的请求会受到一定程度的限制，其中一种限制是引用者和来源标头，它们始终由浏览器控制，而不是由javascript控制.因此，您实际上可以确保，如果(且仅当！)客户端在未修改的浏览器中运行，则将从您的域中下载该客户端.这是浏览器中的默认设置，因此，如果您不发送CORS标头，那么您已经做到了(实际上，浏览器可以做到).但是，这并不能阻止攻击者构建和运行非浏览器客户端并伪造他喜欢的任何引荐来源或来源，或者只是忽略相同的来源策略.

One thing you can actually do is checking the referer/origin of requests. If a client is running in a browser, thr requests it can make are somewhat limited, and one such limitation is the referer and origin headers, which are always controlled by the browser, and not javascript. So you can actually make sure that if (and only if!) the client is running in an unmodified browser, it is downloaded from your domain. This is the default in browsers btw, so if you are not sending CORS headers, you already did this (browsers do, actually). However, this does not keep an attacker from building and running a non-browser client and fake any referer or origin he likes, or just disregard the same origin policy.

您可以做的另一件事是定期更改API，足以阻止流氓客户端正常工作(并同时更改客户端).显然，这根本不安全，但是对于攻击者来说可能会很烦人.如果您一次要下载所有数据，那么这再无济于事.

Another thing you could do is changing the API regularly just enough to stop rogue clients from working (and changing your client at the same time ofc). Obviously this is not secure at all, but can be annoying enough for an attacker. If downloading all your data once is a concern, this again doesn't help at all.

您应该考虑的一些真实事物是:

Some real things you should consider though are:

• 实际上有人要下载您的数据吗?这个值多少钱?在大多数情况下，没有人希望创建其他客户端，也没有人对数据如此感兴趣.

• Does anybody actually want to download your data? How much is it worth? Most of the times nobody wants to create a different client, and nobody is that much interested in the data.

如果很有趣，则您至少应实施用户身份验证，并通过合法的合同下方和/或合同中的规定承担其余的风险.

If it is that interesting, you should implement user authentication at the very least, and cover the remaining risk either via points below and/or in your contracts legally.

您可以实施限制以不允许批量下载.例如，如果典型用户每5秒访问1条记录，而总共访问10条记录，则可以基于客户端IP构建规则，例如以合理地限制用户访问.请注意，尽管速率限制必须基于客户端无法随意修改的参数，并且没有身份验证，但这几乎只能是客户端IP，并且您将面对NAT背后的用户(例如，公司网络)的问题.

You could implement throttling to not allow bulk downloading. For example if the typical user accesses 1 record every 5 seconds, and 10 altogether, you can build rules based on the client IP for example to reasonably limit user access. Note though that rate limiting must be based on a parameter the client can't modify arbitrarily, and without authentication, that's pretty much the client IP only, and you will face issues with users behind a NAT (ie. corporate networks for example).

类似地，您可以实施监视，以发现某人正在下载的数据是否超出正常或必要的数量.但是，如果没有用户身份验证，唯一的选择就是禁止客户端IP.因此，再次取决于知道用户是谁.身份验证.

Similarly, you can implement monitoring to discover if somebody is downloading more data than it would be normal or necessary. However, without user authentication, your only option will be to ban the client IP. So again it comes down to knowing who the user is, ie. authentication.

这篇关于保护SPA后面的REST API免受数据窃贼的侵害的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！