放 cookie 中,但是后端不读 cookie
所有请求需要前端把 token 放到 header 中一个参数下
后端读 header 中的这个参数
这样是不是就可以放置 csrf 攻击了呢?
第三方直接通过服务链接带 cookie 过来,因为后端不读取,所以鉴权不通过
最新回复 (7)
  • zzNucker4月前
    引用2
    存 cookie, header, html 都可以
  • ss0984月前
    引用3
    你是不是在找 OAuth 2.0 Bearer token ?
  • yinmin4月前
    引用4
    常见这 2 种方式吧:
    方式一:csrf token 放服务器的 session ,然后前端传 token (header 、post 参数、get 参数都可以)做对比
    方式二:csrf token 放 cookie 里(设置成 httponly 和 secure),然后前端传 token (header 、post 参数、get 参数都可以)做对比

    方式一的服务器 session 容易丢失,我是推荐方式二,可以做成无服务器状态模式。
  • happyxhw1014月前
    引用5
    一般放在 header 里面可以防止 csrf 攻击,
    如果是放在 cookie 里面,那需要单独生成一个 csrf token ,前端用 js 把 csrf token 放在 header 里面,同时生成一个值是 csrf token 的 cookie ,后端收到请求比较 header 和 cookie 里面的值,这种也是常规手段,但也不能做到 100%
  • Belmode4月前
    引用7
    我觉得 CSRF 无非是避免浏览器,在非法跨站请求携带默认参数时,导致的权限问题。那`认证信息`放哪都无所谓了,放 cookie 也可以,放本地存储也可以,提交的时候放 header 也行,放 cookie 也行。只要保证存储和使用时有标记不一样,并且服务端只认带这个标记的`认证信息`。

    楼上说的,Bearer Token 就是。`认证信息`存任何地方都行,但是放在请求头上时,Authorization: Bearer <token>。这样就确保,是自己站点的页面执行了 js 发送的请求,不是跨站请求。

    所以用 OAuth2.0 之类的认证方式,只要提交请求认证信息时做点不一样的操作,都不用特别考虑 CSRF 攻击,因为从机制上已经避免了。
  • Belmode4月前
    引用8
    @Belmode OP 提问中的疑问的答案是肯定的。你那样操作,是可以避免 CSRF 攻击的。
  • 回复请 登录 or 快速注册
返回