HTTP_REFERER 可以伪造，怎样有效防止盗链呢

[cc959798]

如题，多谢诸位

[lhx2008]

正常浏览器是不能伪造的，所以前端调用不用担心。
但是，非浏览器要抓你的资源，你怎么搞都没用。

[msg7086]

呃，盗链者如何用浏览器伪造 REFERER ？

[580a388da131]

参考百度网盘和用户的攻防战
结论就是没什么好方法 做好检测预警吧

[lihongming]

随机限时文件名、限制下载速度、下载间隔、单 IP 连接数等。
总之一个原则——给用户增加麻烦，麻烦到没人愿用你的产品，就可以了。具体参考 upload 等国外各种文件分享服务。

[yhvictor]

@lhx2008 JavaScript 不能伪造么？之前准备给 discuz 通过 Mobile API 写个第三方客户端。验证码需要 refer。
懒癌一直没动，要是不行或者很麻烦我就不写了。

[t6attack]

如果是 网站 防 其他网站 盗链（客户端仅限浏览器），通过 REFERER 就足够了。对方可以通过服务端盗链，但这意味着消耗双倍带宽资源。而且对方的服务端 IP 你可以随时封掉。。还有一个方式，是发出文章，教每个网站访客修改 HTTP 请求头，这是不小的折腾成本。
如果是防 客户端 盗链？（ APP、桌面软件，拥有软件级别的权限），这种无解。理论上，资源能浏览，就能盗链。看谁肯花更多时间折腾了。

[t6attack]

网页中的 JS 是运行在 HTTP 通道之内的，它没有权限触碰和修改 HTTP 请求头内容。
想要伪造 REFERER 之类的头信息，通过 JS 是不行的，一定需要浏览器之外的“软件级别”权限（浏览器扩展、独立 APP、服务端....这些）。你自己可以通过这些伪造 REFERER 抓取信息，但无法做到让你的网站访客也看到这些。除非你挨个“教”他们安装扩展、修改请求头。
所以防其他网站盗链，通过 REFERER 足够了。同理，软件级别的盗链，你防不了。

[webdisk]

@t6attack #17 准确的说是部分 HTTP 请求头 无法修改。

禁止修改的消息首部包括以 Proxy- 和 Sec- 开头的消息首部，以及下面列出的消息首部：

Accept-Charset
Accept-Encoding
Access-Control-Request-Headers
Access-Control-Request-Method
Connection
Content-Length
Cookie
Cookie2
Date
DNT
Expect
Host
Keep-Alive
Origin
Proxy-
Sec-
Referer
TE
Trailer
Transfer-Encoding
Upgrade
Via

https://developer.mozilla.org/zh-CN/docs/Glossary/%E7%A6%81%E6%AD%A2%E4%BF%AE%E6%94%B9%E7%9A%84%E6%B6%88%E6%81%AF%E9%A6%96%E9%83%A8

[o0]

任何方式应该都只是增加成本吧，之前看到过这个。
https://cloud.tencent.com/document/product/228/13677

[cc959798]

@msg7086 前端写脚本呀，伪造 header

[killerv]

用这个判断足够了，防盗链不是说让对方无法访问，而是不能在对方域名上请求该资源。

[morethansean]

@cc959798 前端写啥脚本？难道是不在浏览器里跑的脚本？楼上不都说了吗 referer 这种 header 前端是不能更改的。

[ThirdFlame]

前端是不能改，但是 上个 burpsuite/fiddler 没啥不能改的。

[won]

防盗链不是单一的技术手段。虽说没有不可破的系统，但用一个开源模块和国际大企业花几千万做的防盗链方案根本不具有可比性。总之首先要看预算

[imn1]

主要问题是「盗」是一个法律定义，并非一个行为定义。在网络上无法通过判断行为的方式来判断它是「盗」还是「取」，还是要通过授权方式来判断

[cc959798]

@morethansean 呃呃，这个中国大量的 IE 是可以改变的，如果是手机 APP 也是可以，不过成本也变高了