防止CSRF和XSS（哈希+加密） [英] Protection against CSRF and XSS (Hashing + Encrypting)

问题描述

安全性。如今，如果没有为应用程序编程适当的安全性，则任何应用程序都无法在Internet上生存下来-无论是开发人员使用的框架，还是开发人员自己使用的框架。我目前正在开发一个RESTful API，以使用Bearer令牌身份验证来工作，但是一直在阅读有关XSS和CSRF攻击的信息。

问题1）根据我的阅读，我发现使用RESTful API且使用基于令牌的身份验证的RESTful API的应用程序容易受到XSS和 not CSRF（如果令牌存储在浏览器的localStorage / sessionStorage中，而不是cookie中）。这是因为，要使CSRF正常运行，应用程序必须使用cookie。我正确吗？

但是现在令牌已存储在localStorage / sessionStorage中，该应用程序容易受到XSS攻击。如果应用程序中有任何部分不清除输入（例如，Angular输入已由框架清除，但是我正在使用的某个第三方库默认情况下未清除输入），则攻击者可以注入恶意代码代码来窃取其他用户的令牌，然后通过模拟它们来发出经过身份验证的请求。

问题2）有一种方法可以防止这两种攻击使用RESTful API的应用程序中的这些攻击。我遇到了 此帖子 。该文章的要旨是，在用户登录并请求承载令牌时，让服务器还返回一个 httpOnly cookie，该cookie的作用例如是 CSRFProtectionCookie 。我相信本文中的解决方案非常强大，并提供了强大的保护。再说一次，我正确吗？您的看法是什么？

我的应用程序和上面帖子中提到的方法的版本

方法上面的帖子中提到的要求我将 CSRFProtectionCookie 保留在某种数据库中。我不想那样做。我不希望每次对API进行身份验证的请求都被击中。相反，我能做的是这样：

登录

1. 用户使用用户名和密码将POST请求发送到令牌端点


2. 授权服务器验证用户凭据并开始构建具有某些声明的JWT。


3. 作为JWT构建的一部分，它还会生成一个随机字符串，哈希，并将其添加为对JWT的声明，例如 csrf 。


4. 此外，接下来，服务器设置一个名为 XSRF-TOKEN httpOnly cookie。 >其值是相同的随机字符串，但这次被加密。


5. 将响应返回到浏览器。浏览器将获取令牌作为响应主体，并设置了 XSRF-TOKEN cookie。

经过身份验证的请求

1. 应用程序通过将JWT承载令牌添加为来调用经过身份验证的端点 Authorization 标头。浏览器会自动发送cookie。




2. 服务器解密cookie以获取纯文本。然后，服务器使用JWT中存在的哈希验证该纯文本。




3. 如果匹配，则继续进行请求。否则，返回未经授权的响应。

我认为这可以防止CSRF和XSS。

问题是必需的，因为令牌和cookie（httpOnly）都是必需的。

问题 （或者是？我是否缺少漏洞？）。但是，在每个用户请求上解密和验证哈希的开销是多少？它比数据库I / O的开销更大吗？另外，欢迎对此方法或其他方法提出任何其他建议！

谢谢：）

解决方案

如果您使用的是承载身份验证，那么任何攻击者都无法使用CSRF，因为它们没有令牌值。浏览器不会自动将其添加到请求中，因此它本质上可以抵御CSRF。请参见此处有关CSRF以及自定义标头如何缓解它的说明。承载身份验证以与在未启用CORS的情况下无法添加自定义标头的方式解决该问题，或者如果CORS处于活动状态（对于API常见），则针对API的身份验证是通过令牌值本身实现的，攻击者将不知道要提供的值（如果这样做，他们将直接使用不使用CSRF的值），并且浏览器将不会像提供基本身份验证，摘要等，cookie身份验证或证书一样自动提供身份验证身份验证。

