漫谈网络安防之CSRF

Labs 导读

在当今数字化时代，漫谈随着网络应用的网络快速发展，网络安全问题变得日益突出 ，安防网络攻击手段也日益猖獗。漫谈在众多网络安全攻击手段中
，网络CSRF（跨站请求伪造）攻击是安防一种被广泛认为具有潜在危害且常见的攻击方式之一 。与其他攻击方式相比 ，漫谈CSRF 攻击不需要获取用户的网络敏感信息（如用户名和密码） ，而是安防利用了用户和网站之间的信任关系 ，使得攻击者可以在用户不知情的漫谈情况下执行未经授权的云计算操作 ，从而导致严重的网络后果
。

在本篇文章中，安防我们将剖析攻击者是漫谈如何利用用户身份和浏览器漏洞来实施CSRF攻击行为 ，通过深入了解这种攻击方式，网络探索防御这一攻击的安防最佳实践 ，为构建更加安全的网络环境做出贡献。

Part 01、  了解CSRF攻击

CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种常见的网络安全攻击方式，源码库它利用了网站对用户请求的信任机制。攻击者通过诱使用户在访问恶意网站或点击恶意链接时，发送伪造的请求到被用户信任（已登录）的目标网站 ，从而执行未经授权的操作。

CSRF攻击可能导致如下安全风险 ：

(1)资金损失 ：攻击者可以利用CSRF攻击进行非法的资金转移、支付操作 ，导致用户的资金受损 。

(2)恶意操作：攻击者可以以受害者的身份执行恶意操作 ，如修改账户密码 、源码下载删除重要数据等  ，给用户带来不便和损失。

CSRF攻击的基本原理如图所示：

(1)用户的身份验证：当用户A浏览并成功登录受信任网站B时，受信任网站B会为用户生成一个会话标识用于进行后续操作的身份验证 ，通常通过Cookie存储在用户的浏览器中 。

(2)用户访问恶意网站：攻击者制作一个恶意网站C，并诱使用户A访问。这可以通过发送欺骗性的电子邮件、社交媒体信息 、恶意广告等方式实现。

(3)恶意请求的模板下载发送
：当用户访问恶意网站C时 ，网站C会加载包含恶意请求的HTML代码。这些请求通常以图片、链接或表单的形式存在
，使浏览器在用户A无感知或未授权的情况下自动访问受信任网站B 。

(4)用户浏览器自动发送请求 ：由于用户A已经在受信任网站B上进行了身份验证，他们的浏览器会自动携带相应的身份验证凭证（Cookie） 。该行为为浏览器默认行为 。

(5)受信任网站的误判：用户A浏览器发送的请求因携带着用户的高防服务器身份验证凭证，被受信任网站B视为合法请求 ，并执行请求中指定的操作，使得恶意网站C的攻击生效
。

通过以上流程可以看出CSRF攻击的一些特征 ：

(1)CSRF攻击场景很大程度上依赖于浏览器的自动行为（浏览器在发送请求时会自动携带相应的Cookie）；

(2)攻击者实施CSRF攻击并不能窃取到用户的Cookie；

(3)攻击者实施CSEF攻击并不需要窃取到用户账户控制权（如窃取用户名密码）；

(4)由于浏览器同源策略的限制 ，攻击者也无法窃取到恶意请求返回的结果。

Part 02、  如何防御CSRF攻击  

在了解了CSRF攻击的免费模板方式和特征之后，就可以有针对性地采取相应的防御措施 。

2.1 防御策略一
：使用CSRF令牌

一种比较流行的防御方式是使用CSRF令牌（Token） 。它通过在用户会话中生成一个唯一的令牌 ，并将其嵌入到用户的请求中来验证请求的合法性 。

以下是使用CSRF令牌进行防御的基本步骤：

(1)接口鉴权 ：服务端针对敏感请求接口（API）进行身份校验，不允许匿名访问；

(2)生成CSRF令牌 ：在用户登录开始时，服务器为用户生成一个唯一的CSRF令牌。这个令牌通常是一个随机的字符串或JWT 。

(3)将令牌嵌入到请求中
：在用户访问页面或发送请求时 ，将生成的CSRF令牌嵌入到请求中。

(4)验证令牌 ：当用户提交请求时，服务器端会验证请求中的CSRF令牌是否有效 。如果令牌有效，则说明请求是合法的；如果令牌无效或者缺失
 ，则可能是CSRF攻击，服务器拒绝该请求 。

