wp_remote_get / wp_remote_postでsslverify => trueを使用しても安全ですか?


18

私は通常、この引数を使用してエラーを防ぎます wp_remote_getwp_remote_post

array(
    'sslverify' => false
)

セキュリティ上の理由から、これを設定true(またはデフォルトがtrueであるため削除)したいと思います。

それを行うことで問題を予想する必要がありますか?

回答:


23

TL; DR:はい、WordPress 3.7以降でその設定を削除します。

過去に、多くの人がsslverify = falseパラメーターを追加しました。これは、PHPのインストールが証明書を適切に検証できなかったためです。

通常、これは、PHPインストールがCAルート証明書の最新のコピーで更新されていないためです。ルート証明書は頻繁に変更されますが、通常はブラウザの通常の更新で発生するため、この変更に気付くことはありません。さて、httpsのURLを取得するためにブラウザのように動作するPHPがある場合、それらのルート証明書の更新も必要です。また、ほとんどのホストはPHPを更新せず、PHPの特定の部分(証明書ファイルなど)も更新しません。

WordPressがバージョン3.7で自動更新を実装したとき、WordPress.org APIをアップグレードして安全な通信を要求する必要があると判断されました。この時点で、WordPressには、MozillaをソースとするCAルート証明書ファイルのコピーが含まれるようになりました。したがって、WordPress 3.7以降、WP_HTTP API関数はこのファイルを使用して証明書の検証を行い、PHPインストールでパッケージ化された古いバージョンや古いバージョンではありません。

そのため、はい、WordPress 3.7以降では、sslverifyパラメーターを削除し、http機能が適切な証明書検証を実行できるようにすることをお勧めします。既知のCAのいずれかによって署名されたキーでSSLを実行している最新のサーバーは、適切に検証されます。WP_HTTPには最新のルート証明書のコピーが含まれている必要があり、コアプロジェクトはWordPressの証明書ファイルを通常の更新とともに更新します。


オットーのおかげで、これは大いに役立つと思います。私は私のプラグインでは、いくつかの条件付きチェックやる
Xaver

9

SSL検証が失敗する理由はたくさんあります。間違った.iniファイル/セットアップへのリダイレクトが多すぎるか、証明書またはサブドメインが欠落しているだけです。いずれにせよ、その理由を検索して修正する必要あります。ありませんそれを回避する方法。

ただし、この問題を一時的に回避するには(コードをさらに開発し、後でSSLエラーを修正する必要があるとしましょう)、フィルターを使用できます。

add_filter( 'https_ssl_verify', '__return_false' );

リモート要求中にこれを実行しているので、このようなHTTP要求中にトリガーされるフィルターに接続されたコールバックでラップする必要があります。正しいケースの検証を本当に削除しているかどうかを必ず確認してください。他のリクエストを保護しないために、これを一度だけ実行してください。

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 );

これが公的に配布されたプラグインである場合、ユーザーがオンまたはオフにできるシンプルなオプションにそれを添付することができます。検証済みのリクエストを最初に試すこともできます。そうでない場合(およびユーザーが署名のないリクエストを選択した場合)、安全でない可能性のあるリクエストに切り替えます。

経験則:

ユーザーが同意してリスクを認識するまで、安全でないリクエストを実行しないでください。


1
おかげで、私は自分のローカル環境上の問題のために、今探しています
Xaver

4

WordPressは、ネットワーク要求を実行するために、基礎となるサーバーソフトウェア(通常はcURL)に依存できます。簡単に言えば、それはそのソフトウェアが優れており、そのためにあるからです。

いくつかのサーバーでは、さまざまな理由で(自分のことを気にすることはありませんでした)、サーバーソフトウェアがセキュリティで保護された接続を "検証"できず、上記のエラーが発生することがよくあります。

そう:

  • それがあなたが管理するサーバー上のプライベートコードである場合、サーバーが適切にリクエストを行っており、この設定が無効になっていないことを確認してください
  • それがパブリック配布用のコードである場合、おそらくそれを無効にしたくないでしょうが、それが十分に人気がある場合、それはある時点で壊れているサーバーで終わるでしょう、そしてあなたは何らかの形でそれをサポートする必要がありますその適切な設定はリクエストなどに対して無効にする設定を提供することが期待されます
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.