UrlScan e URL longo de filtragem de solicitação

Question

NossoWindows/IIS 7.5ambiente está configurado comUrlScaneFiltragem de solicitação do IIS. Estamos enfrentando um problema com um URL longo.

/MyWeb/TestFW/prweb/Servelt1/ZsvSk3vV8PtgJEa4_x3fiQ[[*/!MyWebApp/webwb/desktop_domainsuffix_1819019784.js!yui_13833664524!desktopwrapper_12997951049!automationscripts_1864420987!ui_jquery_1796787788!desktopwrapper_12997951049!automationscripts_1864420987!ui_jquery_1796787788!

Obs: modifiquei a url, mas essa é a estrutura e fica em torno de 880 bytes se colocar no bloco de notas.

UlrScan.iniarquivo tem toda a configuração padrão para a seção Limites de solicitação:

MaxAllowedContentLength=30000000
MaxUrl=260
MaxQueryString=2048

Filtragem de solicitações do IIStambém está habilitado e tem os valores padrão:

<security>
   <requestFiltering>
    <requestLimits
       maxAllowedContentLength="30000000"
       maxUrl="4096"
       maxQueryString="2048" 
                  />
  </requestFiltering>
  </security>

Executei um teste e o URL fornecido no início da postagem falhou com um erro 403. O URL tem 880 bytes, portanto, se a Filtragem de Solicitação tiver precedência, ela não deverá falhar, então presumoUrlScanexecutado sem considerar os limites de solicitação do IIS.

Pedi ao meu administrador do IIS para fornecer logs do IIS algumas vezes e, em todos os logs compartilhados, vejo apenas 403. Nenhum erro 404 ou 404.14, conforme mencionado em todos os outros artigos de suporte da Microsoft.

Então minha observação está correta? com esse tipo de configuração, qual configuração tem precedência? é UrlScan ou filtragem de solicitação do IIS?

Eu adoraria saber se existe uma opção para fazer com que a Filtragem de Solicitações tenha precedência sobreUrlScanconfigurações, porque a filtragem de solicitações é personalizável até o nível do aplicativo, enquanto UrlScan.inié personalizável apenas até o nível do site.

E também, de acordo com a documentação do IIS,UrlScanrecursos estão sendo incorporados à filtragem de solicitações do IIS. Então, por que há uma enorme diferença entre os valores padrão para o URL máximo? 260 bytes urlscan.inie 4.096 bytes na filtragem de solicitações do IIS.

Answer 1

O UrlScan interrompe a solicitação antes que ela chegue ao módulo Filtragem de Solicitação do IIS. A solução ideal e recomendada seria descontinuar o UrlScan e usar o módulo IIS Request Filtering sozinho no IIS 7 e superior. Este módulo no IIS 7.5 possui todos os recursos dos módulos urlscan, portanto, não há razão técnica para não descontinuar. Mas como nossos administradores não se sentiram confortáveis ​​com isso, seguimos a abordagem abaixo. Aumente o maxUrl no módulo urlscan para 4096, o que permite solicitações demoradas. O módulo de filtragem de solicitações pode ser configurado no nível do site padrão ou no nível do servidor, que é global, e também no nível do aplicativo individual. Portanto, o urlScan de nível de site padrão foi deixado em 460 caracteres, o que se aplica a todos os aplicativos e no meu aplicativo o maxUrl da filtragem de solicitação está definido como 4096. Dessa forma, todos os outros 50 aplicativos têm os limites definidos por padrão anos atrás e meu aplicativo tem mais comprimento para atender solicitações demoradas.

Obrigado.