保护 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.

我对如何保护 Rest API for SPA 的初步想法:

在任何地方都使用 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 添加过期时间

我的问题:

我的印象是这是一个常见问题，因此我想知道除了 SPA 直接访问我的 REST Api 响应之外，是否有任何好的解决方案来防止其他人?

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.

您可以真正做的一件事是检查请求的引用者/来源.如果客户端在浏览器中运行，它可以发出的 thr 请求会受到一定限制，其中一个限制是referer 和 origin 标头，它们始终由浏览器控制，而不是 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屋！