要防止XSS，这是一个不同的问题，请确保所有HTML输出均经过HTML编码（> & gt; ）。如果API本身输出格式化的HTML，则可以在API本身中完成；如果要由使用者适当格式化输出，则可以在JavaScript中完成。 JavaScript内置了一些功能，例如JQuery的框架也可以提供帮助（例如 textContent 和> $$ c> text（） ）。

Security. Today, no application can survive the internet if it does not have proper security programmed into it - either by the framework used by the developer, or by the developer himself. I am currently developing a RESTful API to work using Bearer token authentication but have been reading about XSS and CSRF attacks.

Question 1) From what I've read, I see that applications consuming RESTful APIs that use token-based authentication are vulnerable to XSS and not CSRF if the token is stored in localStorage/sessionStorage of the browser instead of in cookies. This is because, for CSRF to work, the application must use cookies. Am I correct?

But now that the tokens are stored in the localStorage/sessionStorage, the application becomes vulnerable to XSS attacks. If there is any part of the application that does not sanitize inputs (E.g. Angular inputs are sanitized by the framework, but maybe a certain 3rd-party library I'm using is not sanitizing inputs by default), then an attacker can just inject malicious code to steal tokens of other users and then make authenticated requests by impersonating them.

Question 2) There is a way to protect against both of these attacks in your application that consumes a RESTful API. I came across this post. The gist of that article is that at the time of the user logging in and requesting a bearer token, have the server also return a httpOnly cookie that would act as, say, CSRFProtectionCookie. I believe the solution in the article is pretty robust and provides strong protection. Again, am I correct? What are your views?

My application and my version of the approach mentioned in the above post

The approach mentioned in the post above requires me to persist the CSRFProtectionCookie in a database of some sort. I do not want to do that. I do not want the database to be hit every time a authenticated request is made to the API. Instead, what I can do is this:

Login

1. User sends POST request to token endpoint with username and password
2. Authorization server validates user credentials and starts building JWT with certain claims.
3. As part of JWT-building, it also generates a random string, hashes it, and adds it as a, say, csrf claim to the JWT.
4. Also, next the server sets a httpOnly cookie named XSRF-TOKEN whose value is the same random string but encrypted this time.
5. Return the response to the browser. Browser gets both the bearer token as the response body and the XSRF-TOKEN cookie is set.

Authenticated requests

1. Application calls authenticated endpoints by adding the JWT bearer token as the Authorization header. Browser automatically sends along the cookie.

2. Server decrypts the cookie to get plain text. Server then verifies this plain text with the hash present in the JWT.

3. If matched, proceed with request. Else, return Unauthorized response.

I think this gives protection against both CSRF and XSS. As both the token and cookie (httpOnly) is required to make authenticated requests.

Question Yes this eliminates the need to persist anything to the database (or does it? Am I missing some loophole?). But what is the overhead of decrypting and verifying hashes on every user request? Is it more overhead than database I/O? Also, any other suggestions to this approach or other approaches are welcome!

Thanks :)

解决方案

If you are using bearer authentication then CSRF is not possible by any attacker as they don't have the token value. It won't automatically be added by the browser to requests, therefore it is inherently secure against CSRF. See here for an explanation of CSRF and how a custom header can mitigate it. Bearer authentication solves the problem in the same way as the custom header cannot be added without CORS being enabled, or if CORS is active (which is common for an API), then as authentication against the API is achieved with the token value itself, any attacker will not know the value to provide (if they did they would simply use the value directly without CSRF), and the browser will not automatically supply the authentication in the same way it would for basic authentication, digest, etc, cookie authentication or certificate authentication.

For protection against XSS, which is a different issue, ensure all HTML output is HTML encoded (> becomes >). This could be done in the API itself if it outputs formatted HTML, or in JavaScript if it is up to the consumer to format output appropriately. There are functions built into JavaScript and frameworks like JQuery that can also help (e.g. textContent and text()).

这篇关于防止CSRF和XSS（哈希+加密）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！