XSS 和 CSRF 到底有什么本质区别?

关注我们,设为星标,每天7:30不见不散,每日java干货分享

 

在网络安全领域,SQL 注入是“暴力破门”,XSS 是“往饭里下毒”。
而 CSRF (Cross-Site Request Forgery),则是最高明的 “借刀杀人”

黑客不需要偷你的密码,也不需要盗取你的账号。他只需要利用你的浏览器对网站的**“盲目信任”**,就能借你的手,做他想做的事。


💻 一、技术分析:浏览器太“贴心”的锅

要理解 CSRF,必须理解浏览器的一个机制:自动携带 Cookie

1. 正常的身份验证

  1. 1. 你登录了 bank.com(银行)。
  2. 2. 银行服务器给你发了一个 Cookie(相当于通行证)。
  3. 3. 之后你每次访问银行的页面,浏览器都会自动帮你把这个 Cookie 带上,告诉银行“是我”。

2. 攻击原理

浏览器的这个“自动携带”机制,在跨站请求时依然生效。

  • • 假设你在浏览器里打开了两个标签页:
  • • 标签页 A: 已登录的网上银行 (bank.com)。
  • • 标签页 B: 黑客诱导你点开的钓鱼网站 (evil.com)。
  • • 黑客在 evil.com 里埋了一行代码:
    <img src="http://bank.com/transfer?to=hacker&money=1000">
  • • 关键点:
  • • 浏览器解析到这个 img 标签时,会尝试加载图片。
  • • 它发现图片地址是 bank.com
  • • 浏览器非常“贴心”地把你刚才在银行领的 Cookie 也带上了!
  • • 结果:
  • • 银行服务器收到请求,一看 Cookie 是对的。
  • • 银行以为是你本人发起的操作。
  • • 转账成功。

🎭 二、故事场景:由于一张美女图片引发的破产

为了搞懂 CSRF 的隐蔽性,我们来看一个 “借刀杀人” 的完整剧本。

  • • 主角: 老王(用户)。
  • • 场景: 某银行网站。
  • • 道具: 银行的信物 (Cookie)。

第一幕:毫无防备 (登录)

老王在电脑上登录了银行账户查余额。查完后,他没有点击“退出登录”,只是随手关掉了网页标签(此时 Session/Cookie 依然有效)。

第二幕:误入歧途 (中招)

老王无聊时,在一个论坛里看到一个标题:“性感荷官,在线发牌”
老王没忍住,点进了这个帖子(进入了黑客构造的页面)。

第三幕:暗度陈仓 (伪造)

这个帖子里其实只有一张普通的图片。但在图片的背后,黑客隐藏了一个透明的 iframe 或者一个自动提交的 form 表单:

<form action="http://bank.com/transfer" method="POST">
    <input type="hidden" name="to" value="黑客账户">
    <input type="hidden" name="money" value="10000">
</form>
<script>document.forms[0].submit();</script>

第四幕:借刀杀人 (执行)

  1. 1. 老王打开网页的一瞬间,脚本自动执行。
  2. 2. 浏览器向 bank.com 发起了 POST 请求。
  3. 3. 因为老王刚才没退出登录,浏览器忠诚地带上了老王的银行 Cookie。
  4. 4. 银行后台收到请求:“哟,老王要把钱转给某某,信物也在,准了!”

第五幕:结局

老王只是看了一眼帖子,甚至没点任何按钮,钱就没了。
这就是 CSRF —— 利用你的身份,借你的浏览器,杀你的钱包。


🛡️ 三、防御:哪怕你有刀,我也要有盾

怎么防?靠用户“不乱点链接”是不现实的。必须在服务器端设防。

1. Referer Check (查户口)

  • • 原理: HTTP 头里有一个 Referer 字段,记录了请求是从哪里链接过来的
  • • 防御: 银行规定:“凡是转账请求,Referer 必须是 bank.com 自己的页面。如果是从 evil.com 过来的,一律拒绝。”
  • • 缺点: 有些浏览器或防火墙会抹去 Referer,且 Referer 可以被伪造。

2. CSRF Token (暗号) —— 最推荐

  • • 原理: 在转账表单里,加一个随机的、黑客猜不到的暗号
  • • 流程:
  1. 1. 老王打开正常的转账页面时,银行在页面里埋入一个 <input type="hidden" value="随机暗号123">
  2. 2. 老王提交时,把 Cookie 和 暗号 一起发过去。
  3. 3. 关键: 黑客的网站虽然能利用 Cookie,但他拿不到这个随机生成的暗号(因为同源策略,他读不到银行页面的内容)。
  4. 4. 银行检查:Cookie 对,但没有暗号?拒绝!

3. SameSite Cookie (紧闭门户)

  • • 原理: 这是现代浏览器的终极杀招。
  • • 设置: 在 Cookie 上加一个属性 SameSite=Strict
  • • 效果: 浏览器承诺:“只要不是你正在看的这个网站发起的请求,我绝对不带 Cookie。”
  • • 结果: 黑客的 evil.com 发起请求时,Cookie 被浏览器扣下了,攻击直接失效。

🎯 四、总结:XSS 是偷 Cookie,CSRF 是用 Cookie

很多面试者分不清 XSS 和 CSRF。

  • • XSS (跨站脚本): 黑客把代码注入到你的页面里。目的是偷你的 Cookie,然后自己拿去登录。
  • • CSRF (跨站请求伪造): 黑客不需要偷你的 Cookie。目的是借用你的浏览器,在你自己都没察觉的情况下,替你发号施令。

一句话总结:CSRF 就是利用了浏览器“自动发送 Cookie”的便利性,打了一个完美的时间差。

 


推荐阅读  点击标题可跳转

50个Java代码示例:全面掌握Lambda表达式与Stream API

16 个 Java 代码“痛点”大改造:“一般写法” VS “高级写法”终极对决,看完代码质量飙升!

为什么高级 Java 开发工程师喜爱用策略模式

精选Java代码片段:覆盖10个常见编程场景的更优写法

提升Java代码可靠性:5个异常处理最佳实践

为什么大佬的代码中几乎看不到 if-else,因为他们都用这个…

还在 Service 里疯狂注入其他 Service?你早就该用 Spring 的事件机制了


看完本文有收获?请转发分享给更多人

关注「java干货」加星标,提升java技能




❤️给个「推荐 」,是最大的支持❤️

.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}

.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}

.cls-1{fill:#001e36;}.cls-2{fill:#31a8ff;}

© 版权声明
THE END
喜欢就支持一下吧
点赞0赞赏 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容