CSRF 攻击详解

什么是csrf攻击?

CSRF攻击(Cross-Site Request Forgery,跨站请求伪造)是一种常见的网络攻击方式,它利用网站对用户浏览器的信任,诱使用户在不知情的情况下发送恶意请求。这类攻击通常发生在用户已经通过身份验证的Web应用上。

工作原理

CSRF攻击的基本原理是攻击者诱使已经登录的用户(例如在银行网站上)在不知情的情况下执行攻击者预设的操作。例如,用户在没有登出银行网站的情况下,在另一个标签页中访问了攻击者的网站。攻击者的网站包含了一个请求,该请求指向银行网站并试图执行一个操作(如转账)。因为用户的浏览器仍然保持与银行网站的会话,所以这个请求会带上用户的认证cookie,使得请求看起来是合法的。

示例

假设用户登录了银行网站bank.com,并在不退出的情况下访问了另一个包含恶意代码的网站。这个恶意网站上有如下HTML代码:

<img src="http://bank.com/transfer?amount=1000&to=attacker">

当用户浏览该页面时,他们的浏览器会尝试加载这个图片,实际上向bank.com发起了一个转账请求。因为这个请求是从用户的浏览器发起的,所以它会自动包含用户的登录凭证(如cookie),银行网站可能会误认为这是一个合法的用户请求。

防御措施

  1. 使用Anti-CSRF Token:最常见的防范措施是在表单中添加一个CSRF Token,这是一个随机生成的令牌,服务器在渲染表单时生成并验证。只有包含有效CSRF Token的请求才会被接受。

  2. 检查Referer Header:服务器可以验证HTTP请求的Referer头部,以确保请求是从合法的源发起的。

  3. 使用SameSite Cookie属性:设置Cookie的SameSite属性可以限制第三方网站发送带有用户cookie的请求。例如,设置为SameSite=Strict将完全禁止跨站请求携带cookie。

  4. 提高用户安全意识:教育用户识别并避免可疑链接,保持软件更新,使用现代浏览器等,都是减少CSRF攻击风险的有效方法。

总结而言,CSRF是一种利用网站对用户浏览器的信任执行未授权操作的攻击手段。通过合理的安全策略和编程措施,可以有效地防止这种攻击。

如果浏览器端不是基于cookie,而是基于token的,还会有csrf攻击吗?

当浏览器端使用基于token的认证方式(如在HTTP头中使用Bearer token)而非依赖于自动由浏览器附加的cookies时,跨站请求伪造(CSRF)攻击的风险会显著降低。这是因为CSRF攻击的核心在于利用了浏览器自动发送cookie的行为。如果认证信息(如token)需要明确地由前端代码设置在HTTP请求的头部,那么恶意网站则无法自动复制这种行为,因为浏览器的同源策略(SOP)阻止了一个源读取另一个源的数据。

(当用户停留在当前网站的页面,这意味着session还没结束,然后又打开了另一个tab网页,这个网页里内嵌了第一部分加载 img 的代码,浏览器试图解析这个 "img" ,去访问了银行的这个链接,这时候浏览器是自动把 cookie 带上访问的,不需要开发者处理;

但是基于token的访问就需要前端开发人员手动把 token 放在 header 里,所以就避免了csrf攻击

这也解释了为什么csrf 攻击只存在于浏览器端)

为什么基于Token的认证较不易受CSRF攻击:

  1. 不自动附加:与cookie不同,存储在本地存储(localStorage或sessionStorage)的token不会自动附加到每个发往服务器的请求中。开发者需要显式地将token添加到请求的Authorization头部。这意味着只有能够通过JavaScript访问token的网站才能发起带有认证信息的请求。

  2. 受同源策略保护:浏览器的同源策略阻止了一个源的脚本访问另一个源的数据。因此,如果token存储在例如localStorage中,恶意网站的脚本无法从另一个标签页的localStorage中读取token,除非两个标签页都来自相同的源。

仍需注意的安全问题:

