web-dev-qa-db-ja.com

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

私は通常 wp_remote_get と wp_remote_post でエラーを防ぐためにこの引数を使います

array(
    'sslverify' => false
)

セキュリティ上の理由から、これをtrueに設定します（またはデフォルトがtrueなので削除します）。

それをすることによって何か問題を予想するべきですか？

sslcurlwp-remote-request
17
Xaver

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

以前は、PHPをインストールしても証明書を正しく検証できなかったため、多くの人がsslverify = falseパラメータを追加しました。

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

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

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

22
Otto

SSL検証が失敗する可能性がある理由はたくさんあります。間違った.iniファイル/セットアップへのリダイレクトが多すぎる、あるいは単に証明書やサブドメインが足りないということから始めます。いずれにせよ、あなたは 理由を検索する必要があるでしょう それとそれを修正する。 no のような方法があります。

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

add_filter( 'https_ssl_verify', '__return_false' );

リモートリクエストの間にこれを実行しているので、そのようなHTTPリクエストの間に引き起こされるフィルタに付けられたコールバックでそれを包むべきです。 正しい ケース - の検証を本当に削除しているかどうかを確認し、他の要求のセキュリティが保護されないように1回だけ実行するようにしてください。

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

これが公に配布されたプラグインであるならば、あなたはそれをユーザがオンまたはオフにできる簡単なオプションに付けることを望むかもしれません。検証済みのリクエストを最初に試し、そうでない場合（そしてユーザーが署名されていないリクエストを選択した場合）は、安全でない可能性のあるリクエストに切り替えることもできます。

経験則：

ユーザーが同意してリスクを認識するまで、neverは安全でない要求を実行します。

9
kaiser

WordPressはネットワークリクエストを実行するために基盤となるサーバーソフトウェア（通常はcURL）に頼ることができます。一言で言えば、それはそのソフトウェアが優れていて、そこにあるものだからです。

いくつかのサーバーでは（さまざまな理由から（私は自分自身を覗くことに煩わされたことは一度もありませんでした））サーバーソフトウェアが安全な接続を「確認」できず、エラーを引き起こします。

そう：

  • それがあなたが管理しているサーバーのプライベートコードであれば、サーバーが正しくリクエストを行っていること、そしてこの設定が無効になっていないことを確かめるべきです
  • それが公に配布するためのコードであれば、おそらくそれも無効にしたくないでしょうが、それが十分に普及している場合は、ある時点で壊れてしまい、何らかの形でそれをサポートする必要があります。その適切な設定は、 your リクエストなどで無効にする設定を提供することが期待されています。
4
Rarst