基础安全:CSRF攻击原理与防范-Toy模板网

这篇具有很好参考价值的文章主要介绍了基础安全:CSRF攻击原理与防范。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

CSRF的概念

CSRF（Cross-Site Request Forgery）中文名为“跨站请求伪造”。这是一种常见的网络攻击手段，攻击者通过构造恶意请求，诱骗已登录的合法用户在不知情的情况下执行非本意的操作。这种攻击方式利用了Web应用程序中用户身份验证的漏洞，即浏览器在用户完成登录后会自动携带相关的认证信息（如Cookie、Authorization header等）发送给服务器，使得服务器误以为请求来自已授权的用户。

这种攻击手段其实很常见，因此有必要了解他得到原理以及相对的防范措施。

基础安全:CSRF攻击原理与防范,后端,安全,csrf,网络,后端

基于上面的概念描述，CSRF攻击带来的影响可以总结为下面三点:

在成功的 CSRF 攻击中，攻击者会导致受害用户无意中执行操作。例如，这可能是更改其帐户上的电子邮件地址、更改密码或进行资金转账。
根据操作的性质，攻击者可能能够完全控制用户的帐户。
如果受感染的用户在应用程序中具有特权角色，则攻击者可能能够完全控制应用程序的所有数据和功能。

CSRF距离我们并不遥远，以下是一些著名的 CSRF 攻击的示例。

TikTok ——2020 年，字节跳动收到了有关漏洞的报告，该漏洞允许攻击者向 Tiktok 用户发送包含恶意软件的消息。部署恶意软件后，攻击者可以执行 CSRF 或跨站脚本 (XSS) 攻击，导致其他用户帐户代表他们向 TikTok 应用程序提交请求。 TikTok 在三周内修复了该漏洞。

McAfee — 2014 年，Check Point 研究人员在企业安全产品 McAfee Network Security Manager 的用户管理模块中发现了 CSRF 漏洞。该攻击允许恶意用户修改其他用户帐户。该漏洞已在8.1.7.3版本中修复。

YouTube - 2008 年，普林斯顿大学的研究人员在 YouTube 上发现了一个 CSRF 漏洞，该漏洞允许攻击者代表任何用户执行几乎所有操作，包括将视频添加到收藏夹、修改朋友/家人列表、向用户的联系人发送消息以及标记不当行为内容。该漏洞立即得到修复。

ING Direct — 2008 年，一家荷兰跨国银行集团的银行网站 ING Direct 存在 CSRF 漏洞，攻击者可以利用该漏洞从用户帐户中转移资金，即使用户已通过 SSL 进行身份验证。该网站没有任何针对 CSRF 攻击的保护，并且转移资金的过程很容易被攻击者看到和复制。

CSRF是如何工作的

要执行CSRF攻击，需要具备一些基础的必要条件:

用户已认证的会话：攻击者需要利用目标网站上已经认证的用户会话。这意味着用户在目标网站上已经登录并且会话仍然有效。
目标网站缺乏CSRF保护：目标网站没有足够的CSRF防护措施，比如缺乏CSRF令牌（Token）或其他验证机制来确保请求的合法性。
攻击者能够构造恶意请求：攻击者需要能够构造包含恶意操作的请求，并将其嵌入到诱导用户访问的页面或链接中。
用户受到诱导：攻击者需要诱导用户点击包含恶意请求的链接或访问包含恶意代码的页面，从而触发恶意请求的发送。
用户浏览器执行请求：用户的浏览器需要执行恶意请求，发送请求到目标网站，而目标网站会误以为这是用户自己发起的合法请求。

基础安全:CSRF攻击原理与防范,后端,安全,csrf,网络,后端

以经典的银行站点的CSRF为例：

攻击者物色要下手的银行站点，比如www.banking.com

这些网站都有一些主要的特征，比如包含敏感信息的请求通过get进行明文传输，而且容易推测出一定的规律；

基础安全:CSRF攻击原理与防范,后端,安全,csrf,网络,后端

这是一个阳光明媚的好日子，万里无云，心情愉悦，用户哼着小曲儿兴高采烈的通过下面的请求地址登录了自己的账户并给小老婆转账520000，成功登录后在浏览器上留下了Cookie记录
```
banking.com/transfer?amount=520000&toAccount=attackerAccountId
```
1. 攻击者针对性的准备一些含有恶意链接的地址并加以美化封装，再通过社会工程学，利用用户的无知贪婪或者好奇心理诱导他们点击这个含有恶意URL的东西，比如将上面的转账地址添加到一张看似平平无奇的图片中。
```
<img src="bank.com/transfer?amount=100&to=AttackerAccount" />。
```
  在这种情况下，攻击者创建了一个网站，该网站在页面加载时自动提交表单。用户只需访问该网站即可发送此请求。
2. 攻击者可以利用用户的cookies和session向银行的服务器发出合法的请求。资金通常在用户不知情的情况下在表演了一次凭空消失术，与此同时，也触发了另外一个故事…

CSRF 防范

CSRF Token（令牌）：在每个请求中包含一个随机生成的 CSRF 令牌，并在服务器端验证该令牌的有效性。攻击者无法获取有效的令牌，因此无法成功发起 CSRF 攻击。
SameSite Cookie 属性：设置 Cookie 的 SameSite 属性为Strict或Lax，可以阻止跨站点请求伪造。Strict 模式完全禁止第三方 Cookie，而 Lax 模式限制第三方 Cookie 仅在 GET 请求时发送。
验证 Referer 头部：在服务器端验证请求的 Referer 头部，确保请求来源于合法的网站。然而，Referer 头部并不总是可靠，因此不应完全依赖于它来防范 CSRF 攻击。
双重提交 Cookie（Double Submit Cookie）：将 CSRF 令牌存储在 Cookie 和表单字段中，并在服务器端比较这两个值。攻击者无法在跨域请求中访问到 Cookie 中的内容，因此无法成功伪造请求。
使用安全的 HTTP 头部：设置安全的 HTTP 头部，如X-Content-Type-Options、X-Frame-Options、Content-Security-Policy 等，可以增强网站的安全性，降低 CSRF 攻击的风险。
限制敏感操作：对于涉及敏感操作的请求（如修改密码、转账等），应该要求用户进行额外的身份验证，例如输入密码、验证码等。
定期审查和更新代码：定期审查代码，确保实施了最佳的安全实践，并及时更新依赖库以修复已知的安全漏洞。