如何通过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