web-dev-qa-db-fra.com

Est-il prudent d'utiliser sslverify => true pour avec wp_remote_get/wp_remote_post

J'utilise normalement cet argument pour éviter les erreurs avec wp_remote_get et wp_remote_post

array(
    'sslverify' => false
)

Pour des raisons de sécurité, je souhaite le définir sur true (ou le supprimer car la valeur par défaut est true).

Devrais-je m'attendre à des problèmes en faisant cela?

sslcurlwp-remote-request
17
Xaver

TL; DR: Oui, supprimez ce paramètre à partir de WordPress 3.7 ou version ultérieure.

Auparavant, de nombreuses personnes ajoutaient le paramètre sslverify = false spécifiquement parce que leur installation de PHP ne permettait pas de vérifier correctement le certificat.

En règle générale, cela était dû au fait que l'installation PHP n'avait pas été mise à jour avec la dernière copie des certificats racine de l'autorité de certification. Les certificats racine changent de temps en temps et normalement, vous ne remarquerez pas ce changement car il se produit dans les mises à jour normales du navigateur. Eh bien, lorsque vous avez PHP agissant comme un navigateur pour récupérer des URL https, il a également besoin de ces mises à jour du certificat racine. Et la plupart des hôtes ne mettent jamais à jour PHP, ni aucune partie spécifique de celui-ci (comme le fichier de certificats).

Lorsque WordPress a implémenté la mise à jour automatique dans la version 3.7, il a été jugé nécessaire de mettre à niveau les API WordPress.org pour exiger une communication sécurisée. À ce moment, WordPress a commencé à inclure une copie du fichier de certificats racine de CA lui-même, provenant de Mozilla. Par conséquent, depuis WordPress 3.7, les fonctions de l'API WP_HTTP utilisent ce fichier pour vérifier les certificats, et non la version ancienne ou périmée fournie avec votre installation PHP.

Par conséquent, oui, avec WordPress 3.7 ou version ultérieure, il est conseillé de supprimer le paramètre sslverify et d’autoriser les fonctions http à effectuer une vérification de certificat appropriée. Tout serveur moderne exécutant SSL avec une clé signée par l'une des autorités de certification connues sera correctement vérifié. WP_HTTP doit avoir une copie des derniers certificats racine et le projet principal mettra à jour ce fichier de certificats dans WordPress avec les mises à jour normales.

22
Otto

Une tonne de raisons peut laisser une vérification SSL échouer. En partant d'un trop grand nombre de redirections vers de mauvais fichiers/configurations .ini ou simplement des certificats ou sous-domaines manquants. Dans tous les cas, vous aurez besoin de rechercher la raison pour cela et le réparer. Il y a no chemin autour de lui.

Mais pour temporairement contourner ce problème (supposons que vous deviez développer votre code et corriger l'erreur SSL ultérieurement), vous pouvez utiliser un filtre:

add_filter( 'https_ssl_verify', '__return_false' );

Comme vous l'exécutez lors d'une requête distante, vous devez l'envelopper dans un rappel attaché à un filtre déclenché lors d'une telle requête HTTP. Assurez-vous de vérifier si vous supprimez réellement la vérification pour le correct casier - et assurez-vous de ne l'exécuter qu'une seule fois pour ne pas sécuriser les autres demandes.

add_filter( 'http_request_args', function( $params, $url )
{
    // find out if this is the request you are targeting and if not: abort
    if ( 'foo' !== $params['foo'] )
         return $params;

    add_filter( 'https_ssl_verify', '__return_false' );

    return $params;
}, 10, 2 );

S'il s'agit d'un plugin distribué publiquement, vous souhaiterez peut-être l'associer à une simple option que l'utilisateur peut activer ou désactiver. Vous pouvez également essayer d'abord la requête vérifiée et si ce n'est pas le cas (et si l'utilisateur a opté pour une requête non signée), basculez ensuite vers une requête potentiellement non sécurisée.

Règle de base:

Effectuez jamais une requête non sécurisée jusqu'à ce que votre utilisateur accepte de le faire et connaisse les risques.

9
kaiser

WordPress peut s’appuyer sur un logiciel serveur sous-jacent (généralement cURL) pour effectuer une requête réseau. En un mot, parce que c’est ce que le logiciel est bon et fait pour.

Sur certains serveurs pour diverses raisons (je n’avais jamais pris la peine de me regarder moi-même), il est très courant que les logiciels de serveur ne puissent pas "vérifier" des connexions sécurisées, en produisant de telles erreurs.

Alors:

  • s'il s'agit d'un code privé sur les serveurs que vous contrôlez, vous devez vous assurer que les serveurs effectuent les demandes correctement et que ce paramètre n'est pas désactivé.
  • si c'est du code pour distribution publique, vous ne voudrez probablement pas le désactiver non plus, mais s'il est assez populaire, il finira par se retrouver sur des serveurs où il est cassé à un moment donné et vous devrez le supporter sous une forme cette configuration appropriée devrait permettre de la désactiver pour vos requêtes, et ainsi de suite)
4
Rarst