如果表单数据边界包含在附件中怎么办？

Posted 2023-03-05

【中文标题】如果表单数据边界包含在附件中怎么办？

【英文标题】：What if the form-data boundary is contained in the attached file?

【发布时间】：2015-06-14 21:04:08

【问题描述】：

下面以multipart/form-datataken from w3.com为例：

Content-Type: multipart/form-data; boundary=AaB03x

--AaB03x
Content-Disposition: form-data; name="submit-name"

Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain

... contents of file1.txt ...
--AaB03x--

这很简单，但是假设您正在编写代码来实现它并从头开始创建这样的请求。假设file1.txt 是由用户创建的，我们无法控制其内容。

如果文本文件file1.txt 包含字符串--AaB03x 怎么办？您可能会随机生成边界AaB03x，但我们假设"million monkeys entering a million web forms" 场景。

是否有一种标准方法来处理这种不太可能但仍有可能发生的情况？

是否应该对text/plain（甚至可能类似于image/jpeg 或application/octet-stream）进行“编码”或以某种方式“转义”中的某些信息？

或者开发者应该一直在文件的内容中搜索边界，然后反复不断地选择一个新的随机生成的边界，直到在文件中找不到所选择的字符串？

【问题讨论】：

@DavidPostill 我觉得这里的主题比 *** 上的更多，因为这是关于 HTTP 规范的问题。我对真正开发一个生成器/解析器不太感兴趣，而更感兴趣的是学习如何（或者即使）这个“边缘情况”已经解决了。

“假设您正在编写实现此功能的代码”...“开发人员应该”...“已被其他人解决”->Stack Overflow 是开发人员闲逛的地方...

这不在 HTTP 规范中，而是在 Mime 规范 中。边界是一个多部分的工件。

【参考方案1】：

HTTP 委托 MIME RFC 在此处定义 multipart/ 类型。规则在RFC 2046 section 5.1中列出。

RFC 只是声明边界不能出现：

边界 定界符不得出现在任何封装部分内，在 行单独或作为任何行的前缀。这意味着它是 作曲代理能够选择和指定一个至关重要的 不包含边界的唯一边界参数值 作为前缀的封闭多部分的参数值。

和

注意：因为边界分隔符不能出现在正文部分 被封装后，用户代理必须小心选择一个 唯一的边界参数值。边界参数值 上面的例子可能是一个算法设计的结果 以非常低的概率生成边界分隔符 存在于要封装的数据中，而无需预先扫描 数据。替代算法可能会导致更“可读”的边界 具有旧用户代理的收件人的分隔符，但需要 更多地注意边界分隔符可能 出现在封装部分某行的开头。这 最简单的边界分隔线可能类似于“---”， 带有“-----”的闭合边界分隔线。

大多数 MIME 软件只是简单地生成一个随机边界，使得该边界出现在部件中的概率统计上不太可能；例如可能会发生碰撞，但发生这种情况的可能性是如此之低以至于不可行。电脑UUID values 依赖同样的原理；如果您在一年内生成数万亿个 UUID，则生成两个相同 UUID 值的概率与某人被陨石击中的概率大致相同，两者都有 170 亿分之一的机会。

请注意，您通常将二进制数据编码为某种形式的 ASCII 安全编码，例如 base64，这种编码不包含破折号，从而消除了二进制数据包含边界的可能性。

因此，处理这种可能性的标准方法是简单地将可能性降低到几乎没有。如果计算机存储电子邮件被陨石击中的可能性更大，为什么还要担心 MIME 边界？

【讨论】：

HTTP 在这里无关紧要；相关的是 IANA 媒体类型注册表中 multipart/form-data 的定义；这指的是 RFC 2388。

@JulianReschke：RFC 2388 是特定的 multipart/ 子类型；它仍然不能确定如何选择边界。这被委托给一般 MIME RFC。我确实注意到我在这里引用了一个过时的 RFC。我更新为使用最新的 RFC。