Node中的CSRF攻击和防御
Node中的CSRF攻击和防御
假设有一个网上银行系统，用户可以通过该系统进行转账操作。转账功能的URL可能是这样的：
https://www.bank.com/transfer?toAccount=123456&amount=1000
当用户登录到银行系统，并在浏览器中访问这个URL时，银行系统会执行转账操作，将1000元转入账户123456。
CSRF攻击过程：
-
受害者登录：用户Alice登录到她的网上银行账户（比如
www.bank.com）。 -
攻击者准备攻击页面：攻击者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"; -
受害者访问恶意网站：当Alice在已经登录银行系统的情况下，访问了Eve的恶意网站，浏览器会自动执行页面中的代码，发送一个请求到银行系统。
-
请求执行：因为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中的随机数
- 二次验证，比如要求用户获取验证码进行验证