尽管基于token的认证机制在防御CSRF方面较为安全,但它并不是没有安全隐患,例如:

  • 跨站脚本攻击(XSS):如果恶意脚本能够注入并执行在一个网站上,那么它可能能够访问localStorage或sessionStorage,并窃取存储的token。因此,防御XSS攻击对于使用token仍然非常重要。

  • 其他类型的攻击:虽然基于token的认证减少了CSRF的风险,但仍需防范其他类型的攻击,如钓鱼攻击、中间人攻击等。

最佳实践:

  • 使用HTTPS:确保所有通信都通过安全的HTTP(HTTPS)进行,以避免中间人攻击。
  • 有效的内容安全策略(CSP):实施CSP帮助减少XSS的风险。
  • 定期更新和旋转token:确保token具有过期时间,并在必要时进行更换,以减少被窃用的风险。
  • 验证请求的来源:尽管不是必要的,但检查请求的来源(如检查HTTP头中的Origin或Referer)可以增加一个额外的安全层。

总结来说,基于token的认证方式确实减少了CSRF攻击的风险,但仍需要结合其他安全措施,来保护应用免受各种网络攻击的威胁。

https会对整个request报文加密吗,还是只对请求的payload加密?

在HTTPS(HTTP Secure)协议下,不仅请求的payload(即HTTP请求的主体内容)被加密,而且整个HTTP请求和响应的头部信息(headers)也被加密。这意味着除了基本的TCP/IP层(例如IP地址和端口号)信息外,发送到服务器的所有信息,包括URL的路径(但不包括域名部分,如下所述)、查询参数、cookies、用户代理等,都被加密。HTTPS通过SSL/TLS协议实现加密,保护数据免受中间人攻击的窥探和篡改。

HTTPS的加密范围

以下是HTTPS加密的具体内容:

  1. 请求和响应头部:所有的HTTP头部都被加密,包括用户代理、cookie、认证信息、自定义头部等。

  2. 请求和响应主体:任何发送给服务器的数据或从服务器接收的数据,无论是文本、图片、视频还是其他任何类型的数据,都会被加密。

  3. URL的路径和查询字符串:虽然整个URL不在HTTP请求行中传输(因为HTTP请求只包含路径和查询部分,而不包括协议和域名),但路径和查询字符串部分仍然会被加密。

HTTPS不加密的部分

  • 域名:虽然域名本身不在HTTP请求中发送,但通过DNS解析过程可能会暴露,并且在SSL/TLS握手过程中,服务器域名(通过服务器证书呈现)是可见的。此外,使用Server Name Indication(SNI)扩展的SSL/TLS握手会在握手过程中明文传输域名,尽管新的加密SNI(ESNI)技术正在逐步推广以解决这一问题。

安全性和隐私

由于HTTPS加密了除DNS查找和SNI字段外的所有HTTP交互数据,它有效地保护了用户数据的机密性和完整性,防止了数据在传输过程中被窥视或篡改。这对于保护敏感操作,如在线购物、银行交易和个人数据传输等,尤为重要。

结论

总之,HTTPS确保除了域名和部分握手细节外,整个HTTP请求和响应过程中传输的数据都得到了加密和保护。这包括HTTP头部和主体数据,使得HTTPS非常适合保护用户在互联网上的隐私和安全。

为什么csrf攻击只存在于浏览器端?

CSRF(跨站请求伪造)攻击主要存在于浏览器端,原因在于浏览器的特性和行为。以下是详细的解释:

1. 浏览器自动发送认证信息

CSRF 攻击利用了浏览器的一个特性:浏览器会自动发送存储在它内部的认证信息(如 Cookies、HTTP 认证头等)。当用户登录一个网站后,浏览器会把该网站的会话 Cookie 保存在客户端。在用户访问相同网站的其他页面或者发送请求时,浏览器会自动附带这些 Cookies。

2. CSRF 攻击的基本流程

