【问题标题】:Trusting "Content-Type" on File Uploads信任文件上传的“内容类型”
【发布时间】:2016-04-02 17:25:06
【问题描述】:

如果我支持我的 REST API 用户上传内容(主要是图像和视频),那么信任他们在(多部分)上传中声明的 Content-Type 是否安全?或者我是否应该对内容运行某种“媒体类型检测”(例如,使用 Apache Tika)以确保声明的媒体类型与检测到的实际媒体类型相对应?引入这个媒体类型检测步骤是不是我过于热心了?

【问题讨论】:

  • 如果他提供的任何答案都解决了问题,请接受,点赞。

标签: java rest file-upload multipartform-data


【解决方案1】:

您当然不应该盲目相信Content-type 标头或任何其他标头。这些东西应该用于告知您有关如何处理请求的决定。因此,Content-type: application/json 应该允许您将消息正文解释为 json 对象 - 然后可以将此类请求传递给 JSON 反序列化器以将其绑定到对象。

忽略Content-type 标头是错误的,因为请求正文包含看起来 像其他东西的数据。如果请求在内部不一致,那么它应该被拒绝。不发送Content-type 标头是一回事,但标头错误是另一回事。

因此,您可能想要使用某种自动检测的唯一情况应该是您没有关于内容的合理信息 - Content-Type 非常通用(例如“/ ") 或根本不存在。在这种情况下,值得决定某种自动检测是否可行或有价值。

【讨论】:

    【解决方案2】:

    您绝对应该拒绝所有缺少Content-Type 标头(以及Content-Length)或设置错误的请求。

    这绝对不是过度热心,而是保护系统。如果您对内容有怀疑,请检查它。但请记住在检查内容之前验证大小。如果你有一个代理服务器(例如 nginx),它有适当的模块来拒绝太大的请求。

    【讨论】:

      【解决方案3】:

      永远不要相信你从用户那里得到的输入。始终检查您的服务器端代码,无论是文件类型、文件大小等。使用 REST API 或 Javascript 使用户体验更流畅、更快。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2012-07-31
        • 2018-09-22
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多