Ceci est bloqué directement au niveau du noyau d’IIS. En guise de test, j’ai retiré tous les modules d’IIS de sorte qu’il n’avait même plus de gestionnaire de pages statiques, et il affichait toujours le message d’erreur 400.
Je ne crois pas qu’il soit possible de contourner cela avec IIS. Les paramètres de registre que vous avez mentionnés sont pour d’autres types de caractères restreints. Je n’ai pas vu de levier pour modifier cette fonctionnalité.
Quel est votre objectif en évitant cela ? Cela élargit votre surface d’attaque, et je n’imagine pas qu’un visiteur légitime soit perdu à cause du blocage de séquences d’échappement URL incomplètes.
Mise à jour 2 :
Voici trois excellents liens à ce sujet. Nazim Lala et Wade Hilmo de l’équipe IIS ont blogué à ce sujet à cause de la discussion autour de votre question. Scott Hanselman a aussi un excellent article sur la partie chaîne de requête dans .NET :
Mise à jour :
J’ai vérifié auprès d’un membre de l’équipe IIS pour obtenir une réponse faisant autorité. Il a mentionné que le % est considéré comme un caractère non sûr selon la RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt).
Voici le texte pertinent :
Non sûr :
Les caractères peuvent être non sûrs pour plusieurs raisons. Le caractère espace est non sûr car des espaces significatifs peuvent disparaître et des espaces non significatifs peuvent être introduits lorsque les URL sont transcrites ou composées ou soumises au traitement de programmes de traitement de texte. Les caractères « < » et « > » sont non sûrs car ils sont utilisés comme délimiteurs autour des URL dans le texte libre ; les guillemets (« " ») sont utilisés pour délimiter les URL dans certains systèmes. Le caractère « # » est non sûr et devrait toujours être encodé car il est utilisé dans le World Wide Web et dans d’autres systèmes pour délimiter une URL d’un identifiant de fragment/ancre qui pourrait le suivre. Le caractère « % » est non sûr car il est utilisé pour l’encodage d’autres caractères. Les autres caractères sont non sûrs car les passerelles et autres agents de transport sont connus pour parfois modifier de tels caractères. Ces caractères sont « { », « } », « | », « \ », « ^ », « ~ », « [ », « ] » et « ` ».
Tous les caractères non sûrs doivent toujours être encodés au sein d’une URL. Par exemple, le caractère « # » doit être encodé au sein des URL même dans les systèmes qui ne traitent normalement pas les identifiants de fragment ou d’ancre, afin que si l’URL est copiée dans un autre système qui les utilise, il ne soit pas nécessaire de modifier l’encodage de l’URL.
IIS bloque donc proactivement cela au niveau du noyau, une mesure de sécurité proactive pour minimiser leur surface d’attaque.