一个典型的 CSRF 攻击流程如下:

  1. 用户登录到受信任的网站(如银行网站),并保持登录状态。
  2. 用户在浏览器中打开一个恶意网站,该网站包含一个恶意脚本或链接,触发对受信任网站的请求。
  3. 浏览器自动附带用户的会话 Cookie 发送这个请求到受信任的网站。
  4. 受信任的网站接收到请求后,由于会话 Cookie 有效,认为这是一个合法的请求并执行相应操作。

3. 非浏览器客户端的行为

与浏览器不同,非浏览器客户端(如移动应用、桌面应用、API 客户端)不会自动附带认证信息(如 Cookies)发送请求。通常,这些客户端需要明确地设置认证信息,例如在 HTTP 请求头中添加授权令牌(如 JWT)。因此,攻击者无法轻易伪造请求并附带合法的认证信息进行操作。

4. 示例解释

假设你有一个银行网站 https://bank.com,用户在浏览器中登录了这个网站,并且浏览器保存了一个会话 Cookie。

在浏览器中:
  1. 用户登录 https://bank.com,浏览器保存会话 Cookie。
  2. 用户访问恶意网站 https://malicious.com,该网站包含以下代码:

    html

    复制
    <img src="https://bank.com/transfer?amount=1000&to=attackerAccount" />
    
  3. 浏览器自动发送请求到 https://bank.com,并附带会话 Cookie。
  4. 银行网站接收到请求并执行转账操作。
在非浏览器客户端中:

假设你有一个移动应用,需要访问银行 API https://api.bank.com/transfer

  1. 移动应用发送请求时,必须明确地在请求头中设置认证信息(如 JWT)。

    java

    复制
    HttpRequest request = HttpRequest.newBuilder().uri(URI.create("https://api.bank.com/transfer")).header("Authorization", "Bearer <token>").build();
    
  2. 恶意应用无法自动附带合法的认证信息,除非它已经获取了用户的认证信息(如盗取了 JWT),但这属于另一种类型的攻击(如盗取令牌)。

5. 防御措施

虽然 CSRF 主要针对浏览器,但理解它的工作原理有助于更好地防御类似的攻击。常见的防御措施包括:

  • CSRF 令牌:在每个敏感请求中包含一个唯一的、不可预测的令牌,并在服务器端验证该令牌。
  • SameSite Cookie 属性:设置 Cookie 的 SameSite 属性为 Strict 或 Lax,限制 Cookie 的跨站发送。
  • 检测 Referer 头:部分系统会检查请求的 Referer 头,以确保请求来源于同一站点。

结论

CSRF 攻击依赖于浏览器自动附带认证信息的特性,因此在浏览器环境中更容易实现和利用。在非浏览器客户端中,由于认证信息需要明确设置,CSRF 攻击的风险大大降低。了解这些原理可以帮助开发者更好地保护应用免受 CSRF 攻击。

为什么在springsecurity里一般都disable掉csrf?

在 Spring Security 中,CSRF(跨站请求伪造)保护是默认启用的,因为它是防止用户在已经认证的状态下被恶意网站利用的一个重要安全机制。然而,在某些情况下,开发者会选择禁用 CSRF 保护。以下是一些常见的原因和场景:

1. API 端点

在开发 RESTful API 时,通常不需要 CSRF 保护,因为:

  • RESTful API 通常是无状态的,并且客户端(如移动应用、单页应用)不会存储和使用会话 Cookie。
  • API 请求通常使用 JWT(JSON Web Token)或其他基于令牌的认证机制,而不是基于会话的认证。

java

复制

@Override
protected void configure(HttpSecurity http) throws Exception {http.csrf().disable().authorizeRequests().anyRequest().authenticated();
}

2. 使用其他防护措施

有时,应用程序可能已经使用了其他防护措施,如 JWT 或 OAuth,这些机制在某种程度上也可以防御 CSRF 攻击。例如,通过在请求头中发送令牌,攻击者难以伪造合法的请求。

3. 内部应用

对于一些内部应用,特别是完全在受控环境中运行的应用,开发者可能会认为 CSRF 风险较低,因此选择禁用它。

4. 非浏览器客户端

如果应用的客户端不是浏览器,如移动应用、桌面应用或其他类型的客户端,这些客户端不会遭受传统的 CSRF 攻击。因此,可以选择禁用 CSRF 保护。

