dev. guide Standards de développement XenForo - Vulnérabilités des ressources

Standards de développement XenForo​

Il est important que tous les auteurs de ressources soient conscients des normes minimales que XenForo attends d'eux lorsqu'ils publient des produits destinés à l'environnement XenForo.

Le respect de ces normes est extrêmement important pour garantir un écosystème de développement tiers fondé sur la qualité. Il est impératif, si vous avez actuellement un code qui ne respecte pas ces normes que vous vous efforciez de résoudre ces problèmes dès que possible. De même, si vous n'êtes pas sûr de respecter ces normes ou si vous avez besoin de plus d'informations sur la façon de respecter ces normes, vous devez demander de l'aide et des conseils dans le forum de discussion sur le développement.

Si des violations des normes de ressources sont constatées, elles doivent être signalées à l'auteur de la ressource en premier lieu. Si l'auteur de la ressource n'est pas en mesure de résoudre le problème ou ne parvient pas à résoudre le problème en temps opportun, la ressource doit être signalée à l'aide du bouton "Signaler" en précisant le maximum de détails sur la violation des standards XenForo.

Les normes minimales sont les suivantes :

1. Le titre du module complémentaire doit être clair quant à sa fonction, même si c'est au prix de la brièveté. Par exemple, un module complémentaire qui marque automatiquement les alertes consultées doit être intitulé "Marquage automatique de la vue des alertes" plutôt que simplement "Alertes".
2. Le module complémentaire doit pouvoir être installé.
3. Sans bogues évidents - variables indéfinies, index indéfinis, fautes d'orthographe, utilisation de $this en dehors du contexte de l'objet, etc.
4. Toutes les mises à jour de ressources publiées dans le Gestionnaire de Ressources (XFRM) doivent indiquer clairement quels problèmes (le cas échéant) ont été résolus dans la mise à jour.
5. Sauf à des fins de démonstration ou d'essai limitées dans le temps, le code ne doit pas être crypté, encodé ou autrement obscurci.
6. Les requêtes de base de données doivent principalement être effectuées à l'aide du Finder. Lorsqu'il existe une raison spécifique de ne pas le faire, les requêtes de base de données doivent utiliser l'adaptateur de base de données XF par défaut et doivent utiliser des instructions préparées.
7. De même, les modules complémentaires ne doivent pas contourner les objets Entity et doivent effectuer des lectures et des écritures à l'aide de ces objets et d'objets associés.
8. Les requêtes doivent bien évoluer et doivent éviter une situation qui augmenterait le nombre de requêtes de manière inattendue.
9. Les requêtes doivent être contraintes à l'aide des conditions appropriées pour éviter l'écrasement accidentel des données existantes.
10. Dans la mesure du possible, le gestionnaire de schéma doit être utilisé pour toutes les modifications de schéma, bien que l'utilisation de l'adaptateur de base de données pour effectuer ces requêtes soit raisonnable mais non recommandée.
11. Les éléments suivants doivent être respectés en ce qui concerne les modifications de schéma :
    1. Les nouvelles tables doivent être préfixées avec xf_ et en plus un identifiant pour le module complémentaire, par exemple xf_mg_.
    2. Les nouvelles colonnes des tables principales doivent être précédées d'un identifiant pour le module complémentaire, par exemple xfmg_.
    3. Les nouvelles colonnes des tables principales doivent avoir une valeur par défaut ou être nullables.
    4. Toutes les nouvelles tables ou colonnes ajoutées doivent être supprimées lors de la désinstallation.
    5. Dans la mesure du possible, un module complémentaire ne doit pas modifier la définition d'une colonne principale.
