CSRF攻击

CSRF叫做跨站请求伪造攻击,也有叫XSRF的,其实都差不多,你也可以认为是XSS和CSRF的结合。对于这个攻击原本我是不怎么理解的,写了个接口,然后试了一下,直接就发起了请求。

先看接口:

const http=require('http');



http.createServer(function(requset,response){

 response.setHeader('Access-Control-Allow-Credentials', 'true');

 response.end('123');

}).listen(3000);

当我用图片地址访问的时候,出现:

A cookie associated with a cross-site resource at was set without the SameSite attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with SameSite=None

大概意思就是不允许携带cookie,如果我设置了:

response.setHeader(‘Set-Cookie’, ‘a=888;Path=/;SameSite=Lax’);

然后用img标签请求成功了:

<img src="http://192.168.164.31:3000/" alt="">

虽然cookie没有携带,不知道是不是这个原因:

Chrome 计划将Lax变为默认设置。这时,网站可以选择显式关闭SameSite属性,将其设为None。不过,前提是必须同时设置Secure属性(Cookie 只能通过 HTTPS 协议发送),否则无效。

写不出好的接口去验证,于是只好不求甚解的简单理解一下,就是用户通过访问安全网站,进行登录,登录成功后,用户验证登录的信息记录在了浏览器,这时候用户在安全网站可以正常操作,之后要是用户在同一个浏览器访问不安全网站,不安全网站通过各种方法通过安全网站的用户登录信息进行攻击,比如:

1、当安全网站A登录之后,不安全网站B通过img、script等不会跨域的元素调用get请求的接口,如果是通过请求携带cookie判断的话,直接就可以请求成功。

2、如果后台是POST接口,校验数据用的也是post才能获取参数,不安全网站B可以通过ifram嵌入安全网站A,然后通过form表单提交请求。

这是一般我们认知的简单CSRF,有资料说,可以触发请求的方法达到了几百种,单单HTML就有196种。还有什么PDF JavaScript、ServiceWorkers等奇奇怪怪的方法去进行XSRF攻击。

有攻击就有防御方法,检查Referer、添加校验token、不保存cookie、不使用全局cookie、自定义header属性并校验等等。

虽然不知道CSRF攻击是不是真的那么简单,突然发现自己做过的项目好像并没有想象中的那么安全,感觉随便都能被攻击了。

像阿里这种几乎是所有黑客攻击的第一目标,他们要遭遇的可不仅仅是CSRF这种小儿科玩意儿,很难想象他们的安全团队是多么的牛逼。

CSRF(Cross-site request forgery,跨站请求伪造)是一种常见的Web安全漏洞,攻击者通过伪装成用户向已认证的Web应用发送恶意请求,从而执行未经授权的操作,例如更改用户密码、发起转账等。这种攻击之所以能够成功,是因为浏览器会自动在请求中携带用户与目标网站的会话信息(如Cookie),而服务器端无法区分请求是否由用户主动发起[^4]。 ### CSRF攻击原理 CSRF攻击的核心在于攻击者能够诱导用户访问一个恶意网站或点击一个恶意链接,该链接会向目标网站发起请求。由于用户已经登录目标网站,其会话凭证(如Cookie)会自动附加到请求中,服务器端误认为这是用户合法的操作请求。例如,攻击者可以构造一个隐藏的表单,当用户点击某个链接或访问某个页面时,自动提交该表单至目标网站,执行如更改邮箱、转账等操作[^4]。 ### CSRF防护措施 #### 1. CSRF Token CSRF Token 是目前最成熟、最广泛使用的防护方法。其基本思想是在每次请求中加入一个随机生成的令牌(Token),该令牌必须包含在请求参数或请求头中,服务器端会对该令牌进行验证。由于攻击者无法获取该令牌(不能通过跨域访问获取),因此无法伪造合法的请求。通常的做法是: - 在登录或初始化会话时生成一个唯一的Token。 - 将Token存储在服务器端(如Session)。 - 在前端页面中将Token作为隐藏字段或请求头传递。 - 服务器端接收到请求后,验证Token是否匹配。 例如,在HTML表单中可以加入如下隐藏字段: ```html <input type="hidden" name="csrf_token" value="abc123xyz"> ``` 在后端验证逻辑中,可以通过拦截器或中间件进行Token校验[^3]。 #### 2. 同源检测(Origin 和 Referer 检查) 通过检查请求头中的 `Origin` 或 `Referer` 字段,判断请求是否来自预期的源。如果这两个字段缺失或与当前域名不匹配,则拒绝该请求。这种方法适用于大多数现代浏览器,但存在一定的局限性,例如某些客户端或代理可能会省略这些字段,导致误判[^1]。 #### 3. 验证请求方法一致性 只对 `POST` 请求进行CSRF防护是一种语义一致性策略。因为 `GET` 请求通常用于获取数据,不应产生副作用,而 `POST` 请求则用于提交数据、执行操作。因此,开发者应确保所有状态更改的操作都使用 `POST` 方法,避免使用 `GET` 提交敏感操作,从而减少攻击面。 #### 4. 二次验证(用户交互确认) 对于高敏感操作(如修改密码、转账等),可以要求用户再次输入密码或点击确认按钮。这种方式虽然增加了用户体验的复杂度,但能有效防止CSRF攻击,因为攻击者无法自动完成二次验证步骤。 #### 5. SameSite Cookie 属性 现代浏览器支持 `SameSite` Cookie 属性,可以设置为 `Strict` 或 `Lax`,以限制Cookie在跨站请求中的发送。设置为 `SameSite=Strict` 时,Cookie 仅在同源请求中发送;设置为 `SameSite=Lax` 时,允许部分安全的跨站请求(如 `GET` 请求)携带Cookie。这种方法可以有效缓解CSRF攻击,但需要浏览器支持。 ### 小结 CSRF攻击利用了浏览器自动携带会话凭证的机制,攻击者通过诱导用户访问恶意链接或页面,伪造用户执行非授权操作。为了有效防御CSRF攻击,推荐使用 **CSRF Token** 机制,结合 **同源检测** 和 **请求方法一致性** 等策略,确保请求的来源可信且不可伪造。此外,合理使用 **SameSite Cookie 属性** 也能在现代浏览器中提供额外的防护[^3]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值