允许引号字符作为 URL 参数的一部分有什么风险？答案

【问题标题】：What are the risks of allowing quote characters as part of a URL parameter?允许引号字符作为 URL 参数的一部分有什么风险？
【发布时间】：2011-05-03 21:43:25
【问题描述】：

我需要允许用户提交如下查询；

/search/"my search string"

但由于请求验证而失败，如以下 2 个问题所述：

How to include quote characters as a route parameter? Getting "Illegal characters in path" message

How to modify request validation?

我目前正试图弄清楚如何禁用引号字符的请求验证，但我想知道在我实际启用该禁用的站点之前的风险？我不会禁用请求验证，除非我只能为引号字符禁用它，所以我打算禁止当前不允许的所有其他字符。

【问题讨论】：

有人要问这个愚蠢的问题：为什么搜索字符串必须是路径的一部分，而不是 URL 查询参数（例如 /search?q=%22my+search+string%22）？
这是愚蠢的答案：因为客户喜欢这样。您将其附加为查询字符串参数的建议是 plan b
好吧，还有一个更愚蠢的问题：为什么客户会关心您采用哪种 URL 方案？（诚然，我发现愚蠢的顾客不仅充满了愚蠢的想法，而且他们也无可救药地相信这些想法的天才。）如果我更愤世嫉俗，我可能会建议你空手回去说， “对不起，但我们只能执行 B 计划。”但我尽量不要玩世不恭，我绝不会建议对你的老板撒谎，所以我不会建议这样做。

标签： asp.net security request-validation

【解决方案1】：

根据 URI 通用语法规范 (RFC 2396)，双引号字符被明确排除并且必须转义（即%22）。请参阅第 2.4.3 节。规范中给出的原因：

尖括号“”和双引号（“）字符被排除在外，因为它们经常在文本文档和协议字段中用作 URI 周围的分隔符。

您可以很容易地看到为什么会这样——想象一下尝试在 HTML 中创建指向您的 URL 的链接：

<a href="http://somesite/search/"my search string""/>

这会使 HTML 解析失败（并且还会破坏 SO 的语法突出显示）。您也将无法使用 URL 进行基本操作，例如通过电子邮件将其发送给某人（电子邮件客户端无法正确解析 URL）、将其发布在留言板上、以即时消息的形式发送等。

不管怎样，空格也被明确排除（RFC 的同一部分解释了原因）。

【讨论】：