Mass Assignment

Pourquoi c'est important

Les frameworks rendent le développement rapide en liant automatiquement les données de requête aux objets, mais cette commodité devient une vulnérabilité quand l'objet contient des champs que l'utilisateur ne devrait jamais contrôler. Un seul champ caché, role fixé à admin, transforme une inscription ordinaire en prise de contrôle de l'application elle-même.

Le mass assignment est particulièrement courant dans les API et l'un des chemins d'élévation de privilèges les plus nets qu'un testeur puisse trouver, ce qui explique sa présence dans l'OWASP API Security Top 10. On le connaît aussi sous le nom d'autobinding ou d'injection d'objet et il est catalogué sous CWE-915.

Comment les frameworks lient automatiquement

Pour épargner aux développeurs l'écriture d'une affectation par champ, les frameworks offrent des assistants qui mappent un corps de requête entier sur un modèle en un seul appel. Lorsque le modèle inclut des colonnes sensibles et que la liaison n'a aucune liste blanche, chaque colonne devient inscriptible depuis la requête. L'exemple le plus célèbre est l'incident GitHub de 2012, où un chercheur a utilisé le mass assignment pour ajouter sa clé publique à une organisation qu'il ne contrôlait pas. Le même schéma existe dans Rails, Laravel, Spring, ASP.NET, Django et de nombreux ORM de Node.js.

Comment ça fonctionne

Un point de terminaison d'inscription accepte du JSON et le valide bien :

{ "username": "testuser", "email": "test@example.com", "password": "Test123!" }

L'attaquant ajoute un champ que le formulaire n'a jamais montré et, souvent, change le type de contenu pour qu'un analyseur plus laxiste le traite :

<user>
  <username>testuser</username>
  <password>Test123!</password>
  <role>admin</role>
</user>

Si le serveur lie <role> directement sur le modèle utilisateur, le nouveau compte est créé en tant qu'administrateur. Cela combine deux problèmes : un type de contenu qui contourne la validation et un autobinding qui n'aurait jamais dû accepter role de la part du client. C'est un résultat fréquent du parameter tampering durant le test d'API.

Comment la tester

Capturez une requête de création ou de mise à jour et comparez les champs envoyés par l'interface aux propriétés probables de l'objet. Ajoutez des candidats comme role, isAdmin, is_admin, verified, approved, balance, user_id et group, un à la fois, et observez si la réponse ou une requête de suivi confirme que le champ a été accepté. Lisez d'abord un GET du même objet, car les champs qu'il renvoie sont de solides indices sur les propriétés inscriptibles. Réessayez ensuite la requête sous chaque type de contenu accepté, car la validation diffère souvent entre JSON, XML et données de formulaire.

Prévention

Liez depuis une liste blanche explicite de champs sûrs, ne liez jamais des objets de requête entiers, et gardez un modèle d'écriture distinct de votre modèle interne. Rejetez les champs inattendus, validez chaque type de contenu selon le même standard, et ne fixez les propriétés sensibles comme role que dans une logique côté serveur que le client ne peut pas influencer.