Manuseie corretamente a solicitação do IIS com o URL de entrada percentual (/%)

14

Estou procurando qualquer tipo de solução para obter corretamente uma solicitação do IIS, como /programming//% e http://bing.com/%, para não exibir uma página 400 Solicitação incorreta, mas exibir uma página de erro personalizada semelhante à maneira como o http://google.com/% e http://facebook.com/% faz (obviamente, esses exemplos não estão no IIS).

Acredito que tentei definir todas as configurações de registro http.sys aplicáveis (AllowRestrictedChars, PercentUAllowed) por http://support.microsoft.com/kb/820129, mas isso não ajudou. A configuração de AllowRestrictedChars e uma página 400 personalizada corrigiu URLs como /programming//%12, mas não /%.

iis iis-7 iis-7.5

— bkaid
fonte

3

Você percebe que é um escape de URL incompleto e é uma solicitação ruim, por isso o 400 está lidando adequadamente com isso? PercentU e AllowRestricted não são realmente aplicável

— Rup

Sim, sim (e /% é apenas um exemplo de URL, mas obviamente o erro ocorre com todos os caracteres de escape inválidos). IIS está a lidar com o 400, mas eu quero mostrar uma página personalizada 400 como eu posso com outros códigos de status em IIS, e como como não-servidores IIS pode para 400.

— bkaid

Eu tenho alguns links poderosos apontando para meus sites que são codificados por engano assim. mas não tenho permissão para obtê-los na página correta. Em vez disso, é um erro grave. isso é inaceitável.

— boomhauer

20

Isso está bloqueado diretamente no nível do kernel do IIS. Como teste, retirei todos os módulos do IIS para que ele nem tivesse um manipulador de página estático e ainda exibisse a mensagem de erro 400.

Não acredito que seja possível com o IIS contornar isso. As configurações do registro mencionadas são para outros tipos de caracteres restritos. Não vi uma alavanca para alterar essa funcionalidade.

Qual é o seu objetivo é evitar isso? Ele abre sua superfície de ataque mais ampla e não consigo imaginar um visitante legítimo sendo perdido como resultado do bloqueio de seqüências de escape de URL incompletas.

Update2: Aqui estão três ótimos links sobre isso. Nazim Lala e Wade Hilmo da equipe do IIS publicaram um blog sobre isso por causa de discussões sobre sua pergunta. Scott Hanselman também tem um ótimo post sobre a parte da querystring no .NET:

Uso de caracteres especiais no IIS - Nazim Lala
Como o IIS bloqueia caracteres em URLs - Wade Hilmo
Experiências de malícia - Scott Hanselman

