如何通过JWT防御CSRF

本文介绍了CSRF攻击原理及其防御方法,详细解释了JSON Web Token (JWT) 的概念,并探讨了如何利用JWT增强Web应用安全性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

如何通过JWT防御CSRF 博客分类: 架构

先解释两个名词,CSRF 和 JWT。

CSRF (Cross Site Request Forgery),它讲的是你在一个浏览器中打开了两个标签页,其中一个页面通过窃取另一个页面的 cookie 来发送伪造的请求,因为 cookie 是随着请求自动发送到服务端的。

JWT (JSON Web Token),通过某种算法将两个 JSON 对象加密成一个字符串,该字符串能代表唯一用户。

CSRF 的产生

首先通过一个图来理解 CSRF 是什么现象。

Java,还是 Node.js,都有 response.setHeader 方法。

小结

我对 Web 安全方面的了解还不太深,所以没有太多经验可谈。安全性是一个在平常不太受重视的领域,因为完成一个项目的优先级从来都是:功能 > 颜值 > 性能, 安全 。至少得保证用户在使用过程中不会出错,然后再做得酷炫或清新一点,性能和安全只有在满足了前两项,或者迫在眉睫的时候才去考虑。当服务器承受不了那么高 的负载了,才会去增加更多的服务器,但业务功能从一开始就不能少。

可是这样做有错吗?并没有吧。在特定的场景,做特定的处理,或许是性价比最高的决策了。

这篇文章中反复提到的一个词是“ 约定 ”,它貌似和“ 具体情况具体分析 ”这个观点矛盾了,额……。

约定是人与人之间的共识,比如说 GET 请求,那么对方的第一反应就是查询,当有人破坏约定,用 GET 请求去做删除操作时,就会让别人很难理解(当有一大堆人这么做的时候,就不难理解了吧……)。或者当我们提到 JWT 的时候,那它就应该是由三个部分组成,如果有人仅仅是按照自己的算法来生成一个 token,同样可以唯一标识用户,那他必须得像共事的人解释,这个算法的安全性、使用方法等。

另一方面,如果真心觉得按照“约定”办事没必要,太麻烦,并且可以接受“耍小聪明”的后果的话,那就按自己的想法去做吧(真的不再考虑一下了吗)。

为什么 HTML5 新增了那么多语义化的标签,是因为一切都在朝着更规范的方向走。

 

http://www.2cto.com/Article/201509/441863.html

转载于:https://my.oschina.net/xiaominmin/blog/1599079

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值