セキュリティ - HTTPS - 《WordPress開発者リソース》日本語

HTTPSによる管理
- HTTPSログインとHTTPS管理アクセスを強制する
  - 例
- リバースプロキシの使用
変更履歴

HTTPSによる管理

SSLを介したWordPress管理を簡単に有効に（および強制）するには、サイトのwp-config.phpファイルに2つの定数を定義できます。これらの定数をプラグインファイルに定義するだけでは不十分で、wp-config.phpファイルに定義する必要があります。また、これらの定数をtrueに設定する前に、サーバーにSSLが構成されており、セキュアサーバー用に（仮想）ホストが構成されている必要があります。

注意: FORCE_SSL_LOGINはバージョン4.0で非推奨になりました。FORCE_SSL_ADMINを使用してください。

HTTPSログインとHTTPS管理アクセスを強制する

定数FORCE_SSL_ADMINをwp-config.phpファイルでtrueに設定すると、すべてのログインおよびすべての管理セッションがSSLを介して行われるようになります。

例

define( 'FORCE_SSL_ADMIN', true );

リバースプロキシの使用

WordPressがSSLを提供するリバースプロキシの背後にホストされているが、SSLなしでホストされている場合、これらのオプションは最初に無限リダイレクトループにリクエストを送信します。これを避けるために、WordPressがHTTP_X_FORWARDED_PROTOヘッダーを認識するように構成できます（そのヘッダーを設定するためにリバースプロキシを適切に構成していると仮定します）。

例

define( 'FORCE_SSL_ADMIN', true );
// in some setups HTTP_X_FORWARDED_PROTO might contain
// a comma-separated list e.g. http,https
// so check for https existence
if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false )
   $_SERVER['HTTPS'] = 'on';

通知

プロキシパスリダイレクションを使用している場合、リクエストをネットワークのホストに送信しますが、それに関連するヘッダーは送信しません。ただし、WordPressがリダイレクションを行うために必要なヘッダーがあります。それらを送信するには、リダイレクションにいくつかの行を追加する必要があります。

たとえば、Nginxでは、次の行を追加する必要があります:

location / {
   proxy_pass http://your_host_name:your_port;
   proxy_set_header Host $host;
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Host $server_name;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_redirect off;
}

 <a name="further-information"></a>
### さらなる情報
この記事の残りは、古いバージョンのWordPressを使用している場合（理想的には使用すべきではありません！）や、SSL設定が多少異なる場合（つまり、SSL証明書が異なるドメイン用である場合）の情報として役立ちます。  
時には、全体のwp-adminをhttpsプロトコルを使用してセキュアな接続で実行したいことがあります。概念的には、手順は次のように機能します:  
- 1*.* 同じURL（ブログURL）を持つ2つの仮想ホストを設定します。1つはセキュア、もう1つは非セキュアです。 
- 2*.* セキュア仮想ホストで、すべての非wp-adminトラフィックを非セキュアサイトにシャトルするリライトルールを設定します。 
- 3*.* 非セキュア仮想ホストで、すべてのwp-adminトラフィックをセキュアホストにシャトルするリライトルールを設定します。 
- 4*.* プラグインを介してフィルターを入れ、wp-admin内のリンクをフィルタリングして、アクティブ化されると管理リンクがhttpsを使用するように書き換えられ、暗号化された接続でのみクッキーが機能するようにします。
以下のガイドは、WordPress 1.5とApacheを使用して`````mod_rewrite`````を実行し、`````httpd.conf`````のリライトルールを使用しています（`````.htaccess`````ファイルではなく）が、他のホスティングシナリオに合わせて簡単に変更できます。  
 <a name="virtual-hosts"></a>
