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中的随机数
• 二次验证，比如要求用户获取验证码进行验证