当前位置: 首页 > article >正文

因浏览器未发送Referer HTTP头导致Django项目CSRF验证失败的原因

问题

前段时间,做了一次服务器减负的同时,也把所有的遗留网站都加上了 HTTPS 支持,让客户免受推荐 HTTPS 证书销售公司的电话骚扰(他们的话术很吓人,客户听了以后会害怕地找我,这就很让我烦心了)。

因为遗留的都是企业官网,很少人会登陆更新内容,所以很久以后,客户才来联系我说后台登陆不上了。我一试,发现出现了 403 错误:

禁止访问 (403)

CSRF验证失败. 请求被中断.

您看到此消息是由于HTTPS站点需要浏览器发送 ‘Referer HTTP头‘,但是目前没有被发送。出于安全考虑,浏览器必须发送该HTTP头,以确保您的浏览器没有被第三方劫持。

如果您已经设置浏览器禁用 ‘Referer’ 头,请重新启用,至少针对这个站点,全部HTTPS请求,或者同源请求(same-origin)启用发送该HTTP头。

更多信息请设置选项DEBUG=True。

探索

奇哉!我记得我们的Django项目一直是有做 CSRF 验证的。但不管三七二十一,先爬上服务器看看。配置文件里的corsheaders.middleware.CorsMiddlewarecorsheaders都好好地躺在MIDDLEWAREINSTALLED_APPS配置项里。

重新看出错信息,有一段如果您已经设置浏览器禁用 ‘Referer’ 头,请重新启用,这很是奇怪。都不知道浏览器还能禁用 Referer 头,搜索也找不到相关配置。搞得一头雾水,好不头大!

复制CSRF验证失败. 请求被中断.去搜索,也是一些关于开启Cookies和需要在form表单中增加{% csrf_token %}字段之类的常规方法,根据没有和Referer HTTP头 相关的片段,而这些提及的方向我们都已经做好了。

端倪

看来只能使用找Bug的根本大法:看源代码了。打开目录发现重载了页码模板,打开页面模板搜索referer关键字,并无收获。再仔细看,发现还重载了base.html这个基础页面,再找开就发现里面有一行:

<meta name="referrer" content="never">

一看这行,就知道是控制了当发送 HTTP 请求的时候,不要发送Referer头了!

把这一行去掉,再测试,果然解决问题。然后查阅参考文档,发现这个 meta 项的默认值是:strict-origin-when-cross-origin,于是重新改回:

<meta name="referrer" content="strict-origin-when-cross-origin">

测试可用,提交代码。收工。

小结

不知道为什么会出现这样的错误,想来可能是之前的同事从别处直接复制了一个文件,遗留了快十年吧。估计也不会有其他人遇到同样的情况,在此记之以自娱矣。


http://www.kler.cn/news/335593.html

相关文章:

  • JavaScript中的(this)指向问题(如何正确判断this,箭头函数的this是什么)
  • 在 window 系统下安装 Ubuntu (虚拟机)
  • Maven的生命周期与依赖作用域介绍
  • Spring Data JPA
  • 大数据新视界 --大数据大厂之深度优化 Alluxio 分层架构:提升大数据缓存效率的全方位解析
  • 调试意义、步骤及方式
  • FreeRTOS列表与列表项
  • VRRP协议个人理解+报文示例+典型配置-RFC2338/RFC3768/RFC5798/RFC9568
  • 速盾:如何判断高防服务器的防御是否真实?
  • 计算机网络思维导图
  • 人工智能专业就业方向与前景
  • 怎么查看网站是否被谷歌收录,查看网站是否被搜索引擎收录5个方法与步骤
  • stm32四足机器人(标准库)
  • 「轻盈」之旅:OOM故障重现与解决
  • Kafak入门技术详解
  • Django对接支付宝沙箱环境(2024年9月新测有效)
  • expressjs,MySQL,实现分页查询接口
  • 中间件介绍
  • 在Ubuntu 16.04上使用Logrotate管理日志文件
  • 【ECMAScript 从入门到进阶教程】第三部分:高级主题(高级函数与范式,元编程,正则表达式,性能优化)