Open xiongwilee opened 7 years ago
完全客户端渲染,使用ajax请求后端数据。没有nodejs作为服务端,这怎么生成页面的token?让静态服务器生成?再提交到后端服务器?
@LikeDege 好问题,一般页面初始化的时候,不都有一个get请求来获取数据嘛,可以在这里获取token
token参数必须由前端处理之后交给后端
一般前端还需要做什么处理呢? ajax每个请求都挂上token,会有个httpProxy func吧,这样就不用每个请求都加token了。
@liuzy0404 不太明白你的意思~
这里讨论的主要是,通过 客户端-》node层-内网-》服务端
这个流程里客户端-》node层
做简单可行csrf防御的方案
@xiongwilee 我的意思是,前端拿到token后发送ajax请求,这个token传原值,还是需要再加工一下。 下面那句是统一管理ajax请求,想当年我可是每个页面每条请求都加了一遍token...
服务端生成token传给客户端, 客户端把这个token放入header里 再请求 后端, 如果这个时候 这个请求被劫持了,改点请求参数,token 到后台还是照样验证通过
服务端生成token传给客户端, 客户端把这个token放入header里 再请求 后端, 如果这个时候 这个请求被劫持了,改点请求参数,token 到后台还是照样验证通过
上HTTPS
背景
1、什么是CSRF攻击?
这里不再介绍CSRF,已经了解CSRF原理的同学可以直接跳到:“3、前后端分离下有何不同?”。
不太了解的同学可以看这两篇对CSRF介绍比较详细的参考文章:
如果来不及了解CSRF的原理,可以这么理解:有一个人发给你一个搞(mei)笑(nv)图片链接,你打开这个链接之后,便立刻收到了短信:你的银行里的钱已经转移到这个人的帐户了。
2、有哪些防御方案?
上面这个例子当然有点危言耸听,当然可以确定的是确实会有这样的漏洞:你打开了一个未知域名的链接,然后你就自动发了条广告帖子、你的Gmail的邮件内容就泄露了、你的百度登录状态就没了……
防御方案在上面的两篇文章里也有提到,总结下,无外乎三种:
第一种方案明显严重影响了用户体验,而且还有额外的开发成本;第二种方案成本最低,但是并不能保证100%安全,而且很有可能会埋坑;第三种方案,可取!
token验证的CSRF防御机制是公认最合适的方案,也是本文讨论的重点。
3、前后端分离下有何不同?
《CSRF 攻击的应对之道》这篇文章里有提到:
我们前端架构早已经告别了服务端语言(PHP/JAVA等)绑定路由、携带数据渲染模板引擎的方式(毕竟是2011年的文章了,我们笑而不语)。
当然, 前端不要高兴的太早:前后端分离之后,Nodejs不具备完善的服务端SESSION、数据库等功能。
总结一下,在“更先进”的前端架构下,与以往的架构会有一些区别:
实现思路
如上文提到,这里仅仅讨论在“更先进”的前端后端架构背景下的token防御方案的实现。
1、可行性方案
token防御的整体思路是:
上文提到过,前后端分离状态下,Nodejs是不具备SESSION功能的。那这种token防御机制是不是就无法实现了呢?
肯定不是。我们可以借助cookie把这个流程升级下:
当然这样实现也有需要注意的:
现在方案确定了,具体该如何实现呢?
2、具体实现
我们的技术栈是
koa(服务端)
+Vue.js(前端)
。有兴趣可以看这些资料:在服务端,实现了一个token生成的中间件,koa-grace-csrf:
在前端代码中,对发送ajax请求的封装稍作优化:
总结一下:
这里依旧有个细节值得提一下:Nodejs的上层一般是nginx,而nginx默认会过滤头信息中不合法的字段(比如头信息字段名包含“_”的),这里在写头信息的时候需要注意。
"One more thing..."
上文也提到,通过cookie及http头信息传递加密token会有很多弊端;有没有更优雅的实现方案呢?
1、cookie中samesite属性
回溯下CSRF产生的根本原因:cookie会被第三方发起的跨站请求携带,这本质上是HTTP协议设计的漏洞。
那么,我们能不能通过cookie的某个属性禁止cookie的这个特性呢?
好消息是,在最新的RFC规范中已经加入了“samesite”属性。细节这里不再赘述,可以参考:
2、更优雅的架构
当然,目前为止,客户端对samesite属性的支持并不是特别好;回到前后端分离架构下,我们明确下前后端分离框架的基本原则:
后端(Java / PHP )职责:
前端(Nodejs + Javascript)职责:
我们提到,
前端Nodejs层不负责实现任何SESSION和数据库功能
,但有没有可能把后端缓存系统做成公共服务提供给Nodejs层使用呢?想想感觉前端整条路都亮了有木有?!这里先挖一个坑,后续慢慢填。3、延伸
这里再顺便提一下,新架构下的XSS防御。
犹记得,在狼厂使用PHP的年代,经常被安全部门曝出各类XSS漏洞,然后就在smaty里添加各种
escape
滤镜,但是添加之后发现竟然把原始数据也给转义了。当然,现在更多要归功于各种
MVVM
单页面应用:使得前端完全不需要通过读取URL中的参数来控制VIEW。不过,还有一点值得一提:前后端分离框架下,路由由Nodejs控制;我自己要获取的后端参数和需要用在业务逻辑的参数,在主观上前端同学更好把握一些。
所以, 在
koa(服务端)
+Vue.js(前端)
架构下基本不用顾虑XSS问题(至少不会被全安组追着问XSS漏洞啥时候修复)。总结
要不学PHP、看Java、玩Python做全栈好了?