12. Le code complémentaire doit suivre MVC (Model-View-Controller) principles.
13. Le code complémentaire doit suivre DRY (don't repeat yourself) principles.
14. Toutes les entrées utilisateur doivent être filtrées conformément aux approches par défaut (à l'aide du filtre d'entrée XF). Les variables contenant des entrées utilisateur telles que $_POST, $_GET, $_SERVER etc... ne doivent pas être accessibles directement sans être filtrées de manière appropriée.
15. L'utilisation de JavaScript et de HTML ne doit pas être susceptible d'être exploitée par XSS. Des précautions supplémentaires doivent être prises pour échapper (ou ne pas contourner l'échappement par défaut) du contenu généré par l'utilisateur.
16. Le style de l'add-on doit être cohérent avec le style de base. Le style de base doit être utilisé dans toute la mesure du possible, y compris (mais sans s'y limiter) les styles de liste structurée, de liste de données, de bloc ou de ligne de contenu, ainsi que l'utilisation complète de la syntaxe du modèle XF pour produire des éléments de formulaire, y compris (mais sans s'y limiter) les balises comme <xf:form>, <xf:textboxrow> etc...
17. Les modifications de template doivent être utilisées pour injecter des modifications dans les templates plutôt que de modifier le template rendu dans le code.
18. Les modifications de template doivent veiller à ne pas trop remplacer un template. Cela peut nécessiter l'utilisation de méthodes plus complexes telles qu'un rappel PHP ou une correspondance d'expression régulière.
19. Les classes existantes doivent être étendues à l'aide du système XenForo Class Proxy (XFCP) via le système intégré « Extensions de classe ».
20. Lorsqu'un événement de code spécifique existe, un listener doit être créé pour l'utiliser plutôt qu'une extension de classe complète.
21. Les modules complémentaires doivent utiliser les différents systèmes de "gestionnaire" lorsqu'ils sont disponibles dans toute leur étendue plutôt que d'étendre les classes pour injecter un comportement personnalisé. Y compris, mais sans s'y limiter, la vérification du spam qui doit être implémentée à l'aide du système de gestion du vérificateur de spam plutôt que d'étendre les checkForSpam méthodes à différents endroits.
22. Si une extension de classe est requise pour étendre les méthodes principales, elle doit être étendue correctement, plutôt que remplacée, en appelant la méthode parent.
23. Si une méthode principale a différents types de retour avec différents comportements (par exemple, les actions du controler renvoient différents types d'objets de réponse), le code étendu doit vérifier qu'il fonctionne avec le type correct.
24. Les modules complémentaires ne doivent pas tenter d'ajouter des données qui ne sont pas associées au module complémentaire.
25. Les données d'ajout qui nécessitent des identifiants ou des clés uniques (telles que des modifications de template) doivent être préfixées de manière à identifier l'ajout ou le développeur.
26. Les modules complémentaires doivent utiliser tout type de rappel de licence que si cela est clairement indiqué dans la description de la ressource; usual guidelines regarding this apply.
27. Si un module complémentaire doit faire des requêtes HTTP, il doit utiliser le client HTTP XF plutôt que de faire des requêtes cURL manuellement.
28. De même, si XF possède d'autres fonctionnalités de framework, y compris (mais sans s'y limiter) l'envoi d'e-mails et la manipulation d'images, celles-ci doivent être utilisées dans la mesure du possible.
29. Les opérations du système de fichiers doivent utiliser le système de fichiers XF (qui utilise "FlySystem") en particulier pour les fichiers hébergés dans les répertoires data, internal_data ou code_cache.
30. Les bibliothèques tierces incluses dans votre version doivent disposer d'une licence appropriée.
31. Si des fonctions de type exec sont utilisées, les arguments qui leur sont passés doivent être échappés de manière appropriée.

Remarque : s'il y a des violations répétées de ces normes et que les demandes de rectification de ces violations ne sont pas résolues, nous nous réservons le droit de supprimer les ressources incriminées. Dans les cas extrêmes, les auteurs qui sont constamment en deçà des normes ici peuvent ne pas être autorisés à publier leurs ressources ici à l'avenir.

---

Source : https://xenforo.com/community/help/resource-standards/

Vulnérabilités des ressources​

Gestion des vulnérabilités de sécurité dans les ressources​

