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
Avoid using functions like  and , as well as the   pattern modifier for. While powerful and convenient, these features are inherently insecure:
 * valign="top" |


 * it's easier to put arbitrary strings into text processed by a regular expressions, which – when combined with the  pattern modifier – can lead to code injection attacks.
 * it is harder to read and maintain code that is part of a string.
 * static analysis tools won't catch warnings and errors in the code.
 * opcode caches (like APC) can't cache code mixed into strings.
 * sometimes has garbage-collection issues.
 * A loop which has a  inside will create a new function on each iteration.

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.

Inline lambda functions will make it easier to make your callback inline while retaining the benefits of code that's written in native syntax instead of strings.


 * 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:


 * 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.)
Any content that MediaWiki generates can be a vector for XSS attacks.
 * valign="top" |
 * used the  and   helper classes?


 * 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
 * Always validate that any POST data received is what you expect it to be


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

Chaînes de requête

 * valign="top" |
 * See above


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

Sessions

 * valign="top" |


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

Anxiété du relecteur

 * valign="top" |
 * Clearly added comments to explain unexpected or odd parts of your code?


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

Requêtes SQL

 * valign="top" |
 * used MediaWiki's database wrappers?


 * }

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

 * Security for developers