5. 简化开发和测试

在开发和测试阶段,有时为了简化工作流程,开发者会暂时禁用 CSRF 保护。但在这种情况下,应该确保在生产环境中重新启用 CSRF 保护。

例外情况

尽管有以上原因,有些情况下不应该禁用 CSRF 保护,特别是在以下场景中:

  • Web 应用程序接受来自用户的表单提交。
  • 应用程序依赖于会话来管理用户认证状态。

如何禁用 CSRF

如果你确实需要禁用 CSRF 保护,可以在 Spring Security 配置中通过 HttpSecurity 的 csrf().disable() 方法来实现:

java

复制

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {@Overrideprotected void configure(HttpSecurity http) throws Exception {http.csrf().disable().authorizeRequests().anyRequest().authenticated();}
}

总结

禁用 CSRF 保护有其合理的应用场景,特别是在开发 RESTful API、使用其他防护措施、内部应用和非浏览器客户端时。然而,需要谨慎对待这个决定,并确保在适当的场景中启用 CSRF 保护,以防范潜在的安全风险。

如果springsecurity不禁用csrf会怎么样?

在 Spring Security 中,如果不禁用 CSRF 保护,应用程序会具有一定的安全保障,防止跨站请求伪造攻击。具体来说,不禁用 CSRF 保护会带来以下影响和行为:

1. 表单提交需要 CSRF 令牌

当 CSRF 保护启用时,所有通过表单提交的 POST、PUT、DELETE 等敏感请求都需要包含一个有效的 CSRF 令牌。这个令牌由服务器生成,并在表单中以隐藏字段的形式包含。服务器会验证令牌的有效性,以确保请求来自合法用户。

示例:

html

复制

<form action="/some-action" method="POST"><input type="hidden" name="_csrf" value="generated-csrf-token" /><!-- 其他表单字段 --><button type="submit">Submit</button>
</form>

在 Spring MVC 控制器中可以这样生成 CSRF 令牌:

java

复制

@GetMapping("/form")
public String showForm(Model model) {model.addAttribute("csrfToken", ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest().getAttribute("_csrf"));return "form";
}

2. AJAX 请求需要 CSRF 令牌

对于使用 AJAX 发送的请求,CSRF 令牌需要在请求头中包含。通常情况下,可以在全局 AJAX 设置中配置 CSRF 令牌:

javascript

复制

$.ajaxSetup({beforeSend: function(xhr) {xhr.setRequestHeader('X-CSRF-Token', $('meta[name="csrf-token"]').attr('content'));}
});

3. 错误处理

如果请求不包含有效的 CSRF 令牌,服务器会返回 403 Forbidden 错误,表示请求被拒绝。这可以防止未经授权的请求执行敏感操作。

4. RESTful API 的影响

在 RESTful API 中,如果启用了 CSRF 保护,客户端需要在每个非 GET 请求中包含 CSRF 令牌。这在使用基于令牌的认证机制(如 JWT)时会显得多余,因为这些机制已经提供了一定的安全保障。在这种情况下,通常会禁用 CSRF 保护:

java

复制

@Override
protected void configure(HttpSecurity http) throws Exception {http.csrf().disable().authorizeRequests().anyRequest().authenticated();
}

5. 安全性提升

启用 CSRF 保护后,应用程序可以有效防止 CSRF 攻击。这种攻击利用用户的身份执行未经授权的操作,可能导致数据泄露、账户操作等安全问题。

总结

如果在 Spring Security 中不禁用 CSRF 保护,应用程序会有以下行为和影响:

  • 表单提交和 AJAX 请求需要包含有效的 CSRF 令牌。
  • 服务器会验证 CSRF 令牌的有效性,拒绝未包含或包含无效令牌的请求。
  • RESTful API 可能需要额外的配置来处理 CSRF 令牌,或选择禁用 CSRF 保护。
  • 提升整体安全性,有效防止 CSRF 攻击。

