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 potentiellement 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.

Sometimes you really do need these features (obviously  needs to run     but in most cases, we'd rather see the function broken out and referred as a 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 échappé avec [preg_quote ($externalStr, $delimiter) preg_quote]( $2, $3 ). It puts a backslash in front of every character that is part of the regular expression syntax, and escapes also the delimiter given as second parameter:


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



Programmes externes

 * valign="top" |
 * executed the program via from namespace  ?
 * quoted all arguments to external programs using the above's secure parameter passing facilities (which is basically everything except for )?

Note that old /  are not recommended because they make it easier for developers to miss escaping a parameter.
 * valign="top" |
 * valign="top" |

Formulaires

 * valign="top" |
 * used  to implement anti-CSRF measures?
 * used when checking the token to avoid timing attacks?
 * reduced reviewer anxiety by using or extending MediaWiki's existing form functionality?


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



Données GET

 * valign="top" |
 * reduced reviewer anxiety by using  instead of  ?


 * 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é les classes d'aide  et   ?


 * reduced reviewer anxiety by using ResourceLoader to deliver CSS and JavaScript resources?
 * valign="top" |
 * valign="top" |



CSS fournit par l'utilisateur
User provided CSS (Say for use in a  attribute) needs to be sanitized to prevent XSS, as well as to disallow insertion of tracking images (via background-image), etc
 * valign="top" |
 * Use the Sanitizer::checkCss method for any css received from a user, possibly along with the Html class.


 * For CSS provided by the extension (and not the user), this is not needed (and will remove some valid things like ). However, extension provided CSS should go in stylesheets loaded by ResourceLoader, and not in   attributes.
 * valign="top" |
 * valign="top" |



Données POST

 * valign="top" |
 * reduced reviewer anxiety by using  instead of
 * 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é disctinctement 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