URL 中保留的分号是啥？

Posted 2023-02-21

【中文标题】URL 中保留的分号是啥？

【英文标题】：What is the semicolon reserved for in URLs?URL 中保留的分号是什么？

【发布时间】：2011-01-10 22:50:03

【问题描述】：

RFC 3986 URI: Generic Syntax 规范将分号列为保留（子分隔符）字符：

reserved    = gen-delims / sub-delims

gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
              / "*" / "+" / "," / ";" / "="

“;”的保留用途是什么URI 中的分号？就此而言，其他子分隔符的用途是什么（我只知道“&”、“+”和“=”的用途）？

【参考方案1】：

Section 3.3 covers this - 这是一个不透明的分隔符，如果方便，生成 URI 的应用程序可以使用：

除了点段 层次路径，路径段是 被泛型认为是不透明的 句法。 URI 生成应用程序 经常使用保留字符 允许在段中分隔 特定方案或 取消引用处理程序特定 子组件。例如， 分号 (";") 和等于 ("=") 保留字符通常用于 分隔参数和参数 适用于该段的值。这 逗号 (",") 保留字符是 经常用于类似目的。为了 例如，一个 URI 生产者可能使用 段如“name;v=1.1”到 表示对 1.1 版的引用 “名称”，而另一个可能使用 段如“name,1.1”来表示 相同。参数类型可能是 由特定于方案的语义定义， 但在大多数情况下，a 的语法 参数是特定于 URI 的实现 解引用算法。

【讨论】：

什么是“不透明分隔符”？它以什么方式不透明？

【参考方案2】：

3.3节末尾有说明。

除了点段 层次路径，路径段是 被泛型认为是不透明的 句法。 URI 生成应用程序 经常使用保留字符 允许在段中分隔 特定方案或 取消引用处理程序特定 子组件。例如， 分号 (";") 和等于 ("=") 经常使用保留字符 分隔参数和参数 适用于该段的值。 逗号 (",") 保留字符是 常用于类似目的。 例如，一个 URI 生产者可能 使用诸如“name;v=1.1”之类的段 表示对 1.1 版的引用 “名称”，而另一个可能 使用诸如“name,1.1”之类的段来 表示相同。参数类型 可以由特定于方案的定义 语义，但在大多数情况下 参数的语法特定于 URI 的实现 解引用算法。

换句话说，它是保留的，以便想要在 URL 中分隔列表的人可以安全地使用 ; 作为分隔符，即使部分包含 ;，只要内容是百分比编码的.换句话说，您可以这样做：

foo;bar;baz%3bqux

并将其解释为三个部分：foo、bar、baz;qux。如果分号不是保留字符，; 和 %3b 将是等效的，因此 URI 将被错误地解释为四个部分：foo、bar、baz、qux。

【讨论】：

简而言之，保留，但没有什么特别的。我们使用它来编码 RESTful 查询中的一些信息。

感谢您的示例，这真的很有帮助。

有人可以分享一个在真实网络服务中使用的例子吗？

HTTP URL 中; 的一些特殊含义？

@Winny 我的路径包括在路径结束之前过滤的段。例如：some.com/path/filter;arguments;here/products/12345 在不影响路径本身的情况下，将元数据添加到路径的整个分支也很有用。例如：some.com/blog;paid_user/2018/Jun/That-time-I-did-that-thing 或 myshop.com/product;referred_by_facebook/category/123

【参考方案3】：

如果你回到规范的older versions，意图会更清楚：

  path_segments = segment *( "/" segment )
  segment       = *pchar *( ";" param ) 

每个路径段可能包含一个 参数序列，用分号“;”表示字符。

我相信它起源于FTP URIs。

【参考方案4】：

围绕其当前用法有一些有趣的约定。这些说明何时使用分号或逗号。摘自《RESTful Web Services》一书：

使用标点字符分隔同一层次结构级别的多条数据。当项目的顺序很重要时使用逗号，...当顺序无关紧要时使用分号。

【参考方案5】：

自 2014 年以来，已知路径段对Reflected File Download attacks 有贡献。假设我们有一个易受攻击的 API，它反映了我们发送给它的任何内容：

https://google.com/s?q=rfd%22||calc||

"results":["q", "rfd\"||calc||","I love rfd"]

现在，这在浏览器中是无害的，因为它是 JSON，因此不会被渲染，但浏览器宁愿提供将响应下载为文件。现在这里的路径段来帮助（攻击者）：

https://google.com/s;/setup.bat;?q=rfd%22||calc||

分号 (;/setup.bat;) 之间的所有内容都将不发送到 Web 服务，而是浏览器将其解释为文件名...以保存 API 响应。

现在，将下载并运行一个名为 setup.bat 的文件，而无需询问运行从 Internet 下载的文件的危险（因为它的名称中包含单词 "setup"）。内容将被解释为 Windows 批处理文件，并运行 calc.exe 命令。

预防：

清理 API 的输入（在这种情况下，它们应该只允许使用字母数字）；转义是不够的 在不会渲染的 API 上添加 Content-Disposition: attachment; filename="whatever.txt"； Google 缺少 filename 部分，这实际上使攻击更容易 在 API 响应中添加 X-Content-Type-Options: nosniff 标头

【参考方案6】：

我发现了以下用例：

它是 html 实体的最后一个字符：

List of XML and HTML character entity references

在 HTML 或 XML 中使用这些字符实体引用之一 文档中，输入一个＆符号，后跟实体名称和一个 分号，例如 & 表示 & 符号（“&”）。

Apache Tomcat 7（或更新版本？！）我们将其命名为path parameter：

Three Semicolon Vulnerabilities

Apache Tomcat 是支持“路径”的 Web 服务器示例之一 参数”。路径参数是文件名后的额外内容， 用分号隔开。分号后的任意内容 不影响 Web 浏览器的登录页面。这意味着 http://example.com/index.jsp;derp 仍将返回 index.jsp，而不是 一些错误页面。

URI 方案由它拆分 MIME 和数据：

Data URI scheme

它可以包含一个可选的字符集参数，与 前面部分用分号 (;) 。

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg=="  />

并且 IIS 5 和 IIS 6 中存在绕过文件上传限制的错误：

Unrestricted File Upload

将文件扩展名列入黑名单 此保护可能会被以下人员绕过： ... 通过在禁止扩展后添加分号字符和 在允许的之前（例如“file.asp;.jpg”）

结论：

不要在 URL 中使用分号，否则它们可能会意外生成 HTML 实体或 URI 方案。