Atualização: verifiquei com um membro da equipe do IIS para obter uma resposta autorizada. Ele mencionou que o% é considerado um caractere não seguro de acordo com a RFC 1738 ( http://www.ietf.org/rfc/rfc1738.txt ).

Aqui está o texto relevante:

Inseguro:

Os caracteres podem não ser seguros por vários motivos. O caractere de espaço é inseguro porque espaços significativos podem desaparecer e espaços insignificantes podem ser introduzidos quando as URLs são transcritas ou digitadas ou submetidas ao tratamento de programas de processamento de texto. Os caracteres "<" e ">" não são seguros porque são usados como delimitadores em torno de URLs em texto livre; a citação ("" ") é usada para delimitar URLs em alguns sistemas. O caractere" # "é inseguro e sempre deve ser codificado porque é usado na World Wide Web e em outros sistemas para delimitar um URL de um fragmento / âncora O identificador "%" não é seguro porque é usado para codificações de outros caracteres. Outros caracteres são inseguros porque é conhecido que gateways e outros agentes de transporte às vezes modificam esses caracteres. Esses caracteres são "{", "}", "|", "\", "^", "~", "[", "]" e "` ".

Todos os caracteres não seguros devem sempre ser codificados em um URL. Por exemplo, o caractere "#" deve ser codificado nas URLs, mesmo em sistemas que normalmente não lidam com identificadores de fragmento ou âncora, para que, se a URL for copiada para outro sistema que os use, não seja necessário alterar o Codificação de URL.

Portanto, o IIS proativamente bloqueia isso no nível principal, uma medida de segurança proativa para minimizar a superfície de ataque.

— Scott Forsyth - MVP
fonte

Prefiro registrar e manipular corretamente todos os erros para monitorar qualquer combinação estranha inválida de URLs inválidos que estão sendo gerados dinamicamente no meu site - no caso de um URL não estar sendo escapado corretamente.

— bkaid

1

Há algo a ser dito para lidar com os erros, mas se as falhas flagrantemente óbvias forem tratadas para você, isso é um bônus interessante. O IIS não deve permitir caracteres que não correspondam a um arquivo ou pasta no sistema de arquivos NTFS. Não saberia o que fazer com o caminho da pasta. Se não for um padrão de caractere igual a um caractere válido, será necessário tomar uma decisão sobre o que fazer. Nesse caso, parece que ele foi dedicado a bloquear em vez de ignorar os caracteres inválidos.

— Scott Forsyth - MVP

@thekaido Como Scott disse, não faz sentido analisar URLs incompletos. Que tipo de página de erro personalizada você pode criar, pois não tem idéia do que o usuário estava tentando fazer (já que a solicitação está incompleta). Note-se que o IE9 não vai mesmo deixar você chegar ao servidor com um pedido incompleto

— Jim B

Entendo as implicações de todas essas coisas, mas o Apache e outros servidores da Web permitem isso, como o IIS deve. URLs com escape inadequado são os únicos URLs que o IIS não permite que você saiba disso. O IIS deve e permite outros caracteres que não são mapeados para o sistema de arquivos NTFS porque meu site foi criado usando o ASP.NET MVC, em que as solicitações serão roteadas para recursos que não são baseados em arquivo.

— bkaid

Na verdade, eu estou corrigido sobre o% no NTFS. É permitido, juntamente com a maioria dos outros caracteres: en.wikipedia.org/wiki/Ntfs . (procure caracteres permitidos nos nomes de arquivos).

— Scott Forsyth - MVP

3

Eu posso pensar em 3 maneiras possíveis

Altere o IIS para apontar para uma página personalizada para 400 erros do que normalmente
Se isso é exclusivo para um site específico no IIS, você pode fazer algo assim no web.config:

<customErrors defaultRedirect = "ErrorPage.aspx" mode = "On">
<error statusCode = "400" redirect = "myCustom400Error.aspx" />
</customErrors>
Escreva um httpModule que inspeciona os URLs recebidos e os manipula

— Dave Wise
fonte

4

Nada disso funciona - o IIS nunca repassa a solicitação.

— bkaid

Opção # 1 deve funcionar não importa o que porque é assim que IIS responde ao erro

— Dave Sábio

4

Eu apenas tentei a opção 1 e o número 2 novamente e nenhum deles funciona. O IIS está lidando com essa solicitação especialmente como Scott menciona.

— bkaid

3

A única maneira de contornar isso parece verificar a URL antes que o kernel do IIS possa.

Você precisaria enviar os links gerados dinamicamente por meio de um script para verificá-los antes de encaminhar o usuário final para esse URL ...

Salvo isso, você sabe que esta é a única situação em que o IIS não lidará com isso da maneira que você deseja. Portanto, pelo processo de eliminação, se você tiver uma solicitação não tratada, sabe o que a causou.

Talvez a verificação do referenciador em uma página personalizada de 400 ajude a restringir a origem do tráfego?

— Garrett
fonte

2

Esta postagem no fórum do IIS indica que o HTTP 400 (Solicitação inválida) está bloqueado pelo http.sys e não chega ao IIS, que corresponde aos links que o @Scott Forsyth - MVP incluiu em sua resposta original.

Você pode ver um log dessas solicitações em c: \ Windows \ System32 \ LogFiles \ HTTPERR \

Não sei se você pode configurar a página de resposta que é enviada de volta ao usuário para esse tipo de erro, mas como até o Bing sofre com esse problema, suspeito que isso não é possível ou exigiria alguns hacks horríveis no sistema.

— Hector Correa
fonte