Points de sécurité vérifiés par les développeurs

Ce document est un supplément à Sécurité pour les développeurs . 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

Si vous travaillez avec…	avez-vous…
Cookies	limité l'anxiété du relecteur en utilisant $wgRequest au lieu de $_COOKIE ? récupéré les cookies en utilisant $wgRequest->getCookie(...) ? défini les cookies en utilisant $wgRequest->response()->setCookie(...) ? # Tentative pour accéder à la valeur du cookie UserID. # la valeur renvoyée n'est pas fiable; forçée à int. $sId = intval( $wgRequest->getCookie( 'UserID' ) );
Génération automatique de code	évité d'utiliser les fonctions telles que eval() et create_function(), tout comme le modificateur de modèle /e pour preg_replace(). Bien qu'elles soient puissantes et pratiques, ces fonctionnalités sont par définition non sécurisées : 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 /e – 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. create_function() présente quelques fois des problèmes de ramasse miettes. une boucle contenant create_function() crée une nouvelle fonction à chaque itération. Quelques fois ces fonctionnalités sont réellement nécessaires (visiblement eval.php doit exécuter eval();) 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. $str = preg_replace( "!" . preg_quote( $externalStr, '!' ) . "!", $replacement, $str );
Programmes externes	exécuté le programme via Shell::command() à partir de l'espace de noms MediaWiki\Shell ? 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 unsafeParams())? // échapper automatiquement les caractères dangereux $result = Shell::command( $cmd, '--version' ) ->params( 'some', 'extra', 'parameters' ) ->execute(); Notez que les anciens wfShellExec() / wfEscapeShellArg() ne sont plus recommandés car ils conduisent les développeurs à oublier d'échapper les paramètres.
Formulaires	utilisé User ::getEditToken() pour implémenter les mesures anti-CSRF? utilisé User::matchEditToken() 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 ?
Données GET	réduit l'anxiété du relecteur en utilisant $wgRequest au lieu de $_GET ? # vérifier que le paramètre d'action vaut 'purge' if ( $wgRequest->getVal( 'action' ) == 'purge' ) { ...
Sorties (API, CSS, JavaScript, HTML, XML, etc.) Tout contenu généré par MediaWiki est succeptible d'être un vecteur pour les attaques XSS.	utilisé le Html et les classes d'aide Xml ? # rawElement() échappe chaque valeur d'attribut # (qui dans ce cas est fournie par $myClass) echo Html::rawElement( 'p', [ 'class' => $myClass ] ); réduit l'anxiété du relecteur en utilisant le ResourceLoader pour fournir le CSS et les ressources JavaScript ?
CSS fournit par l'utilisateur Le CSS fourni par l'utilisateur (disons pour être utilisé dans un attribut style) doit être normalisé pour empêcher le XSS et refuser l'insertion d'images de trace (via background-image), etc.	utilisé la méthode Sanitizer::checkCss pour tout CSS reçu de l'utilisateur, éventuellement avec une classe Html. # déclarer $CSSFromUser comme CSS de l'utilisateur. echo Html::rawElement( 'p', [ 'style' => Sanitizer::checkCss( $CSSFromUser ) ] ); 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 background-image:). 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 style.
Données POST	réduit l'anxiété du relecteur en utilisant $wgRequest au lieu de $_POST Toujours valider que les données POST que vous recevez sont bien celles que vous attendiez # Vérifier que le paramètre d'action vaut 'render' if ( $wgRequest->getVal( 'action' ) == 'render' ) { ...
Chaînes de requête	Voir la section GET ci-dessus
Sessions
Anxiété du relecteur	Ajouté distinctement des commentaires pour expliquer les parties non souhaitées du code ou celles qui ne semblent pas claires ? # $wgRequest n'est pas encore disponible. Remplacé par $_GET. if ( $_GET['setupTestSuite'] !== null ) { $setupTestSuiteName = $_GET['setupTestSuite']; ...
Requêtes SQL	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 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