Node中的CSRF攻击和防御

Node中的CSRF攻击和防御

假设有一个网上银行系统,用户可以通过该系统进行转账操作。转账功能的URL可能是这样的:

https://www.bank.com/transfer?toAccount=123456&amount=1000

当用户登录到银行系统,并在浏览器中访问这个URL时,银行系统会执行转账操作,将1000元转入账户123456。

CSRF攻击过程:

  1. 受害者登录:用户Alice登录到她的网上银行账户(比如www.bank.com)。

  2. 攻击者准备攻击页面:攻击者Eve创建了一个恶意网站www.evil.com,并在该网站上嵌入了一段HTML代码或JavaScript代码,试图利用CSRF漏洞:

    <img src="https://www.bank.com/transfer?toAccount=999999&amount=1000" style="display:none">
    

    或者通过JavaScript发送请求:

    var img = new Image();
    img.src = "https://www.bank.com/transfer?toAccount=999999&amount=1000";
    
  3. 受害者访问恶意网站:当Alice在已经登录银行系统的情况下,访问了Eve的恶意网站,浏览器会自动执行页面中的代码,发送一个请求到银行系统。

  4. 请求执行:因为Alice已经在银行系统中登录,浏览器会带上Alice的会话Cookie。这时,银行系统收到请求后,会认为这是一个合法的请求,并执行转账操作,将1000元转入攻击者的账户999999。

防御措施:

  • 设置后端的cookie 禁止跨域携带cookie 我们只需要把cookie设置的 SameSite:Strict即可;
  • 验证 referer和Origin 每个页面都会带这哥俩 通过验证这哥俩也就可以了
  • 使用token 每一次请求都带token
  • 使用验证码 要求用户进行敏感操作的时候 填写验证码
  • 表单随机数(这种做法是在服务端渲染的时候用)
    • 1.生成一个随机数放到 session中
    • 2.生成页面时,表单中加入一个隐藏的表单域 : <input type="hidden" name:"Hash" value="<%=session['key']%>">
    • 3.服务端 进行验证随机数
    • 4.清除session中的随机数
  • 二次验证,比如要求用户获取验证码进行验证
  • 4
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值