#### 仮想ホスト
非セキュアサイトに加えて、セキュアサーバー用に（仮想）ホストを構成する必要があります。この例では、セキュア仮想ホストは非セキュアホストと同じ`````DocumentRoot`````を使用します。仮に、wpadmin.mysite.comのような異なる名前のホストを使用し、ドキュメントルートをwpadminディレクトリにリンクすることもできます。  
ISPにセキュア仮想ホストを設定するように依頼するか、管理アクセスがある場合は自分で設定してください。[名前ベースの仮想ホスティングを使用して異なるSSLサーバーを識別することはできません](https://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts2)。  
**非セキュアホストのためのリライトルール**  
非セキュアホストの`````.htaccess`````または`````httpd.conf`````の仮想ホストスタンザに、このリライトルールを追加して、https://example.com/wp-admin/またはhttps://example.com/wp-login.phpにアクセスしたときに自動的にセキュアホストに移動します。  
これは、メインのWordPressリライトルールブロックの上に置く必要があります。  
``````bash
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^/?(wp-admin/|wp-login\.php) https://example.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]
`

パーマリンクリライトルールを使用している場合、この行はRewriteRule ^.*$ - [S=40]の前に来る必要があります。

このブロックの重要なアイデアは、THE_REQUESTを使用することで、実際のhttpリクエストのみが書き換えられ、includeやfopenのようなローカルの直接ファイルリクエストは書き換えられないことを保証します。

セキュアホストのためのリライトルール（オプション）

これらのリライトルールはオプションです。セキュア接続を介してパブリックサイトへのアクセスを無効にします。以下のプラグインを使用してサイトのパブリック部分にログインし続けたい場合は、これらのルールを追加してはいけません。プラグインは暗号化されていない接続でクッキーを無効にします。

セキュア仮想ホストには、.htaccessファイルまたは仮想ホスト宣言に2つのリライトルールが必要です（リライトに関する詳細はパーマリンクの使用を参照してください）：

RewriteRule !^/wp-admin/(.*) - [C]
RewriteRule ^/(.*) https://www.example.com/$1 [QSA,L]

最初のルールは、次のルールからwp-adminディレクトリを除外し、トラフィックをセキュアサイトから非セキュアサイトにシャッフルして、オーディエンスにとってスムーズに保ちます。

WordPress URIの設定

一部のプラグインが機能するため、また他の理由から、WordPress URIをhttpsプロトコルを反映するように設定することをお勧めします。この設定をhttps://example.comにすることで、ブログアドレスは変更されません。

設定例スタンザ

注意: 以下の設定はWordPress 2.8+と100%互換性があるわけではありません。WordPress 2.8はwp-includesフォルダからいくつかのファイルを使用します。最初のリライトルールセットによって導入されるリダイレクションは、一部のユーザーにセキュリティ警告を引き起こす可能性があります。詳細は#10079を参照してください。

<VirtualHost nnn.nnn.nnn.nnn:443>
   ServerName www.example.com
   SSLEngine On
   SSLCertificateFile /etc/apache2/ssl/thissite.crt
   SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem
   SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
   DocumentRoot /var/www/mysite
   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteRule !^/wp-(admin|includes)/(.*) - [C]
   RewriteRule ^/(.*) https://www.example.com/$1 [QSA,L]
   </IfModule>
</VirtualHost>

非セキュアサイト

<VirtualHost *>
   ServerName www.mysite.com
   DocumentRoot /var/www/ii/mysite
   <Directory /var/www/ii/mysite >
   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteBase /
   RewriteCond %{REQUEST_FILENAME} -f [OR]
   RewriteCond %{REQUEST_FILENAME} -d
   RewriteRule ^wp-admin/(.*) https://www.example.com/wp-admin/$1 [C]
   RewriteRule ^.*$ - [S=40]
   RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]
   </IfModule>
   </Directory>
</VirtualHost>

ログインと登録のためのリライト

ユーザーログインと登録にSSLを利用するのは良い考えかもしれません。以下の代替リライトルールを考慮してください。

非セキュア

RewriteRule ^/wp-(admin|login|register)(.*) https://www.example.com/wp-$1$2 [C]

セキュア

RewriteRule !^/wp-(admin|login|register)(.*) - [C]

ポート443またはポート80で実行されているサイトのためのリライト


# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# ポート443またはそれ以外（http over ssl）で実行されているサイトのために
RewriteCond %{SERVER_PORT} !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [L]
# ポート80（http）で実行されているサイトのために
RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^wp-(admin|login|register)(.*) https://%{SERVER_NAME}:10001/wp-$1$2 [L]
RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

要約

この方法は、WordPressの固有のセキュリティリスクを修正するものではなく、マンインザミドル攻撃やセキュア接続を損なう他のリスクから保護するものでもありません。

しかし、これにより、悪意のある人物がクッキーや認証ヘッダーを盗んであなたを偽装し、wp-adminにアクセスすることが非常に困難になるはずです。また、コンテンツを盗聴する能力を隠すこともでき、これは厳格な保護が必要な文書のドラフトを持つ法的ブログにとって重要かもしれません。

検証

著者のサーバーでは、ログはGETおよびPOSTリクエストがSSLを介して行われており、非セキュアホストのwp-adminへのすべてのトラフィックがセキュアホストにシャトルされていることを示しています。

サンプルPOSTログ行:

[Thu Apr 28 09:34:33 2005]
 Subsequent (No.5) HTTPS request received for child 6 (server foo.com:443)
xx.xxx.xxx.xxx - - [28/Apr/2005:09:34:33 -0500] "POST /wp-admin/post.php HTTP/1.1" 302 - "https://foo.com/wp-admin/post.php?action=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"

パケットスニファーやハードコアなネットワーク分析ツールを使用して、さらなるテストを行うことで確認できます。

制限事項

著者は（確認していませんが）ユーザーがクッキーを保存している場合やブラウザにパスワードを記憶させている場合（フォームフィールドに基づくのではなく、特定の外部認証メカニズムを使用している場合）に、https://www.example.com/wp-admin/にアクセスすると、パケットがクリアで送信され、クッキー/認証ヘッダーが傍受される可能性があると仮定しています。したがって、最大のセキュリティを確保するために、ユーザーは明示的にhttpsホストを使用するか、新しいセッションの開始時に常にログインする必要があります。

変更履歴

2022-10-25: なぜHTTPSを使用すべきかおよびSSLによる管理からの元のコンテンツ。