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

我需要允许用户提交如下查询;允许引用字符作为URL参数的一部分有什么风险？

/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?

我目前正在试图找出如何禁用请求验证对于引用字符，但我想知道我真的把这个网站与这个残疾人生活之前的风险？我不会禁用请求验证，除非我只能为引号字符禁用它，所以我打算禁止当前不允许的其他字符。

来源

2010-11-02 DaveDev

有人必须问一个愚蠢的问题：为什么搜索字符串必须是路径的一部分，而不是URL查询参数（例如'/ search？q =％22my + search + string％22'）？ – 2010-11-02 12:03:07

以下是愚蠢的答案：因为客户喜欢这种方式。您的建议将其附加为查询字符串参数是计划b – DaveDev 2010-11-02 12:05:09

好的，这是一个愚蠢的问题：为什么客户关心您采用哪种URL方案？（不可否认，我发现愚蠢的顾客不仅充满了愚蠢的想法，而且他们也无法相信这些想法的天才。）如果我更加愤世嫉俗，我可能会建议你空手回去说， “对不起，我们只需要计划B”。但我尽量不要玩世不恭，我绝不会向你的老板推荐说谎，所以我不会建议。 – 2010-11-02 12:12:08

根据URI通用语法规范（RFC 2396），明确排除了双引号字符并且必须转义（即%22）。参见2.4.3节。在spec给出的原因：

“<”和“>”和双引号（“）字符被排除在外，因为它们经常被用来作为在文本文档和协议字段周围URI定界符的支架角。

你可以很容易看到为什么是这样的话 - 想象试图创建HTML链接到您的网址：

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

这将失败HTML解析（也打破SO的语法高亮）你也会遇到麻烦用URL做基本的东西，比如发邮件给某人（电子邮件客户端不会正确解析URL），将它发布在留言板上，通过即时消息发送出去等。

对于它的价值，空间也被明确排除（RFC的相同部分解释了原因）。

来源

2010-11-02 12:28:06

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

回答

相关问题