首页>Firefox 专区>Firefox 正式版和测试版>Firefox链接的download属性同源策略是不是太严格...
回复
« 返回列表
白左
白左
千年狐狸
千年狐狸
  • UID34985
  • 注册日期2010-12-29
  • 最后登录2024-12-29
  • 发帖数2039
  • 经验655枚
  • 威望0点
  • 贡献值364点
  • 好评度69点
写私信
  • 社区居民
  • 忠实会员
阅读：3025回复：8

Firefox链接的download属性同源策略是不是太严格了？

楼主#
更多 发布于：2017-07-01 12:22
测试页面



<!doctype html>
<head>
        <meta charset="UTF-8" />
</head>
<body>
        <a id="downladImgLink" download="logo.png" href="https://ss0.bdstatic.com/5aV1bjqh_Q23odCf/static/superman/img/logo/logo_white.png">图片链接（有download属性）</a>
        ＜br/>
        <a id="normalImgLink" href="https://ss0.bdstatic.com/5aV1bjqh_Q23odCf/static/superman/img/logo/logo_white.png">图片链接（无download属性）</a>
</body>
</html>



Chrome点击第一个时，会下载百度的logo；点第二个时，会打开百度logoFirefox总是打开logo


根据bug 676619 的说明，是因为fx只允许下载同源的文件。然而即使你通过控制台，在百度主页添加上面第一个<a>，同样无法弹出下载，因为图片存放在bdstatic.com上，被认为和baidu.com不同源。所以，任何把多媒体资源存在CDN上的网页，download属性都没用


要说有什么影响，最大的影响就是想在某些图片网站用油猴脚本写个一键下载图片的按钮/链接的话，如果图片放在CDN上，用chrome只需要加个download属性，用fx却必须借助油猴的xmlhttprequest获取图片二进制数据文本，再手动转换为二进制数组，再生成为blob链接，再添加到下载按钮/链接上……超麻烦


话说论坛的code标签能不能修一修，完全没用，还把＜br/>给识别了
喜欢0
-いたんですか？ -ええ、ずっと
回复
aaaa007cn
aaaa007cn
千年狐狸
千年狐狸
  • UID23968
  • 注册日期2008-05-03
  • 最后登录2022-03-07
  • 发帖数1924
  • 经验1138枚
  • 威望1点
  • 贡献值232点
  • 好评度164点
写私信
1楼#
发布于：2017-07-01 20:08
bug 676619 逻辑上没毛病
不能因为 Google 那么做就说谋智这么做不对
你个人方不方便不影响谋智决策

你还不如投票重启 bug 874009 实现 download 属性的 CORS 支持呢
How To Ask Questions The Smart Way | 提问的智慧

2 + 2 = 5
回复(1) 喜欢(0)
白左
白左
千年狐狸
千年狐狸
  • UID34985
  • 注册日期2010-12-29
  • 最后登录2024-12-29
  • 发帖数2039
  • 经验655枚
  • 威望0点
  • 贡献值364点
  • 好评度69点
写私信
  • 社区居民
  • 忠实会员
2楼#
发布于：2017-07-02 11:11
aaaa007cn：bug 676619 逻辑上没毛病
不能因为 Google 那么做就说谋智这么做不对
你个人方不方便不影响谋智决策

你还不如投票重启 bug 874009 实现 download 属性的 CORS 支持呢回到原帖
再仔细看了看，mozilla的考虑确实有道理

bug 874009只说让看bug 676619，但bug 676619讨论太长太专业了，能大致讲一讲为什么mozilla认为download属性即使是符合CORS的跨域也是有安全风险的吗？


就像#5说的一样（同时也是顶楼所使用的方法），ajax请求资源然后把href改成blob，同样可以达到相同的结果，和直接让download属性顺从CORS设置有何不同？
#6的回答没看懂什么意思