Malheureusement, les vulnérabilités de sécurité font presque partie de la vie des logiciels aujourd'hui. Les vulnérabilités peuvent être désastreuses pour les utilisateurs concernés. Par conséquent, la façon dont les développeurs résolvent les problèmes et prennent des mesures pour les prévenir est primordiale.
Pour les ressources tierces répertoriées dans la communauté XenForo France, nous souhaitons établir des directives claires pour signaler les vulnérabilités et sur la manière dont les développeurs doivent gérer les correctifs de vulnérabilité.

Signaler une vulnérabilité​

Si vous découvrez ce que vous pensez être une vulnérabilité dans une ressource, nous attendons de vous que vous suiviez une approche de divulgation responsable. Veuillez contacter l'auteur de la ressource en privé pour divulguer les détails de la vulnérabilité, y compris dans la mesure du possible :

• Une explication claire du problème
• Explication de la manière dont il peut être exploité ou importance du problème
• Étapes pour reproduire ou démontrer la preuve de concept du problème

Vous devez accorder un délai raisonnable à l'auteur pour accuser réception de votre message, déterminer les actions qu'il souhaite entreprendre et résoudre le problème. Sachez que de nombreux auteurs de ressources sont des développeurs solitaires, il est donc possible qu'ils soient simplement absents et incapables de répondre (plutôt que d'agir de mauvaise foi et de ne pas tenir compte de votre message). Veuillez attendre au moins une semaine pour obtenir une réponse avant de signaler un problème. Tant qu'un développeur vous engage activement, travaillez directement avec lui aussi longtemps que possible avant de faire remonter le problème.
Si vous ne parvenez pas à contacter l'auteur avec succès ou si l'auteur refuse de résoudre un véritable problème, veuillez alors faire remonter le problème au personnel de XenForo France. Veuillez signaler le premier message de la conversation (la divulgation initiale) et ajouter Nicolas à la conversation afin que l'équipe XenForo France puisse déterminer les mesures nécessaires à prendre. En cas de problèmes graves la ressource peut être supprimée.

Développeurs : réponse à un rapport de vulnérabilité​

Comprenez que les problèmes de sécurité sont essentiellement inévitables. Ils sont potentiellement très importants, vous devez donc traiter l'analyse d'une vulnérabilité comme une priorité absolue, même si vous pensez qu'elle n'est peut-être pas légitime.
Si vous confirmez que le problème est légitime et qu'il s'agit d'un problème grave, vous devez envisager de publier un correctif dès que possible. Les problèmes graves peuvent inclure (mais sans s'y limiter) l'injection SQL et l'exécution de code à distance ; certains problèmes XSS peuvent également être très graves. Vous devez déterminer l'importance du problème au cas par cas. Vous souhaiterez peut-être résoudre des problèmes moins graves dans votre prochaine version régulièrement planifiée ; Si vous n'êtes pas sûr de la gravité d'un problème, faites preuve de prudence et publiez un correctif dès que possible.
Lors de la publication d'une mise à jour qui résout un problème de sécurité, les détails de la mise à jour doivent inclure :

• Une indication claire qu'il y avait un correctif pour un problème exploitable
• Une explication de base du problème résolu et de ce qu'il aurait pu entraîner (par exemple, vous avez peut-être corrigé une injection SQL, ce qui pourrait compromettre la base de données et les comptes d'utilisateurs)
• Un crédit au membre qui a reporté la vulnérabilité, si le problème a été divulgué de manière responsable et que vous avez eu l'accord du membre.

Si vous ne répondez pas ou ne résolvez pas un rapport de vulnérabilité, le problème peut être transmis au personnel XenForo France. Nous pourrons peut-être vous fournir des conseils sur le problème, mais nous ne le résoudrons pas à votre place. Si le problème ne peut pas être résolu, dans les cas graves, nous devrons peut-être supprimer la ressource de la communauté XenForo France jusqu'à ce que le problème soit résolu.

---

Source : https://xenforo.com/community/help/resource-vulnerabilities/