Le 10 mai 2016, le plugin All In One WP Security & Firewall a corrigé plusieurs vulnérabilités de type SQL Injection détectées par notre équipe. Ces failles permettaient à n’importe quel visiteur de modifier des requêtes de base de données. Ceci représente un haut risque de sécurité.
Quelques explications
WordPress dispose de nombreuses API dont celle de la base de données. Cette API contient plein de wrappers, comprenez des fonctions qui utilisent de façon transparente l’API.
L’objet $wpdb permet de jouer avec la base de données pour faire des sélections, des insertions ou des suppressions (crud).
Comme tout développement, il faut se poser la question de “ai-je ici besoin de sécuriser cette ligne de code“.
Il arrive que du code faisant appel à une fonction qui fait elle même appel à une autre fonction masque la source des données à traiter, c’est là que les failles se cachent le plus souvent.
Toute donnée provenant de l’utilisateur (le navigateur aussi donc) DOIT être traitée comme si elle était malicieuse.
Les vulnérabilités
Les vulnérabilités présentes dans les versions inférieures à la 4.0.9 proviennent justement d’un manque de traitement de données utilisateurs.
Le DREAD score est évalué à 5/5 HIGH RISK. La mise à jour est obligatoire.
Ces failles permettent notamment à de simples visiteurs de modifier certaines requêtes SQL grâce à un simple paramètre dans l’URL.
Lisez la suite si vous voulez en savoir plus sur où est la faille et comment l’exploiter.
Dans le fichier /classes/wp-security-general-init-tasks.php on retrouve sur le hook init ce code :
[pastacode lang=”php” message=”” highlight=”” provider=”manual” manual=”if(isset(%24_GET%5B’aiowps_auth_key’%5D))%7B%0A%0A%20%20%20%20%20%20%20%20%20%20%20%20%2F%2FIf%20URL%20contains%20unlock%20key%20in%20query%20param%20then%20process%20the%20request%0A%0A%20%20%20%20%20%20%20%20%20%20%20%20%24unlock_key%20%3D%20strip_tags(%24_GET%5B’aiowps_auth_key’%5D)%3B%0A%0A%20%20%20%20%20%20%20%20%20%20%20%20AIOWPSecurity_User_Login%3A%3Aprocess_unlock_request(%24unlock_key)%3B%0A%0A%20%20%20%20%20%20%20%20%7D”/]
On y trouve un appel à la méthode process_unlock_request() de la classe AIOWPSecurity_User_Login. Elle prends en paramètre ce qui vient de $_GET['aiowps_auth_key'] avec un simple strip_tags().
Voyons cette méthode, que fait-elle avec notre paramètre :
[pastacode lang=”php” message=”” highlight=”” provider=”manual” manual=”static%20function%20process_unlock_request(%24unlock_key)%0A%0A%20%20%20%20%7B%0A%0A%20%20%20%20%20%20%20%20global%20%24wpdb%2C%20%24aio_wp_security%3B%0A%0A%20%20%20%20%20%20%20%20%24lockdown_table_name%20%3D%20AIOWPSEC_TBL_LOGIN_LOCKDOWN%3B%0A%0A%20%20%20%20%20%20%20%20%0A%0A%20%20%20%20%20%20%20%20%24unlock_command%20%3D%20%22UPDATE%20%22.%24lockdown_table_name.%22%20SET%20release_date%20%3D%20now()%20WHERE%20unlock_key%20%3D%20’%22.%24unlock_key.%22’%22%3B%0A%0A%20%20%20%20%20%20%20%20%24result%20%3D%20%24wpdb-%3Equery(%24unlock_command)%3B%0A%0A…”/]
Le paramètre $unlock_key est directement concaténé dans une requête sans aucun autre traitement que le précédent strip_tags().
Sauf que ce n’est pas un traitement suffisant pour empêcher les injections SQL. Pour le faire, il faut “préparer” les requête comme suit :
[pastacode lang=”php” message=”” highlight=”” provider=”manual” manual=”%24unlock_command%20%3D%20%24wpdb-%3Eprepare(%20%22UPDATE%20%22.%24lockdown_table_name.%22%20SET%20release_date%20%3D%20now()%20WHERE%20unlock_key%20%3D%20%25s%22%2C%20%24unlock_key%20)%3B”/]
L’équipe de AIOWPS a corrigé le problème très rapidement, tenez vous à jour !