The difference is the ajax call enforces same-origin or CORS opt-in.
I suppose we could do something where @download is considered for cross-origin but CORS is then enforced...
-いたんですか？ -ええ、ずっと
回复(0) 喜欢(0)
aaaa007cn
aaaa007cn
千年狐狸
千年狐狸
  • UID23968
  • 注册日期2008-05-03
  • 最后登录2022-03-07
  • 发帖数1924
  • 经验1138枚
  • 威望1点
  • 贡献值232点
  • 好评度164点
写私信
3楼#
发布于：2017-07-02 12:10
676619 逻辑没问题
只是因为 Google 反对在这个场景使用 CORS 而放弃了进一步讨论（从 #c7 开始看，7 年前）
并最终只做了 same origin 的第一个实现（从 #c46 开始，5 年前）
事实上，#c40（5 年前）确实说了可以考虑 CORS

才注意到 874009 不是仅针对 CORS 的
只有最后才提到

还有个由此功能的实现者 Tom Schuster（676619 #c46）开的 923415，重新评估 download 属性的风险
How To Ask Questions The Smart Way | 提问的智慧

2 + 2 = 5
回复(1) 喜欢(0)
白左
白左
千年狐狸
千年狐狸
  • UID34985
  • 注册日期2010-12-29
  • 最后登录2024-12-29
  • 发帖数2039
  • 经验655枚
  • 威望0点
  • 贡献值364点
  • 好评度69点
写私信
  • 社区居民
  • 忠实会员
4楼#
发布于：2017-07-02 14:02
aaaa007cn：676619 逻辑没问题
只是因为 Google 反对在这个场景使用 CORS 而放弃了进一步讨论（从 #c7 开始看，7 年前）
并最终只做了 same origin 的第一个实现（从 #c46 开始，5 年前）
事实上，#c40（...回到原帖
mozilla是担心在钓鱼网站，download指向满足CORS的次级站点（不能总是保证安全）的链接？
676619 的#c7里说google反对，这个有没有前情提要？google又是考虑的什么反对在download属性应用CORS呢（然而chrome现在明明可以识别跨域download属性）


bug 923415的#c7正是我的疑惑，不过我不是很同意他#c12的观点，直接点击链接和主动右键下载应该不能完全等同起来，前者不能代表明确的下载意愿


……一圈看下来表示更迷糊了，假如是在A站有个指向B站资源的链接：
1. 如果攻击者攻击B站，那么攻击者直接把响应的类型改成application/octet-stream就行了，不管有没有download属性，用户点击链接都会执行下载动作
2. 如果攻击者攻击A站，那就更危险了，想干什么都可以，download属性不管怎么设都不重要了，例如以下示例：



<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8" />
    <title>www.secure-site-A.com</title>
</head>
<body>
    <a class="safe-link" href="https://www.secure-site-B.com/SafeFile.exe">Safe Download</a>
    <script class="injected">
        let fakeLink = document.querySelector(".safe-link");
        fakeLink.addEventListener('click', Evil, true);
        
        function Evil(e){
            e.preventDefault();
            e.stopPropagation();
            
            let evilUrl = URL.createObjectURL(new Blob(["evil content"], {type:"application/octet-stream;characterSet=UTF-8"}));
            var evilLink = document.createElement("a");
            evilLink.href = evilUrl;
            evilLink.download = 'SafeFile.exe';
            document.body.appendChild(evilLink);
            
            evilLink.click();
        }
    </script>
</body>
</html>
在这个例子中，作为被攻击的A站，有个指向B站的链接，地址是B站的，文件名也是B站的，可是实际下载的文件却可能是任意内容


总而言之，就是即使download属性限制只能同源，通过松限制的xhr也能够实现跨域下载，效果如同限制为跨域的download属性
以我的理解，在这方面继续限制download的跨域能力就像在有一块短木板的桶上加高另一块木板，水要漏的话，肯定还是从短的那一块漏啊
-いたんですか？ -ええ、ずっと
回复(0) 喜欢(0)
aaaa007cn
aaaa007cn
千年狐狸
千年狐狸
  • UID23968
  • 注册日期2008-05-03
  • 最后登录2022-03-07
  • 发帖数1924
  • 经验1138枚
  • 威望1点
  • 贡献值232点
  • 好评度164点
