Sécuriser WordPress

WordPress 4.8.2 – Correctifs de sécurité

Blog Sécuriser WordPress WordPress 4.8.2 – Correctifs de sécurité
1 commentaire

Le 19 sep. 2017 l’équipe WordPress Core et Sécurité ont publié une version mineure contenant 9 patchs sécurité et 6 de maintenance.

Il est important de comprendre qu’i s’agit d’une grosse mise à jour de sécurité puisque toutes les versions de WOrdPress depuis la 2.3 ont été mises à jour. Votre site devrait se mettre à jour automatiquement, si ce n’est pas fait en 12 heures, faites le manuellement !

9 correctifs de sécurité dont certains sont plutôt gros, voici la distribution des failles avec 5 attaques XSS, 2 Path Traversal, 1 Injection SQL, 1 Redirection ouverte.

Redirection Ouverte dans les écrans d’édition des utilisateurs et termes

Rapporté par Yasin Soliman, cette vulnérabilité permet à un attaquant de changer le lien « back » après la mise à jour d’un élément.

Problème :

WordPress va imprimer le contenu du paramètre $_GET['wp_http_refferer'] et l’utilisation de la fonction esc_url() ne suffit pas pour protéger la redirection ouvert, seulement une XSS.

<?php echo esc_url( $wp_http_referer ); ?>

Correctif :

L’utilisation de la fonction WordPress wp_validate_redirect() empêchera les URLs nn autorisées d’être imprimées.

<?php echo esc_url( wp_validate_redirect( esc_url_raw( $wp_http_referer ), admin_url( 'term.php?taxonomy=' . $taxonomy ) ) ); ?>

Injection SQL dans $wpdb->prepare

Rapportée par Slavco, la méthode prepare() est vulnérable à une potentielle injection, ironique quand on sait que cette méthode sert à empêcher les injection SQL.

Problème :

Pas de vérification scalaire et l’échappement du symbole % est manquant.

La faille réside dans la requête elle-même, puisque vous pouvez y insérer des % sans échappement et qu’on peut parfois jouer avec les paramètres de la méthode, on peut y insérer d’autres variables non scalaires pour tenter de modifier la requête en y insérant des %s, %d reconnus par la méthode.

Correctif :

Vérifier chaque argument de la méthode WordPress prepare() pour qu’ils soient scalaire avec la function PHP is_scalar().

if ( ! is_scalar( $arg ) && ! is_null( $arg ) ) {

Ajouter l’échappement de  %.

$query = preg_replace( '/%(?:%|$|([^dsF]))/', '%%\\1', $query );

Path Traversal dans le code du dézippage

Rapportée par Alex Chapman, un nom de fichier corrompu mène à un path traversal, ce qui signifie que le zip pourrait se faire extraire ailleurs que dans le dossier prévu.

Problème :

Manque de validation du nom de fichier.

Correctif :

L’utilisation de la fonction WordPress validate_file() peut empêcher un zip d’être mal dézippé.

if ( 0 !== validate_file( $info['name'] ) ) {

Path Traversal dans le customizer

Rapportée par Weston Ruter, c’est la même chose qu’au-dessus, un nom de thème incorrect mène au path traversal quand on le lit dans le customizer.

Problème :

Manque de sanitization lors de la lecture du nom du thème.

$this->theme = wp_get_theme( $args['theme'] );

Correctif :

L’utilisation de la fonction WordPress validate_file() peut empêcher le nom du dossier du thème d’être le sujet du path traversal.

$this->theme = wp_get_theme( 0 === validate_file( $args['theme'] ) ? $args['theme'] : null );

XSS dans le oEmbed Discovery

Rapporté par Alex Concha, le code du oEmbed Discovery utilise une mauvaise regex.

Problème :

Cette regex mène à une possible injection de propriétés HTML habituellement interdites.

preg_match( '/ src=[\'"]([^\'"]*)[\'"]/', $html, $results );

Correctif :

D »abord, corriger la regex

preg_match( '/ src=([\'"])(.*?)\1/', $html, $results );

Puis utiliser la fonction WordPress wp_kses() pour sanitizer le tout.

$html = wp_kses( $html, $allowed_html );

XSS dans l’éditeur visuel

Rapportée par Rodolfo Assis, cette XSS réside dans le code JavaScript où le texte n’est pas décodé. La faille réside dans la lecture de ce text.

Problème :

Le décodage du texte est manquant

if ( ! this.loader && $( node ).text() !== this.text ) {

Correctif :

Décoder le texte

if ( ! this.loader && $( node ).text() !== tinymce.DOM.decode( this.text )

XSS dans l’éditeur de plugins

Rapportée par Chen Ruiqi, la sanitization du nom de fichier demandé n’était pas la solution correcte, il fallait utiliser la fonction WordPress wp_unslash().

Problème :

Sanitization non correcte

$file = sanitize_text_field( $_REQUEST['file'] );

XSS dans le nom des templates

Rapportée par Luca Sikic, les noms qui viennent du dossier du thème étaient écrit sans échappement. La faille réside dans la boite de choix/selectbox.

Problème :

Échappement manquant dans le tag  <option>.

echo "\n\t<option value='" . $templates[ $template ] . "' $selected>$template</option>";

Correctif :

Échapper le nom des templates dans les attributs avec esc_attr() puis avec esc_html() pour le contenu.

echo "\n\t<option value='" . esc_attr( $templates[ $template ] ) . "' $selected>" . esc_html( $template ) . "</option>";

XSS dans la boite de dialogue des liens

Rapportée par Anas Roubi, la boite de dialogue des liens souffre d’une possible injection de javascript: ou data:. La faille réside dans la fonction htmlUpdate().

Problème :

Le manque de sanitization lors de la mise à jour du code HTML.

Correctif :

Si on rencontre les textes javascript: ou data: alors on vide la propriété href.

if ( 'javascript:' === parser.protocol || 'data:' === parser.protocol ) 

attrs.href = '';

Que faire maintenant

Votre installation WordPress devrait se mettre à jour automatiquement dans les 12 prochaines heures grâce à la mise à jour automatique des versions mineures de maintenance et sécurité depuis WP 3.7. Si le site ne reçoit rien, faites le manuellement et forcez vos installations à se tenir à jour.

Ressources

1 commentaire

Merci Julio pour le détail technique, ça manque dans les blogposts de WP.core

Laisser un commentaire