网络安全csrf和xss_网络安全10 — CSRF

最新推荐文章于 2024-08-02 10:57:12 发布

weixin_26722031

最新推荐文章于 2024-08-02 10:57:12 发布

阅读量174

点赞数

原文链接：https://medium.com/swlh/web-security-10-csrf-b91c3d0c370e

版权

网络安全csrf和xss

1个简介 (1 Intro)

CSRF, Cross Site Request Forgery, is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request.

CSRF ( 跨站点请求伪造 )是一种攻击，它迫使最终用户在当前已通过身份验证的Web应用程序上执行不需要的操作。 CSRF攻击专门针对状态更改请求而不是数据盗窃，因为攻击者无法看到对伪造请求的响应。

2复核推荐人样本 (2 Review Referrer Sample)

In Web Security 02 — Referrer, we have given a simple example of How referrer can avoid basic attack. Actually, that sample is some kind of CSRF attack. Malicious website runs on 8889, and our blog system runs on 8888. There is an API in our blog system /api/transferPoints?dstUser=xxx. When called after authenticated, it will transfer points to dstUser xxx.

在Web Security 02-Referrer中，我们给出了一个简单的示例，referrer如何避免基本攻击。实际上，该样本是某种CSRF攻击。恶意网站运行在8889上，我们的博客系统运行在/api/transferPoints?dstUser=xxx 。我们的博客系统/api/transferPoints?dstUser=xxx有一个API。验证后调用时，它将转移点到dstUser xxx 。

Below is the operations when user is not authenticated. It won’t cause any point loss.

以下是用户未认证时的操作。它不会造成任何积分损失。

But if a user is currently authenticated, points will be transferred after unconsciously click on the malicious link.

但是，如果用户当前已通过身份验证，则在不自觉地单击恶意链接后将转移积分。

You can try this by checkout the 10CSRF branch, and run:

您可以通过签出10CSRF分支来尝试此10CSRF ，然后运行：

npm i
npm start
npm run-script startHack

3如何避免CSRF攻击 (3 How to avoid CSRF attack)

Use only JSON APIs : AJAX calls use JavaScript and are CORS-restricted. There is no way for a simple <form> to send JSON, so by accepting only JSON, you eliminate the possibility of the above form.
仅使用JSON API ：AJAX调用使用JavaScript，并且受CORS限制。一个简单的<form>无法发送JSON ，因此仅接受JSON即可消除上述形式的可能性。
Disable CORS : The first way to mitigate CSRF attacks is to disable cross-origin requests. If you’re going to allow CORS, only allow it on OPTIONS, HEAD, GET as they are not supposed to have side-effects. Unfortunately, this does not block the above request as it does not use JavaScript (so CORS is not applicable).
禁用CORS ：缓解CSRF攻击的第一种方法是禁用跨域请求。如果您要允许CORS，请仅在OPTIONS, HEAD, GET上允许它OPTIONS, HEAD, GET因为它们不具有副作用。不幸的是，这不会阻止上述请求，因为它不使用JavaScript(因此CORS不适用)。
Check the referrer header : Unfortunately, checking the referrer header is a pain in the ass, but you could always block requests whose referrer headers are not from your site. This really isn’t worth the trouble. For example, you could not load sessions if the referrer header is not your server.
检查引荐来源标头 ：不幸的是，检查引荐来源标头是一件麻烦事，但是您始终可以阻止那些引荐来源标头不是来自您站点的请求。这确实不值得麻烦。例如，如果引荐来源标头不是您的服务器，则无法加载会话。
GET should not have side effects : Make sure that none of your GET requests change any relevant data in your database. This is a very novice mistake to make and makes your app susceptible to more than just CSRF attacks.
GET应该没有副作用 ：确保没有任何GET请求更改数据库中的任何相关数据。这是一个非常新手的错误，不仅使您的应用更容易遭受CSRF攻击。
Avoid using POST : Because <form> s can only GET and POST, by using other methods like PUT, PATCH, and DELETE, an attacker has fewer methods to attack your site.
避免使用POST ：由于<form>只能进行GET和POST ，因此通过使用PUT ， PATCH和DELETE类的其他方法，攻击者可以利用较少的方法来攻击您的站点。
Don’t use method override! : Many applications use method-override to use PUT, PATCH, and DELETE requests over a regular form. This, however, converts requests that were previously invulnerable vulnerable! Don’t use method-override in your apps - just use AJAX!
不要使用方法重写！ ：许多应用程序使用method-override方法以常规形式使用PUT ， PATCH和DELETE请求。但是，这将转换以前不可攻击的请求！不要在应用程序中使用method-override -只需使用AJAX！
Don’t support old browsers : Old browsers do not support CORS or security policies. By disabling support for older browsers (which more technologically-illiterate people use, who are more (easily) attacked), you minimize CSRF attack vectors.
不支持旧版浏览器 ：旧版浏览器不支持CORS或安全策略。通过禁用对较旧的浏览器(技术较不熟练的人使用，容易(容易)攻击的浏览器)的支持，可以最小化CSRF攻击向量。
CSRF Tokens : Alas, the final solution is using CSRF tokens. How do CSRF tokens work? 1) Server sends the client a token. 2) Client submits a form with the token. 3) The server rejects the request if the token is invalid. An attacker would have to somehow get the CSRF token from your site, and they would have to use JavaScript to do so. Thus, if your site does not support CORS, then there’s no way for the attacker to get the CSRF token, eliminating the threat. Make sure CSRF tokens can not be accessed with AJAX! Don’t create a /csrf route just to grab a token, and especially don't support CORS on that route!
CSRF令牌 ：las，最终的解决方案是使用CSRF令牌。 CSRF令牌如何工作？ 1)服务器向客户端发送令牌。 2)客户提交带有令牌的表格。 3)如果令牌无效，服务器将拒绝该请求。攻击者必须以某种方式从您的站点获取CSRF令牌，并且他们必须使用JavaScript来这样做。因此，如果您的站点不支持CORS，则攻击者无法获取CSRF令牌，从而消除了威胁。 确保CSRF令牌不能用AJAX访问！ 不要仅为了获取令牌而创建/csrf路由，尤其不要在该路由上支持CORS！

