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

Question

所以我目前的状态是我有一个 REST API 网络服务器(ASP.Net Web API)，一个纯 Html 的网站，它通过 ajax/angular post 和 get 与服务器通信，我还有一个移动应用程序，它通过ajax/ Angular 发布和获取。

我使用Basic Auth header来保护请求，web服务器将解密auth header的内容并在之后进行验证。

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

我读到了有关 CSRF 攻击的信息，我认为我的系统没有针对它的保护措施，但我不知道如何在 REST API 上实现它。

还有 cookie 窃取攻击。因为我的系统使用持久性 cookie 来存储身份验证 token ，如何应对这种攻击？

Answer 1

为防止 CSRF 攻击，您的后端 (ASP.NET Web API) 和前端 (Angular) 都必须配置为防止此类攻击。

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

To prevent XSRF, the application must ensure that a user request originates from the real application, not from a different site. The server and client must cooperate to thwart this attack.

In a common anti-XSRF technique, the application server [backend] sends a randomly generated authentication token in a cookie. The client code reads the cookie and adds a custom request header with the token in all subsequent requests. The server compares the received cookie value to the request header value and rejects the request if the values are missing or don't match.

This technique is effective because all browsers implement the same origin policy. Only code from the website on which cookies are set can read the cookies from that site and set custom headers on requests to that site. That means only your application can read this cookie token and set the custom header. The malicious code on evil.com can't.

考虑到这一点，这是 Angular HttpClient 文档中的另一段引述，它解释了如何实现它。

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

When performing HTTP requests, an interceptor reads a token from a cookie, by default XSRF-TOKEN, and sets it as an HTTP header, X-XSRF-TOKEN. Since only code that runs on your domain could read the cookie, the backend can be certain that the HTTP request came from your client application and not an attacker.

By default, an interceptor sends this header on all mutating requests (POST, etc.) to relative URLs but not on GET/HEAD requests or on requests with an absolute URL.

your server needs to set a token in a JavaScript readable session cookie called XSRF-TOKEN on either the page load or the first GET request. On subsequent requests the server can verify that the cookie matches the X-XSRF-TOKEN HTTP header, and therefore be sure that only code running on your domain could have sent the request. The token must be unique for each user and must be verifiable by the server; this prevents the client from making up its own tokens. Set the token to a digest of your site's authentication cookie with a salt for added security.

需要注意的要点是:

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

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

XSS vulnerabilities generally occur when an application takes user input and outputs it to a page without validating, encoding or escaping it.

Angular 默认清理标签的输入。但是，前提是您以“Angular 方式”做事。如果您使用第三方库(例如 jQuery)来操作 DOM 而不是使用 Angular 的 renderer2 模块，您可能会失去这种保护。

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

In the same way, if you interact with other libraries that manipulate the DOM, you likely won't have the same automatic sanitization as with Angular interpolations. Avoid directly interacting with the DOM and instead use Angular templates where possible.

For cases where this is unavoidable, use the built-in Angular sanitization functions. Sanitize untrusted values with the DomSanitizer.sanitize method and the appropriate SecurityContext.

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

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

我希望您能阅读我在上面添加超链接的那些链接。它们肯定更详细，解释得更清楚。我希望它至少能为您指出正确的入门方向。