在持久Cookie REST Api网站/移动应用程序上实现的安全性

Question

所以我目前的状态是我有一个REST API web服务器（ASP.Net web API），一个纯Html的网站，它通过ajax/angular post和get与服务器通信，我还有一个移动应用程序，它通过ajax/angular post和get通信。

我使用基本认证头来保护请求，网络服务器将解密认证头的内容并在之后进行验证。

系统容易受到什么样的攻击？还有，我应该实现什么样的安全性。

我读了关于CSRF攻击的文章，我认为我的系统没有针对它的保护，但是我不知道如何在REST API上实现它。

还有偷饼干攻击。因为我的系统使用持久cookie来存储授权令牌，如何处理这种攻击？

Answer 1

我真的不知道答案，但我发现这个网站涵盖了几乎所有类型的攻击
https://www.hacksplaining.com/lessons

Answer 2

为了防止CSRF攻击，必须将后端（ASP.NET Web API）和前端（Angular）都配置为防止此类攻击。

取自https://angular.io/guide/security#xsrf:

为了防止XSRF，应用程序必须确保用户请求来自真正的应用程序，而不是来自不同的站点。服务器和客户端必须合作阻止此攻击。

在常见的反XSRF技术中，应用服务器[后端]在cookie中发送随机生成的身份验证令牌。客户端代码读取cookie，并在所有后续请求中添加带有令牌的自定义请求标头。服务器将接收到的cookie值与请求标头值进行比较，如果这些值缺失或不匹配，则拒绝请求。

这种技术非常有效，因为所有浏览器都实现相同的源策略。只有设置Cookie的网站上的代码才能读取该网站上的Cookie，并在对该网站的请求上设置自定义标题。这意味着只有您的应用程序才能读取此cookie令牌并设置自定义头。关于邪恶的恶意代码。com不能。

考虑到这一点，这里有另一个来自Angular HttpClient文档的引用，它解释了如何实现它。

取自https://angular.io/guide/http#security-xsrf-protection：

在执行HTTP请求时，拦截器从cookie中读取令牌（默认为XSRF-token），并将其设置为HTTP头X-XSRF-token。由于只有在您的域上运行的代码才能读取cookie，因此后端可以确定HTTP请求来自您的客户端应用程序，而不是攻击者。

默认情况下，拦截器在所有变异请求（POST等）上发送此标头。）到相对URL，但不是在GET/HEAD请求或具有绝对URL的请求上。

您的服务器需要在页面加载或第一个GET请求上在名为XSRF-TOKEN的JavaScript可读会话cookie中设置令牌。在随后的请求中，服务器可以验证cookie是否匹配X-XSRF-TOKEN HTTP标头，因此确保只有在域上运行的代码才能发送请求。令牌对于每个用户必须是唯一的，并且必须可以由服务器验证；这可以防止客户端创建自己的令牌。将令牌设置为网站身份验证cookie的摘要，并添加盐以增加安全性。

需要注意的要点是：

1. 加载angular应用程序时，它应该首先对后端进行API调用，以检索保存为名为“XSRF-token”的cookie的身份验证令牌。可能是根组件（app.component.ts）上的某个地方，ngOnInit（）听起来是个不错的地方
2. 默认情况下，身份验证令牌将自动注入所有变化请求（如POST）的http头中。（注意这一点，它是未记录的：Angular 6没有向http请求添加X-XSRF-TOKEN头）。除非返回一个自定义的命名cookie，否则必须使用Angular的HttpClientXsrfModule
3. 考虑到这一点，您的ASP。NET Web API还应该在XSRF-TOKEN接收请求时验证它

关于你的第二个问题，cookie劫持是通过XSS完成的。

XSS漏洞通常发生在应用程序接受用户输入并将其输出到页面而不进行验证、编码或转义时。

Angular默认情况下会清除标记的输入。然而，这是假设你做事情的“角度的方式”。如果您使用第三方库（如jQuery）来操作DOM，而不是使用Angular的renderer2模块，您可能会失去这种保护。

摘自：https://angular.io/guide/security#xss:

同样，如果与操作DOM的其他库交互，则可能不会像角度插值那样进行自动清理。避免直接与DOM交互，而是尽可能使用角度模板。

对于不可避免的情况，请使用内置的角度消毒功能。使用DomSanitizer清理不受信任的值。清理方法和相应的SecurityContext。

为了提高安全性，您还应该清理后端中的任何变异请求（如PUT或POST）。

很难向您提供代码示例，因为您的问题似乎是一个更基于理论的问题。

我希望你能阅读我上面的超链接。它们肯定更详细，解释得也更清楚。我希望它至少能为你指明正确的开始方向。