写私信
5楼#
发布于：2017-07-02 21:13
> mozilla是担心在钓鱼网站，download指向满足CORS的次级站点（不能总是保证安全）的链接？
在提到 Google 反对在这个场景使用 CORS 之后就放弃讨论了
鬼知道他们担心什么

> 676619 的#c7里说google反对，这个有没有前情提要？google又是考虑的什么反对在download属性应用CORS呢（然而chrome现在明明可以识别跨域download属性）
不知道
chrome 早前的实现根本就不管链接指向哪里，更何况 CORS？
现在怎么不清楚
根据你顶楼测试
应该还是完全无视同不同源
How To Ask Questions The Smart Way | 提问的智慧

2 + 2 = 5
回复(0) 喜欢(0)
aaaa007cn
aaaa007cn
千年狐狸
千年狐狸
  • UID23968
  • 注册日期2008-05-03
  • 最后登录2022-03-07
  • 发帖数1924
  • 经验1138枚
  • 威望1点
  • 贡献值232点
  • 好评度164点
写私信
6楼#
发布于：2017-07-02 21:21
谋智担心的问题是 A 网站本身 *主动* 作为攻击者
比如让用户以为下载的是 A 站的内容
但那其实是来包含有重要私人信息的 B 网站
然后无意识上传回 A 网站
How To Ask Questions The Smart Way | 提问的智慧

2 + 2 = 5
回复(1) 喜欢(0)
白左
白左
千年狐狸
千年狐狸
  • UID34985
  • 注册日期2010-12-29
  • 最后登录2024-12-29
  • 发帖数2039
  • 经验655枚
  • 威望0点
  • 贡献值364点
  • 好评度69点
写私信
  • 社区居民
  • 忠实会员
7楼#
发布于：2017-07-03 08:18
aaaa007cn：谋智担心的问题是 A 网站本身 *主动* 作为攻击者
比如让用户以为下载的是 A 站的内容
但那其实是来包含有重要私人信息的 B 网站
然后无意识上传回 A 网站回到原帖
有点明白了, 是不是点击链接下载的时候, 浏览器会后台发送相应cookie？
所以mozilla担心以下场景：

恶意网站A提供了一个链接<a href="hrrp://www.icbc.com.cn/我的帐号密码.cgi" download="性能分析.extenstionthatlooksexpert">下载报告</a>
网站A假装在检测用户电脑, 声称点击以上链接即可下载分析报告, 上传检测报告即可由专业软件分析结果, 并且还送积分送话费
用户点击链接, 保存了扩展名不认识的"性能分析", 然后上传给了网站A

如果是xhr/fetch, 网站A运行的脚本无法获取工商银行的cookie, 所以是做不到的
如果是引导用户右键保存, 用户看见的文件名是"我的帐号密码.cgi", 可能会提高警惕
-いたんですか？ -ええ、ずっと
回复(0) 喜欢(0)
aaaa007cn
aaaa007cn
千年狐狸
千年狐狸
  • UID23968
  • 注册日期2008-05-03
  • 最后登录2022-03-07
  • 发帖数1924
  • 经验1138枚
  • 威望1点
  • 贡献值232点
  • 好评度164点
写私信
8楼#
发布于：2017-07-03 12:26
点击链接的时候
就是一个普通的 GET 请求
当然会带上 cookie

至于是跳下载框还是直接在浏览器中打开那得看服务器的回应和这个 download 的属性
具体去翻 spec 吧（WHATWG 和 w3c 的）
包括默认的文件名如何决定
都在 spec 中写明了
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a

xhr/fetch 无法跨域
A 网站上往 B 网站的 xhr/fetch 如果不满足 CORS
是拿不到响应的
不用考虑 cookie 的问题
How To Ask Questions The Smart Way | 提问的智慧

2 + 2 = 5
回复(0) 喜欢(0)
游客

关于FirefoxMozilla 技术支持谋智中国手机版(Beta)了解 Mozilla

返回顶部