跨站请求伪造(Cross-site request forgery), 简称为 XSRF,是 Web 应用中常见的一个安全问题。前面的链接也详细讲述了 XSRF 攻击的实现方式。
当前防范 XSRF 的一种通用的方法,是对每一个用户都记录一个无法预知的 cookie 数据,然后要求所有提交的请求(POST/PUT/DELETE)中都必须带有这个 cookie 数据。如果此数据不匹配 ,那么这个请求就可能是被伪造的。
beego 有内建的 XSRF 的防范机制,要使用此机制,你需要在应用配置文件中加上 enablexsrf
设定:
enablexsrf = true
xsrfkey = 61oETzKXQAGaYdkL5gEmGeJJFuYh7EQnp2XdTP1o
xsrfexpire = 3600
或者直接在 main 入口处这样设置:
web.EnableXSRF = true
web.XSRFKEY = "61oETzKXQAGaYdkL5gEmGeJJFuYh7EQnp2XdTP1o"
web.XSRFExpire = 3600 //过期时间,默认1小时
如果开启了 XSRF,那么 beego 的 Web 应用将对所有用户设置一个 _xsrf
的 cookie 值(默认过期 1 小时),如果 POST PUT DELET
请求中没有这个 cookie 值,那么这个请求会被直接拒绝。如果你开启了这个机制,那么在所有被提交的表单中,你都需要加上一个域来提供这个值。你可以通过在模板中使用 专门的函数 XSRFFormHTML()
来做到这一点:
过期时间上面我们设置了全局的过期时间 web.XSRFExpire
,但是有些时候我们也可以在控制器中修改这个过期时间,专门针对某一类处理逻辑:
func (this *HomeController) Get(){
this.XSRFExpire = 7200
this.Data["xsrfdata"]=template.HTML(this.XSRFFormHTML())
}
在 Beego 2.x 里面有一个很大的不同,就是 Beego 2.x 的XSRF只支持 HTTPS 协议。
这是因为,在 2.x 的时候,我们给存储 XSRF token的 cookie 加上了 secure, http-only.
两个设置,所以只能通过 HTTPS 协议运作。
与此同时,你也无法通过 JS 获取到 XSRF token。
这个改进,一个很重要的原因是,在 1.x 的时候,缺乏这两个选项,会导致攻击者可以从 cookie 中拿到 XSRF token,导致 XSRF 失效。
XSRF 之前是全局设置的一个参数,如果设置了那么所有的 API 请求都会进行验证,但是有些时候API 逻辑是不需要进行验证的,因此现在支持在controller 级别设置屏蔽:
type AdminController struct{
web.Controller
}
func (a *AdminController) Prepare() {
a.EnableXSRF = false
}
beego 支持自定义过滤中间件,例如安全验证,强制跳转等。
过滤器函数如下所示:
web.InsertFilter(pattern string, pos int, filter FilterFunc, opts ...FilterOpt)
InsertFilter 函数的三个必填参数,一个可选参数
*
/api/*
的 filter,同时又设置了 /api/docs/*
的 router,那么在访问 /api/docs/swagger/abc.js
的时候,在执行 filters 的时候设置 :splat
参数为 docs/swagger/abc.js
,但是如果不清楚 filter 的这个路由参数,就会在执行路由逻辑的时候保持 docs/swagger/abc.js
,如果设置了 true,就会重置 :splat
参数.如下例子所示,验证用户是否已经登录,应用于全部的请求:
var FilterUser = func(ctx *context.Context) {
_, ok := ctx.Input.Session("uid").(int)
if !ok && ctx.Request.RequestURI != "/login" {
ctx.Redirect(302, "/login")
}
}
web.InsertFilter("/*", web.BeforeRouter, FilterUser)
这里需要特别注意使用 session 的 Filter 必须在 BeforeStatic 之后才能获取,因为 session 没有在这之前初始化。
还可以通过正则路由进行过滤,如果匹配参数就执行:
var FilterUser = func(ctx *context.Context) {
_, ok := ctx.Input.Session("uid").(int)
if !ok {
ctx.Redirect(302, "/login")
}
}
web.InsertFilter("/user/:id([0-9]+)", web.BeforeRouter, FilterUser)
beego1.1.2 开始 Context.Input 中增加了 RunController 和 RunMethod, 这样我们就可以在执行路由查找之前,在 filter 中实现自己的路由规则.
如下示例实现了如何实现自己的路由规则:
var UrlManager = func(ctx *context.Context) {
// 数据库读取全部的 url mapping 数据
urlMapping := model.GetUrlMapping()
for baseurl,rule:=range urlMapping {
if baseurl == ctx.Request.RequestURI {
ctx.Input.RunController = rule.controller
ctx.Input.RunMethod = rule.method
break
}
}
}
web.InsertFilter("/*", web.BeforeRouter, web.UrlManager)
在 v1.x 的设计中,Filter 并不能直接调用下一个 Filter。这导致了我们无法解决一个问题,即我们希望这个 Filter 能够在代码执行前后都执行一段逻辑。
例如,在考虑接入Opentracing
和prometheus
的时候,我们就遇到了这种问题。
考虑到这是一个通用的场景,我们在已有 Filter 的基础上,支持了Filter-Chain
设计模式。
type FilterChain func(next FilterFunc) FilterFunc
例如一个非常简单的例子:
package main
import (
"github.com/beego/beego/v2/core/logs"
"github.com/beego/beego/v2/server/web"
"github.com/beego/beego/v2/server/web/context"
)
func main() {
web.InsertFilterChain("/*", func(next web.FilterFunc) web.FilterFunc {
return func(ctx *context.Context) {
// do something
logs.Info("hello")
// don't forget this
next(ctx)
// do something