使用令牌方式防御CSRF攻击时 ，需注意如下几点：

(1)该令牌必须具有随机性
，使得攻击者无法伪造令牌；

(2)该令牌不能存储在Cookie中
，服务端进行用户身份校验时不能通过Cookie自动获取该令牌；

(3)用户在浏览器中退出登录时，需清除本地存储的令牌；

(4)用户在登录成功后需妥善存储令牌
 ，以免泄漏给第三方；

(5)开发者在实现时需注意令牌的生成和验证逻辑的安全性，并合理管理令牌的生命周期 。

2.2 防御策略二：检查Referer头部信息

Referer是HTTP协议中的一个字段，用于指示请求的来源页面  。当浏览器发送HTTP请求时  ，它会在请求头中包含Referer字段，值为当前页面的URL
。通过检查Referer请求头，服务器可以验证请求的来源是否与预期一致 ，从而判断请求是否合法 。

需要注意的是 ，Referer请求头并不是绝对可靠的 ，一些浏览器或网络代理可能会修改或删除Referer请求头 。因此，单独依赖Referer头部进行防御可能不足以阻止所有的CSRF攻击，但它仍然可以作为一种附加层面的安全措施，与其他防御措施（如CSRF令牌）结合使用，以提高系统的整体安全性。

2.3 防御策略三：实施SameSite属性限制

SameSite属性是一种可以应用于HTTP Cookie的安全属性，它用于控制浏览器是否允许在跨站点请求中发送Cookie
。通过设置SameSite属性
 ，可以限制Cookie只在同一站点的请求中发送 
，从而减少CSRF攻击的风险。

需要注意的是，SameSite属性并非所有浏览器都完全支持，特别是旧版本的浏览器。SameSite属性最早由Google在2016年提出，并在2018年的Chrome浏览器版本中首次实现和推出。因此 ，在使用SameSite属性时，需要进行适当的兼容性检查 ，并根据具体情况选择合适的Fallback策略。

2.4 防御策略四：使用双因素身份验证

双因素身份验证（Two-Factor Authentication，简称2FA）是一种增强登录安全性的身份验证方法  。它要求用户在登录或进行敏感操作时，除了提供密码（或其他单一因素）外，还要提供第二个独立的验证因素，以确认其身份 。常见的验证因素包括密码、手机验证码、动态验证码 、指纹识别 、硬件令牌等 。

对于部分敏感操作，例如删除账户信息 、支付等
，可以强制要求用户进行双因素身份验证。这样可以增加攻击者成功实施CSRF攻击的难度 ，因为即使攻击者能够伪造请求，仍然无法通过双因素验证步骤
。

需要注意的是，双因素身份验证并不是绝对安全的，只能作为综合的安全措施之一，与其他防御策略结合使用 ，以提供更强大的安全防护
。

2.5 防御策略五 ：谨慎使用GET请求

在防御CSRF（Cross-Site Request Forgery）攻击时，合理使用HTTP请求方法是非常重要的。尤其是针对GET请求 ，通常而言 ，GET请求要求具备幂等性 ，所以某些安全框架的配置中默认没有对GET请求进行防护
 。

在Spring Security中，可通过CsrfFilter实现对CSRF攻击的防护。CsrfFilter拦截请求
，并允许使用GET 、HEAD、TRACE 和 OPTIONS等HTTP方法的请求。而针对PUT、POST
、DELETE等可能会修改数据的其他请求，CsrfFilter则要求其必须包含csrf_token信息 。如果请求中不存在或包含不正确的csrf_token值，服务端将拒绝该请求并返回403状态码
。

因此  ，对于执行敏感操作的请求，应该使用POST 、PUT、DELETE等非幂等方法，而不是GET方法 。这样可以防止攻击者通过构造恶意的图片或链接来触发CSRF攻击 。

Part 03 、  总结  

CSRF攻击是一种长期存在且不断演变的安全威胁
。随着互联网技术的不断发展，CSRF攻击也在不断演进 ，未来的CSRF攻击可能会更加复杂
、隐蔽和智能化 。为了应对这些威胁 ，安全研究人员和开发者需要密切关注攻击的新趋势和漏洞，并不断提升防御技术和意识。同时，用户也需要保持警惕，采取合适的防护措施 ，以确保个人和组织的网络安全 。