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

From mediawiki.org
This page is a translated version of the page Security checklist for developers and the translation is 100% complete.

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 :[1][2]

  • 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

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

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


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

Références