Guide de dépannage des sessions d’applications auto-hébergées pour les modifications de proxy et de cookies

L’approche sûre consiste à traiter une comparaison couche par couche des requêtes directes et passant par un proxy, des cookies de réponse, du stockage du navigateur et de l’état de session du backend comme une suite de vérifications observables, et non comme une commande unique.

Dans une application web auto-hébergée derrière un proxy inverse, le risque concret est que les utilisateurs soient déconnectés, pris dans une boucle de redirection ou incapables d’établir une session après des modifications du proxy ou des cookies. Notez l’identité actuelle et le point de restauration, commencez par le facteur discriminant le moins intrusif, interprétez les résultats de réussite et d’échec avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable serait exposée. Le flux de travail ci-dessous ne se termine qu’une fois la charge de travail initiale réussie ou les éléments de preuve arrivés à une limite nécessitant une escalade.

Reproduire un parcours de session et préserver les éléments de preuve

Choisissez un utilisateur, un profil de navigateur, un nom d’hôte et un parcours de connexion. Notez la première requête en échec, la séquence des statuts, les emplacements de redirection, les en-têtes de réponse Set-Cookie avec les valeurs masquées, les cookies de requête, les journaux du proxy, les journaux de l’application et la modification exacte de configuration qui a précédé l’échec.

Ne commencez pas par supprimer tous les cookies ni par renouveler le secret de l’application. Utilisez un profil de navigateur privé comme référence vierge tout en conservant le profil en échec pour comparaison. Vérifiez si l’accès direct au backend fonctionne ; cela permet de distinguer l’authentification de l’application du comportement des URL et des cookies lié au proxy.

Arrêtez-vous si l’application expose des jetons dans les journaux, si le proxy accepte des en-têtes de transfert usurpés provenant de clients non fiables ou si la connexion contourne TLS. Protégez les identifiants et corrigez la limite de sécurité avant de poursuivre le dépannage fonctionnel.

Vérifier le schéma, l’hôte et la confiance accordée aux transferts

Comparez l’URL externe avec ce que croit l’application : schéma, hôte, port, chemin de base et adresse IP du client. Examinez Host, X-Forwarded-Proto ou les en-têtes de transfert normalisés, ainsi que la liste des proxys de confiance de l’application. Un backend qui croit que les requêtes HTTPS sont en HTTP peut refuser les cookies Secure ou générer une redirection sans fin vers HTTPS.

Utilisez un proxy de confiance pour définir ou remplacer les en-têtes de transfert et configurez l’application afin qu’elle ne fasse confiance qu’à ce relais. N’ajoutez pas aveuglément les valeurs fournies par le client. Testez une connexion et une redirection absolue après chaque modification, plutôt que de modifier simultanément les en-têtes du proxy et l’URL de base de l’application.

Le guide ZimaSpace sur le diagnostic des connexions directes et passant par un proxy utilise la même comparaison après un redémarrage du proxy. Son exemple Immich est plus ciblé, mais le parcours des éléments de preuve est transposable : prouvez que la session du backend fonctionne, puis examinez les en-têtes de transfert, le routage et l’état du navigateur.

Examiner la portée des cookies et les décisions du navigateur

Vérifiez le nom du cookie, Domain, Path, Secure, HttpOnly, SameSite, son expiration et l’existence éventuelle de cookies en double portant le même nom à des chemins ou domaines différents. Les outils de développement du navigateur indiquent si un cookie a été enregistré, rejeté ou omis de la requête suivante ; les journaux du serveur ne permettent pas à eux seuls de connaître cette décision.

Le guide de l’OWASP sur le comportement des cookies SameSite explique comment les valeurs SameSite contrôlent l’envoi des cookies entre sites. Si l’authentification traverse plusieurs sites ou utilise un flux intégré, SameSite=None nécessite également Secure ; pour une application simplement sur le même site, élargir inutilement la portée du cookie affaiblit la conception.

Supprimez uniquement le cookie concerné dans le profil de référence après l’avoir consigné, puis répétez la connexion. Si un nouveau cookie fonctionne alors que le profil conservé échoue, comparez la portée et l’expiration ; si les deux échouent, revenez aux en-têtes de réponse ou au stockage des sessions du backend au lieu d’effacer l’état à répétition.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifier l’état partagé des sessions et valider la correction

Pour les applications composées de plusieurs conteneurs ou répliquées, vérifiez que chaque instance utilise le même secret de signature des sessions, la même source de temps et, lorsque cela est nécessaire, le même backend de sessions partagé. Un proxy qui alterne entre les instances peut donner l’impression de déconnexions aléatoires lorsqu’une instance ne peut pas valider le cookie d’une autre.

La discussion de PortSwigger sur les limites de sécurité de SameSite est axée sur la sécurité, mais elle précise que SameSite constitue une limite du navigateur et non un simple bouton de réparation générique des connexions. Préservez la protection CSRF tout en l’adaptant à l’origine réelle de l’application et à son flux de redirection.

Validez la connexion, la déconnexion, l’expiration après inactivité, le redémarrage du navigateur, la modification du mot de passe et l’accès via les noms d’hôte internes et distants prévus. Ne clôturez le problème que lorsque les anciens cookies échouent de manière sûre, que les nouvelles sessions survivent au routage normal et qu’aucun attribut de transfert ou de cookie n’a été assoupli au-delà du besoin documenté.