启用 CSRF 保护有助于增强应用的安全性,但需要开发者在前端和后端之间进行适当的协调,确保所有敏感请求都包含有效的 CSRF 令牌。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/841740.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

linux 常用命令:find grep ps netstat sudo df du rm

rm 命令 删除 -r 是递归参数&#xff08;recursive&#xff09;&#xff0c;用于删除目录及其内容。如果不加这个参数&#xff0c;rm 命令无法删除非空目录。-f 是强制参数&#xff08;force&#xff09;&#xff0c;用于强制删除文件或目录&#xff0c;不会进行任何确认提示…

g-h Filter 详细讲解

g-h 过滤器 g-h 滤波器百科介绍。 之前的翻译大家&#xff0c;我看都没什么阅读量&#xff0c;可能大家都不是很想看&#xff08;估计也是我英文太水&#xff09;。那么这篇博客我就先暂停直接翻译原文&#xff0c;而是直接说一下自己的理解。 本文章背后的书的详细介绍可以…

企业客户信息反馈|基于SprinBoot+vue的企业客户信息反馈平台(源码+数据库+文档)

企业客户信息反馈平台 目录 基于SprinBootvue的企业客户信息反馈平台 一、前言 二、系统设计 三、系统功能设计 1平台功能模块 2后台登录 5.2.1管理员功能 5.2.2客户功能 四、数据库设计 五、核心代码 六、论文参考 七、最新计算机毕设选题推荐 八、源码获取&am…

vscode远程连接Ubuntu mysql服务器

注意&#xff1a;刚开始使用root用户死活连接不上&#xff0c;可能就是root用户没有权限的问题&#xff0c;可以尝试创建一个新的数据库用户&#xff0c;授予权限进行连接 ubuntu安装mysql 创建新用户 执行&#xff1a;sudo apt-get install mysql-server安装服务器(yum) 执…

Aya 23 是 Cohere For AI 推出的一款最先进的新型多语言开放重量模型

相信一些对LLM关注较高的同学们&#xff0c;应该对这家加拿大的Cohere不会太陌生。毕竟此前&#xff0c;它就开源过 Aya 101 和 Command R 这两款大模型。 Cohere 的非营利性研究实验室 Cohere for AI 发布了 Aya 23&#xff0c;这是其多语言大型语言模型 &#xff08;llm&…

[SWPUCTF 2021 新生赛]pop

常见的魔术方法 魔术方法__construct() 类的构造函数&#xff0c;在对象实例化时调用 __destruct() 类的析构函数&#xff0c;在对象被销毁时被调用 __call() 在对象中调用一个不可访问的对象时被调用&#xff0c;比如一个对象被调用时&#xff0c;里面没有程序想调用的属性 …

ML307R OpenCPU 数据保存文件系统fs使用

