Security checklist for developers/fr

Ce document est un supplément à . C'est une liste des tâches courantes de développement et des mesures de sécurité qui doivent être prises.



Liste des points de sécurité à vérifier
{| class="wikitable" | ! Si vous travaillez avec… ! avez-vous…


 * valign="top" |
 * valign="top" |



Cookies

 * valign="top" |
 * limité l'anxiété du relecteur en utilisant au lieu de   ?
 * récupéré les cookies en utilisant ?
 * défini les cookies en utilisant ?


 * valign="top" |
 * valign="top" |



Génération automatique de code
évité d'utiliser les fonctions telles que  et , tout comme le modificateur de modèle   pour. Bien qu'elles soient puissantes et pratiques, ces fonctionnalités sont par définition non sécurisées :
 * valign="top" |


 * il est plus facile de placer des chaînes arbitraires dans le texte traité par les expressions régulières, qui – lorsqu'il est combiné avec le changeur de motif  – peut conduire à des attaques d'injection de code.
 * il est plus difficile de lire et de maintenir du code qui est à l'intérieur d'une chaîne de caractères.
 * les outils statiques d'analyse ne vont pas prendre en compte les avertissements et les erreurs dans le code.
 * les caches d'opcode (tels que APC) ne peuvent pas capturer le code qui se trouve à l'intérieur de chaînes de caractères.
 * présente quelques fois des problèmes de ramasse miettes.
 * une boucle contenant  crée une nouvelle fonction à chaque itération.

Quelques fois ces fonctionnalités sont réellement nécessaires (visiblement  doit exécuter  ) mais dans la plupart des cas la fonction va échouer étant considérée comme une fonction de callback.

Les fonctions lambda en ligne rendront plus facile l'implémentation des fonctions callback en ligne tout en gardant les bénéfices du code qui a été écrit dans la syntaxe native au lieu d'utiliser les chaînes de caractères.


 * tout ce qui est externe et qui est utilisé comme partie d'une expression régulière, doit être évité avec preg_quote ($externalStr, $delimiter). Il insère une barre oblique inverse '\' devant chaque caractère faisant partie de la syntaxe de l'expression régulière et échappe également le séparateur passé en second paramètre.


 * valign="top" |
 * valign="top" |



Programmes externes

 * valign="top" |
 * exécuté le programme via à partir de l'espace de noms   ?
 * cité tous les arguments de programmes externes en utilisant les équipements de passage de paramètre sécurisé ci-dessus (ce qui veut dire basiquement tout sauf )?

Notez que les anciens  /   ne sont plus recommandés car ils conduisent les développeurs à oublier d'échapper les paramètres.
 * valign="top" |
 * valign="top" |

Formulaires

 * valign="top" |
 * utilisé  pour implémenter les mesures anti-CSRF?
 * utilisé pour contrôler le jeton et éviter les attaques temporelles ?
 * réduit l'anxiété du relecteur en utilisant ou en étendant la fonctionnalité existante des formulaires de MediaWiki ?


 * valign="top" |
 * valign="top" |



Données GET

 * valign="top" |
 * réduit l'anxiété du relecteur en utilisant  au lieu de   ?


 * valign="top" |
 * valign="top" |



Sorties (API, CSS, JavaScript, HTML, XML, etc.)
Tout contenu généré par MediaWiki est succeptible d'être un vecteur pour les attaques XSS.
 * valign="top" |
 * utilisé le  et les classes d'aide   ?


 * réduit l'anxiété du relecteur en utilisant le ResourceLoader pour fournir le CSS et les ressources JavaScript ?
 * valign="top" |
 * valign="top" |



CSS fournit par l'utilisateur
Le CSS fourni par l'utilisateur (disons pour être utilisé dans un attribut ) doit être normalisé pour empêcher le XSS et refuser l'insertion d'images de trace (via background-image), etc.
 * valign="top" |
 * utilisé la méthode Sanitizer::checkCss pour tout CSS reçu de l'utilisateur, éventuellement avec une classe Html.


 * Pour le CSS fourni par les extensions, (et non par l'utilisateur), cela n'est pas nécessaire (et peut même supprimer des éléments valides tels que ). Néanmoins le CSS fourni par les extensions doit se trouver dans les feuilles de style chargées par ResourceLoader et non pas dans les attributs.
 * valign="top" |
 * valign="top" |



Données POST

 * valign="top" |
 * réduit l'anxiété du relecteur en utilisant  au lieu de
 * toujours validé que les données POST que vous recevez sont bien celles que vous attendiez


 * valign="top" |
 * valign="top" |



Chaînes de requête

 * valign="top" |
 * voir la section GET ci-dessus


 * valign="top" |
 * valign="top" |

Sessions

 * valign="top" |


 * valign="top" |
 * valign="top" |



Anxiété du relecteur

 * valign="top" |
 * ajouté distinctement des commentaires pour expliquer les parties non souhaitées du code ou celles qui ne semblent pas claires ?


 * valign="top" |
 * valign="top" |



Requêtes SQL

 * valign="top" |
 * utilisé les conteneurs de la base de données de MediaWiki ?


 * }



Contrôles automatiques
Certains de ces problèmes peuvent être vérifiés par le greffon phan-taint-check-plugin nécessaire à tout code MediaWiki de la production Wikimedia. Bien sûr ceci ne reste qu'un outil et il ne peut détecter tous les types de problèmes, voire même les laisser passer alors qu'il en a effectué le contrôle.



Voir aussi

 * Sécurité pour les développeurs