启用双重转义是否危险? [英] Is Enabling Double Escaping Dangerous?

问题描述

我有一个 ASP.NET MVC 应用程序，其路由允许通过/search/ 搜索内容.

I have an ASP.NET MVC application with a route that allows searching for stuff via /search/<searchterm>.

当我提供search/abc"时它运行良好，但是当我提供/search/a+b+c"(正确的 url 编码)时，IIS7 拒绝请求并显示 HTTP 错误 404.11(请求过滤模块配置为拒绝包含双转义序列的请求).首先，它为什么要这样做?如果它是 URL 的一部分，而不是作为查询字符串的一部分，它似乎只会引发错误(/transmit?q=a+b+c 可以正常工作).

When I supply "search/abc" it works well, but when I supply "/search/a+b+c" (correctly url encoded) then IIS7 rejects the request with HTTP Error 404.11 (The request filtering module is configured to deny a request that contains a double escape sequence). FIrst of all, why does it do this? It only seems to throw the error if it is part of the URL, but not as part of a query string ( /transmit?q=a+b+c works fine).

现在我可以在 web.config 的安全部分启用双重转义请求，但我犹豫是否这样做，因为我不明白其中的含义，也不明白为什么服务器会拒绝请求a+b+c" 作为 URL 的一部分，但接受作为查询字符串的一部分.

Now I could enable double escape requests in the security section of my web.config but I'm hesitant to do so as I don't understand the implications, and neither why the server would reject the request "a+b+c" as part of the URL but accept as part of a query string.

有人可以解释并给出一些建议吗?

Can someone explain and give some advice what to do?

推荐答案

增加了相关部分的重点.

Added emphasis to relevant sections.

基本上:IIS 过于偏执.如果您没有对 uri 解码数据做任何特别不明智的事情(例如通过字符串连接生成本地文件系统 URI)，则可以安全地禁用此检查.

Basically: IIS is being excessively paranoid. You can safely disable this check if you're not doing anything particularly unwise with the uri decoded data (such as generating local filesystem URI's via string concatenation).

要禁用检查，请执行以下操作(来自 here):(有关双重转义的含义，请参阅下面的评论).

To disable the check do the following (from here): (see my comment below for what double escaping entails).

<system.webServer>
    <security>
        <requestFiltering allowDoubleEscaping="true"/>
    </security>
</system.webServer>

如果加号是搜索输入中的有效字符，您将需要启用allowDoubleEscaping"以允许 IIS 处理来自 URI 路径的此类输入.

If the plus symbol is a valid character in a search input, you will need to enable "allowDoubleEscaping" to permit IIS to process such input from the URI's path.

最后，一个非常简单但有限的解决方法就是避免使用+"并改用%20".在任何情况下，使用+"符号对空格进行编码不是有效的 url 编码，但特定于一组有限的协议，并且可能广泛支持向后兼容原因.如果仅出于规范化目的，您最好将空格编码为 '%20' ；这很好地回避了 IIS7 问题(对于其他序列，如 %25ab，仍然会出现该问题.)

Finally, a very simple, if limited workaround is simply to avoid '+' and use '%20' instead. In any case, using the '+' symbol to encode a space is not valid url encoding, but specific to a limited set of protocols and probably widely supported for backwards-compatibility reasons. If only for canonicalization purposes, you're better off encoding spaces as '%20' anyhow; and this nicely sidesteps the IIS7 issue (which can still crop up for other sequences, such as %25ab.)

这篇关于启用双重转义是否危险?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！