HTTP 407 sans défi Proxy-Authenticate exploitable

Un client ne peut pas choisir un mécanisme d'authentification à partir d'un simple numéro de statut. La réponse du proxy doit décrire ce qu'il accepte.

HTTP impose à un proxy qui génère un 407 d'envoyer un défi Proxy-Authenticate. Pour un service Basic, un exemple simple est :

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

Le statut numérique, le nom d'en-tête et la syntaxe propre au schéma comptent tous. Une page d'erreur de marque contenant le mot authentication dans son corps ne remplace pas l'en-tête. Les implémentations personnalisées doivent aussi envoyer une réponse HTTP 407 complète, y compris le terminateur d'en-tête et le cadrage du corps.

Inspectez la réponse parvenue à ce client

Capturez les champs de statut et de défi après avoir retiré les valeurs secrètes. Un intermédiaire a peut-être transformé la réponse, ou un proxy personnalisé a peut-être construit un défi invalide. Comparez ces éléments avec le journal des transactions du proxy lui-même.

Si le service envoie plutôt 405 ou une autre erreur, ne réétiquetez pas chaque telle réponse comme 407 dans un client personnalisé. Vous masqueriez de véritables échecs de politique de méthode et n'auriez toujours aucune négociation de schéma fiable. Corrigez le comportement du service ou utilisez son chemin d'authentification pris en charge et documenté.

Plusieurs défis exigent aussi un véritable analyseur HTTP. Une virgule peut séparer des paramètres ou des défis ; découper aveuglément tout l'en-tête sur les virgules peut corrompre un realm entre guillemets. Utilisez l'implémentation d'authentification prise en charge du client plutôt qu'une succession de remplacements de chaînes.

Ce n'est qu'une fois le défi exploitable qu'il devient sensé de chercher pourquoi le fournisseur d'identifiants n'a pas renvoyé de compte.