Reference: Helmetjs, pillarjs

参考： Helmetjs ， boundaryjs

4解决方案样本 (4 Sample of fix solutions)

So there are many fix solutions:

因此，有许多解决方案：

1). Check change referrer : Web Security 02 — Referrer

1)。 检查更改引荐来源 ： Web安全02- 引荐来源

2). Disable CORS : Web Security 11 — CORS

2)。 禁用CORS ：网络安全11 — CORS

3). Change this API to post instead of using get, as this API will cause backend changes

3)。 将此API更改为post而不是使用get ，因为此API会导致后端更改

4). CSRF Tokens

4)。 CSRF代币

Now we will fix this problem in solution 3 and 4.

现在，我们将在解决方案3和4中解决此问题。

4.1将此API更改为post而不是使用get (4.1 Change this API to post instead of using get)

First let’s update our API from get to post. In backend indexPost.js , we change API from get to post (read from body instead of query ):

首先，让我们从get到post更新我们的API。在后端indexPost.js ，我们将API从get更改为post (从body读取而不是query )：

Also, we need to update UI as well (Ajax from get to post ):

另外，我们还需要更新UI(从get到post Ajax)：

Start the app again:

再次启动应用程序：

npm run-script startHack
npm run-script startPost

When we click the malicious get URL , nothing happens because this is a post request.

当我们单击恶意的获取URL时，什么也没有发生，因为这是一个发布请求。

However, hackers can also update their methods. Let’s also have an example:

但是，黑客也可以更新其方法。让我们举个例子：

Malicious guys can work around this!

恶意人员可以解决此问题！

4.2 CSRF代币 (4.2 CSRF Tokens)

The point of CSRF tokens is that, we will use another token to verify the user’s identity. And for each post request, which could do modification to our backend, we will check CSRF token and refresh it. Many people think it is not necessary to refresh them every time. But we won’t talk about that here. We will only give a simple example.

CSRF令牌的要点是，我们将使用另一个令牌来验证用户的身份。对于每个可以修改我们后端的发布请求，我们将检查CSRF令牌并刷新它 。许多人认为没有必要每次都刷新它们。但是，我们这里不再谈论。我们只会举一个简单的例子。

Now every time, if a user logged, we will put a CSRF token in the session, and we will stored it. When we use post method in UI, backend will verify the token in session and from post body. If verified OK, we will refresh this token. And if not, we will redirect user to login page.

现在，每次用户登录时，我们都将CSRF令牌放入session中 ，并将其存储。当我们在UI中使用post方法时，后端将在会话中和post正文中验证令牌。如果验证通过，我们将刷新此令牌。如果没有，我们会将用户重定向到登录页面。

Now in our indexCSRF.js , we add CRF related functions:

现在在我们的indexCSRF.js ，添加与CRF相关的功能：

When we first logon, if everything is OK, we will set CSRF. When user calls transferPoints, we check CSRF:

首次logon ，如果一切正常，将设置CSRF。当用户调用transferPoints ，我们检查CSRF：

What about UI? We should first store the token. staticFileSafeCSRF/index.html :

UI呢？我们应该先存储令牌。 staticFileSafeCSRF/index.html ：

And when we do post, we should do more things staticFileSafeCSRF/post.js :

当我们发布时，我们应该做更多的事情staticFileSafeCSRF/post.js ：

And now, start applications:

现在，启动应用程序：

npm run-script startCSRF
npm run-script startHack

Yeah, even malicious post requests can’t success any more.

是的，即使是恶意的发布请求也无法成功。

Where is the code:

代码在哪里：

What is this place? Princess Margaret Bridge, Fredericton, NB, Canada.

这是什么地方？ 加拿大新罕布什尔州弗雷德里克顿玛格丽特公主桥。

翻译自: https://medium.com/swlh/web-security-10-csrf-b91c3d0c370e

网络安全csrf和xss

weixin_26722031

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
复制链接

分享到 QQ

分享到新浪微博

扫一扫