代码之家 › 专栏 › 技术社区 › kentor

保护SPA背后的REST API免受数据盗窃

restful-authentication jwt security rest

kentor · 技术社区 · 6 年前

我正在为一个角度SPA编写一个REST Api网关,我面临着保护SPA的Api所公开的数据不受“数据盗窃”影响的问题。我知道我不能做太多的反对HTML抓取,但至少我不想提供这样的数据盗窃用户体验和我们的JSON发送到SPA的全部能力。

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

我对如何保护SPA的Rest API的最初想法是:

到处使用JWTs。当访问者第一次打开网站时,SPA从我的REST Api请求JWT并将其保存在HTTPS cookies中。对于所有请求,SPA必须使用JWT来获得响应。

这种方法的问题

即使我解决了攻击者可以从HTTPS cookies中读取保存的JWT并在自己的应用程序中使用它的问题。当然我可以加上JWT的过期时间

我的问题是:

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

1 回复 | 直到 6 年前

Gabor Lengyel 6 年前

从API的角度来看,您的SPA与任何其他客户机都没有任何不同。显然,你不能在SPA中包含一个秘密,因为它是发送给任何人的,并且不能受到保护。另外,它对API的请求可以很容易地被另一个客户机嗅探和复制。

所以简而言之,正如这里多次讨论的那样,您不能对客户端应用程序进行身份验证。任何人都可以创建一个不同的客户,如果他们想的话。

有件事你实际上要做的是检查请求的referer/origin。如果客户机在浏览器中运行,它可以发出的thr请求会受到一定的限制,其中一个限制是referer和origin头,它们总是由浏览器控制,而不是javascript。所以你可以确定如果(并且只有当!)客户端正在未经修改的浏览器中运行,它是从您的域下载的。这是浏览器btw中的默认设置,所以如果您没有发送CORS头,那么您已经发送了(实际上浏览器确实发送了)。但是,这并不能阻止攻击者构建和运行非浏览器客户端,伪造他喜欢的任何引用或源,或者只是忽略同一源策略。

你可以做的另一件事是定期更改API,以阻止恶意客户端工作(并在ofc的同时更改客户端)。显然这根本不安全,但对于攻击者来说已经够烦人了。如果一次下载你所有的数据是一个问题,这再次没有任何帮助。

你应该考虑的是:

有人真的想下载你的数据吗?它值多少钱?大多数情况下,没有人想创建不同的客户机,也没有人对数据那么感兴趣。
是有意思的是,您至少应该实现用户身份验证,并通过以下几点和/或在您的合同中合法地覆盖剩余的风险。
类似地,您可以实现监视,以发现是否有人下载的数据超过了正常或必需的数据量。但是,如果没有用户身份验证,您唯一的选择是禁止客户端IP。所以这又归结为知道用户是谁,即身份验证。