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

This page is a translated version of the page Security checklist for developers and the translation is 91% 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…


  • 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(...) ?
# Attempt to fetch the UserID cookie value. Note: The
# value returned isn't trusted and is forced to be an int.
$sId = intval( $wgRequest->getCookie( 'UserID' ) );

Génération automatique de code

Avoid using functions like eval() and create_function(), as well as the /e pattern modifier for preg_replace(). While powerful and convenient, these features are inherently insecure:[1][2]

  • it's easier to put arbitrary strings into text processed by a regular expressions, which – when combined with the /e pattern modifier – can lead to code injection attacks.
  • 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() sometimes has garbage-collection issues.
  • A loop which has a create_function() inside will create a new function on each iteration.

Sometimes you really do need these features (obviously eval.php needs to run eval() ;) 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.

  • Anything external that is used in part of regex should be escaped with preg_quote( $externalStr, $delimiter ). 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:
$str = preg_replace( "!" . preg_quote( $externalStr, '!' ) . "!", $replacement, $str );

Programmes externes

  • executed the program via Shell::command() from namespace MediaWiki\Shell?
  • quoted all arguments to external programs using the above's secure parameter passing facilities (which is basically everything except for unsafeParams())?
// Automatically escape any naughty characters
$result = Shell::command( $cmd, '--version' )
    ->params( 'some', 'extra', 'parameters' )

Note that old wfShellExec()/wfEscapeShellArg() are not recommended because they make it easier for developers to miss escaping a parameter.


Données GET

  • reduced reviewer anxiety by using $wgRequest instead of $_GET?
# Check if the action parameter is set to '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.

  • used the Html and Xml helper classes?
# rawElement() escapes all attribute values
# (which, in this case, is provided by $myClass)
echo Html::rawElement( 'p', [ 'class' => $myClass  ] );
  • reduced reviewer anxiety by using ResourceLoader to deliver CSS and JavaScript resources?

CSS fournit par l'utilisateur

User provided CSS (Say for use in a style attribute) needs to be sanitized to prevent XSS, as well as to disallow insertion of tracking images (via background-image), etc

  • Use the Sanitizer::checkCss method for any css received from a user, possibly along with the Html class.
# let $CSSFromUser be the user's CSS.
echo Html::rawElement( 'p', [ 'style' => Sanitizer::checkCss( $CSSFromUser ) ] );
  • For CSS provided by the extension (and not the user), this is not needed (and will remove some valid things like background-image:). However, extension provided CSS should go in stylesheets loaded by ResourceLoader, and not in style attributes.

Données POST

  • reduced reviewer anxiety by using $wgRequest instead of $_POST
  • Always validate that any POST data received is what you expect it to be
# Check if the action parameter is set to 'render'
if ( $wgRequest->getVal( 'action' ) == 'render' ) {

Chaînes de requête


Anxiété du relecteur

  • Clearly added comments to explain unexpected or odd parts of your code?
# $wgRequest isn't yet available.  Forced to use $_GET instead.
if ( $_GET['setupTestSuite'] !== null ) {
 	$setupTestSuiteName = $_GET['setupTestSuite'];

Requêtes SQL

Contrôles automatiques

Some of these issues can be checked with phan-taint-check-plugin, which is required for all MediaWiki code in Wikimedia production. This is of course just a tool, and it cannot detect all issue types, and may miss issues even in the issue types it can check for.

Voir aussi