Czy włączenie podwójnej ucieczki jest niebezpieczne?

Mam aplikację ASP.NET MVC z trasą umożliwiającą wyszukiwanie rzeczy za pośrednictwem / search / <searchterm>.

Kiedy podaję „search / abc”, działa to dobrze, ale kiedy podaję „/ search / a + b + c” (poprawnie zakodowany adres URL), IIS7 odrzuca żądanie z błędem HTTP 404.11 ( moduł filtrowania żądań jest skonfigurowany tak, aby odmawiać żądanie zawierające podwójną sekwencję ucieczki ). Po pierwsze, dlaczego to robi? Wydaje się, że zgłasza błąd tylko wtedy, gdy jest częścią adresu URL, ale nie jako część ciągu zapytania (/ transmit? Q = a + b + c działa dobrze).

Teraz mogę włączyć podwójne żądania ucieczki w sekcji bezpieczeństwa mojego pliku web.config, ale waham się, czy to zrobić, ponieważ nie rozumiem konsekwencji ani dlaczego serwer miałby odrzucić żądanie „a + b + c” jako część adresu URL, ale zaakceptuj jako część ciągu zapytania.

Czy ktoś może wyjaśnić i udzielić porady, co robić?

Edycja: dodano nacisk na odpowiednie sekcje.

Zasadniczo: IIS jest nadmiernie paranoikiem. Możesz bezpiecznie wyłączyć to sprawdzanie, jeśli nie robisz niczego szczególnie nierozsądnego z danymi zdekodowanymi uri (na przykład generowanie identyfikatorów URI lokalnego systemu plików poprzez konkatenację ciągów).

Aby wyłączyć sprawdzanie, wykonaj następujące czynności ( stąd ): (zobacz mój komentarz poniżej, aby dowiedzieć się, co pociąga za sobą podwójne uciekanie).

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

Jeśli symbol plusa jest prawidłowym znakiem w danych wejściowych wyszukiwania, należy włączyć opcję „allowDoubleEscaping”, aby umożliwić usługom IIS przetwarzanie takich danych wejściowych ze ścieżki identyfikatora URI.

Wreszcie bardzo prostym, choć ograniczonym obejściem jest po prostu unikanie znaku „+” i zamiast tego użycie „% 20”. W każdym razie użycie symbolu „+” do zakodowania spacji nie jest prawidłowym kodowaniem adresu URL , ale jest specyficzne dla ograniczonego zestawu protokołów i prawdopodobnie jest szeroko obsługiwane ze względu na kompatybilność wsteczną. Jeśli tylko do celów kanonicznych, lepiej jest zakodować spacje jako „% 20”; i to ładnie omija problem z IIS7 (który może nadal pojawiać się w przypadku innych sekwencji, takich jak% 25ab.)

Chciałbym tylko dodać kilka informacji do odpowiedzi Eamona Nerbonne'a związanych z częścią twojego pytania " co robić " (nie wyjaśniając dlaczego).
Możesz również łatwo zmienić ustawienia konkretnej aplikacji za pomocą

1. otwarcie konsoli z uprawnieniami administratora (Start - cmd - prawy przycisk myszy, Uruchom jako administrator)

2. wpisując następujące (pobrane stąd: http://blogs.iis.net/thomad/archive/2007/12/17/iis7-rejecting-urls-containing.aspx ):

   %windir%\system32\inetsrv\appcmd set config "YOURSITENAME" -section:system.webServer/security/requestfiltering -allowDoubleEscaping:true

   (można np substytut YOURSITENAMEze Default Web Sitestosowania tej zasady na stronie domyślnej)

3. Wejdź, gotowe.

Przykład:

1. najpierw miałem ten sam problem:
2. Wpisywanie powyższego tekstu:
3. Teraz działa zgodnie z oczekiwaniami:

Czy myślałeś o umieszczeniu adresu URL wyszukiwania, takiego jak „/ search / a / b / c”?

Musisz ustawić trasę, taką jak

search/{*path}

A następnie wyodrębnij wartości wyszukiwania z ciągu ścieżki w akcji.

HTHs
Charles

Natknąłem się na to w IIS 7.5, wykonując Server.TransferRequest () w aplikacji.

Zakodowanie nazwy pliku spowodowało problem z podwójną ucieczką, ale gdybym jej nie zakodował, napotkałbym „potencjalnie niebezpieczny błąd Request.Path” .

Umieszczenie dowolnego protokołu, nawet pustego, na adresie URL, który przekazuję do Server.TranferRequest () rozwiązało problem.

Nie działa:

context.Server.TransferRequest("/application_name/folder/bar%20bar.jpg");

Pracuje:

context.Server.TransferRequest("://folder/bar%20bar.jpg");