🚀 Preuve de concept (PoC) — XSS stocké

À tester uniquement dans des environnements autorisés / de laboratoire. Ne l'exécutez PAS contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation explicite de test.

Étapes de reproduction

1. Authentifiez-vous sur l'instance ERPNext cible en tant qu'utilisateur disposant de la permission de créer/modifier des articles de blog.

2. Accédez à la route de création/modification d'un article de blog, par exemple :

   root@kitploit:~

   /app/blog-post/<blog_name>
   

   

3. Dans le champ content, insérez la charge utile et enregistrez l'article :

   root@kitploit:~

4. Ouvrez la page de l'article de blog (/app/blog-post/<blog_name>) en tant qu'autre utilisateur (ou le même utilisateur dans un navigateur vierge). La charge utile s'exécute dans le navigateur du visiteur (ici, alert("xss")).

Remarques : la PoC utilise une simple alerte onerror. De véritables attaques pourraient exfiltrer des cookies, effectuer des actions au nom de la victime ou charger des scripts distants (selon la CSP et les attributs des cookies).

🧪 Scénario d'exploitation

Un attaquant pouvant créer ou modifier des articles de blog stocke un script malveillant dans le champ content. Tout utilisateur — y compris les administrateurs — qui visite la page de l'article de blog exécutera le script de l'attaquant dans le contexte de son navigateur. Les conséquences incluent le vol de session (si les cookies ne sont pas HttpOnly), des actions forcées dans la session de la victime, l'exfiltration de données depuis les pages accessibles à l'attaquant, des attaques de redressing d'interface (UI redress) et un déni de service potentiel des composants côté client.

🔐 Recommandations d'atténuation

1. Assainir/encoder le HTML stocké — Assainissez le HTML du champ content à l'entrée et/ou échappez-le à la sortie à l'aide d'un assainisseur HTML sécurisé qui supprime les balises et attributs dangereux (supprimez les attributs on*, les URI javascript:, <script>, ``, etc.). Privilégiez des bibliothèques bien maintenues.
2. Liste blanche (allowlist) HTML — Autorisez uniquement un ensemble minimal de balises/attributs sûrs nécessaires au formatage (par ex. <p>, <b>, <i>, <ul>, <li>, <a href> avec une validation stricte du href). Interdisez les gestionnaires d'événements inline.
3. Politique de sécurité du contenu (CSP) — Déployez une CSP stricte pour réduire l'impact des XSS (restreignez les sources de scripts, évitez 'unsafe-inline', utilisez des autorisations de scripts basées sur nonce/hash si nécessaire).
4. Application côté serveur — Appliquez l'assainissement côté serveur avant de stocker le contenu (ne vous fiez pas uniquement aux contrôles côté client).
5. Cookies HttpOnly & SameSite — Assurez-vous que les cookies de session sont HttpOnly et définissez les attributs SameSite appropriés pour réduire le vol de cookies et les risques de type CSRF.
6. Moindre privilège pour la création de contenu — Limitez les personnes autorisées à créer/modifier des articles de blog et auditez ces permissions.
7. Encodage contextuel — Encodez correctement le contenu fourni par l'utilisateur lorsqu'il est inséré dans des attributs HTML, des contextes JavaScript ou des URL.
8. Rejeter les entrées non sûres — Envisagez de rejeter ou de supprimer les attributs et balises dangereux au moment de l'enregistrement, en journalisant les tentatives bloquées.
9. Tests et surveillance — Ajoutez des tests unitaires/d'intégration pour vérifier le comportement de l'assainissement. Surveillez les journaux pour détecter toute activité suspecte de création/modification d'articles.
10. Correctif — Les développeurs doivent mettre à jour le pipeline d'assainissement dans Frappe/ERPNext et publier une mise à jour de sécurité ; les opérateurs doivent appliquer les mises à jour rapidement.

🔗 Références

• ERPNext GitHub : https://github.com/frappe/erpnext
• Frappe Framework GitHub : https://github.com/frappe/frappe
• Aide-mémoire OWASP sur la prévention des XSS : https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
• Base de données NVD / CVE — vérifiez l'entrée CVE-2025-56379 lorsqu'elle sera publiée

🙏 Remerciements

auteur : Mohammed Aloli

📢 Avertissement

Ce rapport est destiné uniquement à des fins de défense, de remédiation et de sensibilisation. Ne tentez pas d'exploiter cette vulnérabilité contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas d'autorisation explicite de test. Si vous utilisez ERPNext/Frappe, appliquez les correctifs, renforcez l'assainissement et suivez les recommandations d'atténuation ci-dessus.