【问题标题】:Allowing Users To Upload ANY File. Is My Method Insecure?允许用户上传任何文件。我的方法不安全吗?
【发布时间】:2011-10-06 17:17:08
【问题描述】:

我正在创建一个文件共享网站,类似于 Megaupload 或 Rapidshare。就像提到的那些网站一样,我需要允许任何文件类型。

我正在考虑一个解决方案,并且需要知道它是否存在任何安全风险,或者是否有更好的解决方案来解决我的问题?

  1. 用户上传文件
  2. 检查文件大小,如果低于 100mb 开始上传
  3. 使用 IP、时间戳和 salt 加密文件名
  4. 存储在无法从网络访问的目录中
  5. 在数据库中存储文件名、描述和散列文件名

上传完成。现在下载:

  1. 用户请求下载
  2. 连接数据库,定位文件 ID
  3. 如果找到文件 ID,则从文件服务器位置复制文件并准备文件传输

请务必注意,任何东西都不能在服务器上运行。因此用户无法上传恶意文件并对服务器发起攻击。请求文件时,它将立即启动下载,并且永远不会运行。

现在,考虑到上述情况,上述模型中是否存在任何可能允许恶意用户攻击服务器的缺陷?

为了回答这个问题,假设网站的其余部分是安全的。

【问题讨论】:

  • 如果没有任何东西可以实际尝试执行已上传的文件,那么答案是 - 是的,您的模型是安全的。
  • @stereofrog 为什么?这里有 PHP 做不到,或者做不好的地方吗?我真的没看到
  • @stereofrog that 确实是个问题,真的。虽然有解决方案(X-Sendfile 是其中之一)。出于好奇,可以在 Linux/Apache 堆栈上运行的任何其他大型脚本语言是否以更好的方式解决了这个问题? Perl/Python/Ruby? (如果你碰巧知道)

标签: php


【解决方案1】:

这听起来不错,当然前提是它实施得当; IMO 唯一缺少的步骤是检查 3. 和 4. 之间可能的文件名冲突,和/或使用完全随机的文件名。毕竟,在这种情况下,IP 地址和时间戳并不是真正相关的信息。

在下载方面,不需要在服务器上复制文件。从秘密位置流式传输它就足够了,因为最终用户永远不会看到或访问它。

【讨论】:

  • 3 和 4 之间的冲突不太可能,但基于前 2 个字符(如 git)的 GUID 和子目录的解决方案会更好
  • @Konstantin 同意,冲突不太可能发生 - 但如果攻击者知道哈希是如何产生的,则可能有可能通过选择时间戳和 IP 来覆盖其他人的文件(尽管不可否认 不太可能和微观)。无论如何都应该有碰撞检测。
  • GUID 不会发生这种情况 - 碰撞几率与被 wolfes 吃掉的整个开发团队相同(来自 git 手册;))
  • @KonstantinPribluda 只是出于兴趣,您是否有使用基于前 2 个字符的子目录的示例。我不是 git 用户。提前致谢。
  • 众所周知,如果条目太多,unix(和 windows)目录会出现严重的性能问题 - 常见的模式是从 GUID 中取出前 2 个字符,然后对其进行 sibdirecotry。这确保了每个级别上没有太多的antries。也可以使用更细粒度的目录分段
猜你喜欢
  • 2015-04-22
  • 2016-09-03
  • 2021-06-02
  • 2011-10-20
  • 2018-01-17
  • 1970-01-01
  • 1970-01-01
  • 2014-08-14
  • 2018-03-31
相关资源
最近更新 更多