La technique pour passer au “next” middleware

En mars, une vulnérabilité a été découverte dans la librairie Next.js. Elle permet dans certains cas de contourner les mécanismes d’authentification et d’autorisation, nous allons vous expliquer comment.

Next.js est une bibliothèque open-source qui permet de créer des applications Web full-stack. Elle est grandement utilisée, avec plus de 9,4 millions de téléchargements par semaine.

Le framework permet de générer ses pages front, son backend et de créer des middlewares, qui vont s’interfacer entre les deux.

Un middleware est un design pattern permettant de chaîner des fonctions. Dans le cas d’un framework comme Next.js, ces fonctions interviennent à différents moments du traitement d’une requête HTTP.

Dans Next.js, les middlewares peuvent être utilisés pour :

• vérifier l’authentification et l’autorisation
• faire des redirections en fonction du type d’utilisateur
• faire des A/B tests ou du lancement progressif de nouvelles fonctionnalités
• détecter et bloquer des bots
• …

Deux chercheurs en sécurité, zhero; et inzo_, ont décidé de se pencher sur le code de Next.js à la recherche de zero-day, c'est-à-dire des vulnérabilités qui n’ont encore jamais été déclarées et qui ne sont pas connues des mainteneurs.

Ils sont alors tombés sur ce code :

Ce comportement a été ajouté afin de contourner un bug qui faisait boucler les requêtes. L'entête HTTP x-middleware-subrequest est ajouté après le passage de l’appel et si l’appel boucle, le middleware est contourné pour ne pas l’appliquer plusieurs fois.

Or, rien n’empêche un utilisateur de manipuler une requête HTTP pour en modifier à la main les headers. En ajoutant cet entête dans sa requête avec le nom du fichier contenant le middleware, on peut facilement contourner n’importe quel middleware. Par exemple, si les développeurs ont ajouté un middleware dont la responsabilité est de vérifier que l’utilisateur courant a le rôle “administrateur”, alors un attaquant peut accéder à la ressource sans avoir ce rôle, simplement en contournant le middleware.

À partir de la version 13, le code change légèrement pour ajouter un nombre de récursions possibles. Les mainteneurs ont voulu permettre jusqu’à cinq passages pour les appels qui bouclent.

Ce commit modifie le code pour ajouter cette logique.

Toutefois, cela n’empêche pas un attaquant de contourner le middleware en mettant cinq fois son nom dans le header :
x-middleware-subrequest : nom:nom:nom:nom:nom.

De plus, le fichier contenant les middlewares est standardisé, il est donc aisé de deviner le nom à mettre dans le header x-middleware-subrequest  pour le contourner. Les middlewares sont écrits :

• à partir de la version 13, dans un fichier middlewares.ts qui est à la racine ou bien dans le dossier src
• avant la version 13, dans un fichier _middlewares.ts, directement dans le dossier pages ou bien dans un de ses sous-dossiers /pages/**/_middlewares.ts qui dépendent de l’URL de la route appelée.

Ainsi, l’attaquant peut deviner le nom du fichier à mettre dans le header.

Pour corriger cette vulnérabilité, Next.js a supprimé le contournement et l’utilisation du header x-middleware-subrequest.

🛡️️ Comment se protéger

• Monter la version et passer au minimum sur les versions 12.3.5, 13.5.9, 14.2.25 ou 15.2.3. En général, il est recommandé de faire des montées de versions régulières pour avoir les patchs de corrections de vulnérabilités et de bugs.
• Pour cette faille précise, il est possible de faire sa vérification d’autorisation dans le backend plutôt que dans le middleware. Next.js a d'ailleurs changé sa vision et sa documentation sur ce point.

• Mettre à jour ses dépendances et utiliser un outil automatique de suivi des CVE, comme npm audit.
  Un des avantages de l’open source est la recherche régulière de failles par la communauté et la mise à disposition de patch rapidement après leur découverte et donc cela nécessite une certaine rigueur pour les suivre et les corriger. Des outils comme Renovate et Dependabot permettent de proposer des mises à jour régulières des dépendances utilisées.
• D’une manière plus générale, il ne faut jamais faire confiance à des données qui peuvent être modifiées par les utilisateurs. C’est aussi le cas des headers dans les requêtes, comme raconté ici.

• Modification de la documentation de NextJS pour déconseiller l’utilisation des middlewares
• Article du hacker éthique zhero qui détaille sa découverte
• Liens des différents commits :
  • Code vulnérable avant la version 13
  • Code vulnérable à partir de la version 13
  • Fix de la vulnérabilité

Nous avons pour ambition de sécuriser le web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute, n'hésitez pas à contacter notre équipe sécurité par mail (security@theodo.fr).