一、函数介绍 二、实现数据保存 三、代码下载地址 一、函数介绍 以下是cm_fs.h里面的函数介绍 /*** brief 文件指针定位** param [in] fd 文件描述符* param [in] offset 指针偏移量* param [in] base 偏移起始点&#xff0c;CM_FS_SEEK_SET&#xff1a;文件开头 CM_FS…

Leetcode260

260. 只出现一次的数字 III - 力扣&#xff08;LeetCode&#xff09; class Solution {public int[] singleNumber(int[] nums) {//通过异或操作,使得最终结果为两个只出现一次的元素的异或值int filterResult 0;for(int num:nums){filterResult^num;}//计算首个1(从右侧开始)…

视频号小店怎么进入优选联盟?入驻优选联盟都有什么条件?

大家好&#xff0c;我是电商花花。 视频号小店想要出单、爆单&#xff0c;不管在流量上还是销量都离不开达人带货&#xff0c;因为目前视频号小店上基本上就没有自然流量&#xff0c;想出单只能做达人带货。 而视频号小店想要找达人带货&#xff0c;必须是企业店铺&#xff0…

数据结构(七)查找

2024年5月26日一稿(王道P291) 7.1 查找的基本概念 7.2 顺序查找和折半查找 7.2.1 顺序查找 7.2.2 折半查找 7.2.3 分块查找 7.3 树形查找 7.3.1 二叉排序树(BST)

根据Depth Quality Tool的z轴误差值确认相机是否需要进行相机内参校准

下载Depth Quality Tool深度质量验证工具 网盘链接【RealSense SDK v2.55.1】 链接&#xff1a;https://pan.baidu.com/s/1NrlbwNDBUL8wpWfVwbpMwA?pwd2jl0 提取码&#xff1a;2jl0 打开Depth Quality Tool深度质量验证工具 找一面墙作为目标&#xff0c;将摄像头水平对准墙…

第四课 communcation服务-can配置第二弹

Davinci配置目标: 介绍DBC基本属性,并且配置出一个DBC。 将DBC导入到vector的davinci工具,生成我们想要的代码。 Davinci配置步骤: 1. 编辑DBC文件 DBC文件是一种非常重要的工具,所谓DBC就是Database CAN,CAN网络的数据库文件,定义了CAN网络的节点、消息、信号的所有…

小白入职 必要熟悉 Git / tortoiseGit 工具

1.安装Git 1.1 了解Git Git是分布式版本控制系统&#xff0c;没有中央服务器的每个人的电脑就是一个完整的版本库&#xff0c;工作时无需联网可多人协作&#xff0c;只需把各自的修改推送给对方&#xff0c;就可以互相看到对方的修改了 分布式版本控制工具管理方式&#xff…

架构师必考题--软件系统质量属性

软件系统质量属性 1.质量属性2.质量属性场景描述3.系统架构评估 这个知识点是系统架构师必考的题目&#xff0c;也是案例分析题第一题&#xff0c; 有时候会出现在选择题里面&#xff0c;考的分数也是非常高的。 1.质量属性 属性说明可用性错误检测/恢复/避免性能资源需求/管理…

42-4 应急响应之文件痕迹排查

一、文件痕迹排查 对恶意软件常用的敏感路径进行排查: 恶意软件通常会利用系统中一些常见的敏感路径来存储或执行恶意代码,因此排查这些路径是非常重要的。常见的敏感路径包括系统目录、临时目录、用户主目录等。在确定了应急响应事件的时间点后,对时间点前后的文件进行排查…

【Vue】组件间传参与方法调用

【前言】 … 【目标】 1 了解组件间传参 2 组件间自定义事件绑定与解绑 3 组件的事件总线 4 消息订阅与发布 一 组件间传参 1 props 引入并使用组件:传递参数 <template><div id="app"><HelloWorld :msg="msg" :name="name" …

《python编程从入门到实践》day39加更

# 昨日知识点回顾 添加主题、条目 # 今日知识点学习 19.1.3 编辑条目 1.URL模式edit——entry # learning_logs/urls.py ---snip---# 用于编辑条目的页面path(edit_entry/<int:entry_id>/, views.edit_entry, nameedit_entry), ] 2.视图函数edit_entry() # views.py fr…

MySQL数据库中的多表查询/连接查询操作

类型&#xff1a;内连接 &#xff0c;外连接{左外连接&#xff0c;右外连接} 之所以要使用连接查询的意义就是为了&#xff0c;借助数据库可以避免大量的数据重复。 进行连接查询的前提是要求多张表之间存在相关联的字段。 这里指的相关联的字段就是表与表之间存在着关系&am…

ubantu驱动问题

ubuntu20.04安装nvidia显卡驱动-CSDN博客 sudo apt-get --purge remove nvidia* ubuntu-drivers devices nvcc -V Ubuntu(20.04)开机无法进入系统及白色下划线闪烁_安装ubuntu重启白色杠-CSDN博客 驱动程序

logback.xml相关配置——springboot项目

要在 Spring Boot 项目中将日志写入到 Logback 的配置文件 logback.xml 中&#xff0c;你可以按照以下步骤进行设置&#xff1a; 创建 Logback 配置文件&#xff1a; 在 src/main/resources 目录下创建一个名为 logback.xml 的文件。这是默认的 Logback 配置文件名&#xff0c;…