• 赤色のリンクは、まだ日本語Codexに存在しないページ・画像です。英語版と併せてご覧ください。(詳細

このWikiはいつでも誰でも編集できます

「管理画面での SSL 通信」の版間の差分

提供: WordPress Codex 日本語版
移動先: 案内検索
(まとめ)
($_SERVER['HTTP_X_FORWARDED_PROTO']が存在しないケースが想定されていないので、Warningが出る。)
 
(3人の利用者による、間の4版が非表示)
1行目: 1行目:
{{NeedTrans}}
+
管理画面へのアクセスを簡単にかつ強制的に SSL 接続にするにはサイトの [[wp-config.php_の編集|wp-config.php]] ファイルに FORCE_SSL_ADMIN 定数を定義します。この定数をプラグインファイル内に定義しても十分ではありません。[[wp-config.php の編集|wp-config.php]] ファイルで定義する必要があります。なおここではサーバーの SSL 構成や、サイトの前でセキュアサーバー用に構成された(バーチャル)ホストはこの定数を true に設定しても正しく動作するものとします。
  
WordPress 2.6 以降から、デフォルトインストールでの管理画面への SSL 対応性が大きく向上しました。また、WordPress 4.0 以降から、FORCE_SSL_LOGINは廃止されています。
+
注意: FORCE_SSL_LOGIN は [[Version 4.0]] で廃止されました。FORCE_SSL_ADMIN を使用してください。
  
管理画面での SSL 通信を簡単に有効化し、強制使用するには、サイトの [[wp-config.php の編集|wp-config.php]] ファイルで定数を二つ定義します。これらはプラグインファイルで定義するだけでは十分ではありません。必ず [[wp-config.php の編集|wp-config.php]] ファイルを使う必要があります。
 
  
 +
== SSLによる ログインと管理画面へのアクセスを強制する <span id="To_Force_SSL_Logins_''and''_SSL_Admin_Access"></span>==
  
== SSL ログイン・管理画面アクセスを強制する ==<!-- To Force SSL Logins ''and'' SSL Admin Access -->
+
すべてのログイン、およびすべての管理画面へのアクセスを SSL を通して行うには FORCE_SSL_ADMIN 定数を true に設定します。
  
すべてのログインおよび管理画面へのアクセスを SSL を通して行うには、FORCE_SSL_ADMIN 定数を true に設定します。
+
=== 例 <span id="Example"></span> ===
 
+
=== 例 ===<!-- Example -->
+
 
<pre>
 
<pre>
 
   define('FORCE_SSL_ADMIN', true);
 
   define('FORCE_SSL_ADMIN', true);
 
</pre>
 
</pre>
  
== リバースプロキシの利用 ==<!--  Using a Reverse Proxy -->
+
== リバースプロキシの使用 <span id="Using_a_Reverse_Proxy"></span> ==
  
もし、SSL 通信を提供しているリバースプロキシーにおいて、SSL 通信を利用せずにこのオプションを設定した場合、すべてのリクエストが無限リダイレクトループに陥ります。これを避けるために、HTTP_X_FORWARDED_PROTO ヘッダの設定が必要かもしれません。
+
SSL を提供するリバースプロキシにより WordPress がホストされ、自身は SSL なしでホストされる場合、このオプションを設定すると当初すべてのリクエストが無限リダイレクトループに陥ります。これを避けるには HTTP_X_FORWARDED_PROTO ヘッダーを認識するように WordPress を構成してください。ここでリバースプロキシは適切に構成されており、ヘッダーを設定するものとします。
  
=== 例 ===<!-- Example -->
+
=== 例 <span id="Example"></span> ===
  
 
<pre>
 
<pre>
  define('FORCE_SSL_ADMIN', true);
+
define('FORCE_SSL_ADMIN', true);
  if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
+
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) {
 
       $_SERVER['HTTPS']='on';
 
       $_SERVER['HTTPS']='on';
 +
}
 
</pre>
 
</pre>
  
== 追加情報 ==<!-- Further Information -->
+
== 追加情報 <span id="Further_Information"></span>==
  
かなり古いバージョンのWordPress(使うべきではありませんが)あるいは少し特殊な SSL 設定(ie. SSL 証明書が異なるドメイン用のものである等)の場合、この記事の残りは役立ちます。
+
この記事の後半では古いバージョンの WordPress を使っている場合(使うべきではありませんが)、または SSL 設定が異なる場合、たとえば SSL 証明書が異なるドメイン用のものである場合等の構成を説明します。
時々、wp-admin 全体で https プロトコルを使うセキュア通信を動作させたいと思った時に、概念的に下記のような手順で動作します。
+
  
# 同一URL(ブログURL)で、セキュア(SSL 通信)とそうでない二つのバーチャルホストをセットアップする。
+
https プロトコルを使用したセキュアな接続上で wp-admin 全体を動作させたいとします。このとき大きく以下の手順で設定します。
# セキュアなバーチャルホストでは、wp-admin 以外のすべてのトラフィックをセキュアでないサイトへ転送する rewrite ルールを設定する。
+
# セキュアでないバーチャルホストでは、wp-admin のすべてのトラフィックをセキュアなバーチャルホストへ転送する rewrite ルールを設定する。
+
# wp-adminでhttps を利用するための管理リンクの書き換え、暗号化通信でのみ動作するための cookieの編集をするために、一度だけ有効にするフィルタやプラグインを設置する。
+
  
下記のガイドは、WordPress 1.5 と httpd.conf(.htaccess ではなく)のリライトルールを利用した mod_rewrite 搭載のApache 用ですが、他のホスティングのケースに修正することは簡単です。
+
# 同一 URL (ブログ URL) で、セキュア (SSL 通信) とセキュアでない2つのバーチャルホストを設定する。
 +
# セキュアなバーチャルホストでは、wp-admin 以外のすべてのトラフィックをセキュアでないサイトへ転送する Rewrite ルールを設定する。
 +
# セキュアでないバーチャルホストでは、wp-admin のすべてのトラフィックをセキュアなバーチャルホストへ転送する Rewrite ルールを設定する。
 +
# プラグイン経由で wp-admin 内のリンク用のフィルタを定義する。一度有効化されると、管理画面へのリンクは https を使用するように書き換えられ、cookie は暗号化した接続でのみ動作するように編集される。
  
=== バーチャルホスト ===<!-- Virtual Hosts -->
+
以下のガイドでは WordPress 1.5 と httpd.conf(.htaccess ではなく)の Rewrite ルールを使用した mod_rewrite 稼働の Apache を使用します。他のホスティングのケースでも簡単に修正して適用できます。
  
セキュアでないサイトに加えて、セキュアサーバー用に設定された(バーチャル)ホストが必要です。この例では、セキュアなバーチャルホストが、セキュアでないホストと同じ <code>DocumentRoot</code> を使っています。もし仮に、wpadmin.mysite.com のような異なる名前のホストを使うことができる場合には、<code>DocumentRoot</code> を wpadmin ディレクトリにリンクします。
+
=== バーチャルホスト <span id="Virtual_Hosts"></span>===
  
セキュアなバーチャルホストの設定については、利用しているISPに問い合わせてください。あるいは、あなた自身が管理権限を持っている場合には、 [http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts2 you cannot use name based virtual hosting to identify different SSL servers] を参照してください。
+
セキュアでないサイトに追加して、セキュアサーバー用に設定された(バーチャル)ホストが必要です。この例ではセキュアなバーチャルホストがセキュアでないホストと同じ <code>DocumentRoot</code> を使用します。仮に wpadmin.mysite.com のような異なる名前を使用する場合は <code>DocumentRoot</code> を wpadmin ディレクトリにリンクしてください。
  
==== セキュアでないホストのリライトルール ====<!-- Rewrite Rules For The Insecure Host -->
+
セキュアなバーチャルホストの設定については、利用しているISPに問い合わせてください。管理者権限を持つ場合には自分で設定することもできます。注意: 異なる SSL サーバーの識別に名前ベースのバーチャルホストは使用できません。参照: [http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts2 http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts2]
  
セキュアでないホストの .htaccess あるいは httpd.conf の一部に、<nowiki>http://mysite.com/wp-admin/</nowiki> や <nowiki>http://mysite.com/wp-login.php</nowiki> を表示するとき、セキュアなホストへ自動的に飛ぶように、次のリライトルールを追加します。
 
  
これは、メインのWordPress リライトブロック上で行なうべきです。
+
==== セキュアでないホストの Rewrite ルール <span id="Rewrite_Rules_For_The_Insecure_Host"></span>====
 +
 
 +
セキュアでないホストの .htaccess または httpd.conf のバーチャルホスト部分に次の Rewrite ルールを追加します。<nowiki>http://mysite.com/wp-admin/</nowiki> や <nowiki>http://mysite.com/wp-login.php</nowiki> を表示する際に自動でセキュアなホストに転送されます。
 +
 
 +
メインの WordPress 系 Rewrite ブロックの上に追加する必要があります。
  
 
<pre>
 
<pre>
57行目: 58行目:
 
</pre>
 
</pre>
  
もし、パーマネントのリライトルールを使っている場合、<code>RewriteRule ^.*$ - [S=40]</code> の前に設定しなければなりません。
+
パーマリンクの Rewrite ルールを使用している場合、この行は <code>RewriteRule ^.*$ - [S=40]</code> の前に設定する必要があります。
  
ここでの重要なアイデアは、include や fopen のように直接ファイルをリクエストせずに、実際の http リクエストのみを書き換える保証をする THE_REQUEST を使っていることです。
+
上のコードで重要な点は「THE_REQUEST」の使用です。これにより実際の http リクエストのみが書き換えられ、include や fopen のようなローカルでのダイレクトなファイル要求は書き換えられないことが保証されます。
  
==== セキュアなホストのリライトルール (オプション) ====<!-- Rewrite Rules For Secure Host (Optional) -->
 
  
 +
==== セキュアなホストの Rewrite ルール (オプション) <span id="Rewrite_Rules_For_Secure_Host_(Optional)"></span>====
  
これらのリライトルールはオプションです。それらは、公開サイトへのアクセスについて安全な通信を無効にします。もし、プラグインを使ってサイトの公開部分でログインしたままにしたければ、プラグインが安全でない通信のCookieを無効にする場合もあるので、これらのルールは追加してはいけません。
+
以下の Rewrite ルールはオプションです。このルールによりセキュアな接続上のパブリックなサイトへのアクセスは無効化されます。以下のプラグインを使用してサイトのパブリックな部分にログインしたままにしたければ、このルールを追加しないでください。暗号化されていない接続上でプラグインが cookie を無効化します。
  
安全なバーチャルホストは、.htaccess か バーチャルホスト設定内に二つのリライトルール([[パーマリンクの使い方]]を参照)を持っておくべきです。
+
セキュアなバーチャルホストでは .htaccess ファイル内、またはバーチャルホストの宣言内で2つの Rewrite ルールを定義する必要があります (Rewrite の詳細については「[[パーマリンクの使い方]]」を参照してください)。
  
 
<pre>
 
<pre>
73行目: 74行目:
 
</pre>
 
</pre>
  
最初のルールは、セキュアなサイトへのトラフィックをセキュアでないサイトシャッフルする次のルールから wp-admin ディレクトリを除外します。
+
最初のルールは次の2番目のルールの対象から wp-admin ディレクトリを除外します。2番目のルールはセキュアサイトへのアクセスをセキュアでないサイトへのアクセスに変換します。閲覧者が意識することはなく快適さが保たれます。
  
==== WordPress URIを設定する ====<!-- Setting WordPress URI -->
+
==== WordPress URIを設定する <span id="Setting_WordPress_URI"></span>====
 +
ある種のプラグインの動作のため、または何らかの理由によりオプションに WordPress URI を設定し https プロトコルを反映するには <nowiki>https://mysite.com</nowiki> を設定します。ブログのアドレスは変わりません。
  
For some plugins to work, and for other reasons, you may wish to set your WordPress URI in options to reflect the https protocol by making this setting <nowiki>https://mysite.com</nowiki>.  Your blog address should not change.
+
====構成例(一部) <span id="Example_Config_Stanzas"></span>====
  
====Config の一節の例 ====<!-- Example Config Stanzas -->
+
注意: 以下の構成は WordPress 2.8 以上と 100% 互換ではありません。これは WordPress 2.8 wp-includes フォルダーからファイルを使用するためです。はじめの Rewrite ルールによるリダイレクトからセキュリティの警告が出る場合があります。詳細情報については [http://core.trac.wordpress.org/ticket/10079 http://core.trac.wordpress.org/ticket/10079] を参照してください。
 
+
NOTE: The below config is not 100% compatible with WordPress 2.8+, WordPress 2.8 uses some files from the wp-includes folder. The redirection that the first set of Rewrite rules introduces may cause security warnings for some users. See http://core.trac.wordpress.org/ticket/10079 for more information. [Added by DD32, Sorry, Not sure on the exact changes needed here, and i cant test it. This is added to serve as a warning to any new visitors, If you implement this, and get CodePress working in the  wp-includes folder correctly, could you please update the below example and remove my paragraph here?]
+
 
+
I think the correct usage would be:
+
<pre>
+
        <IfModule mod_rewrite.c>
+
                RewriteEngine On
+
                RewriteRule !^/wp-(admin|includes)/(.*) - [C]
+
                RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
+
        </IfModule>
+
</pre>
+
  
 
<pre>
 
<pre>
105行目: 96行目:
 
         <IfModule mod_rewrite.c>
 
         <IfModule mod_rewrite.c>
 
                 RewriteEngine On
 
                 RewriteEngine On
                 RewriteRule !^/wp-admin/(.*) - [C]
+
                 RewriteRule !^/wp-(admin|includes)/(.*) - [C]
 
                 RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
 
                 RewriteRule ^/(.*) http://www.mysite.com/$1 [QSA,L]
 
         </IfModule>
 
         </IfModule>
111行目: 102行目:
 
</VirtualHost>
 
</VirtualHost>
  
# 安全でないサイト
+
# セキュアでないサイト
 +
 
 
<VirtualHost *>
 
<VirtualHost *>
 
         ServerName www.mysite.com
 
         ServerName www.mysite.com
132行目: 124行目:
 
</VirtualHost></pre>
 
</VirtualHost></pre>
  
====ログインと登録URLのリライト ====<!-- Rewrite for Login and Registration -->
+
====ユーザーログインとユーザー登録の Rewrite <span id="Rewrite_for_Login_and_Registration"></span>====
  
これはおそらく、ユーザーのログインと登録にSSLを利用することをお勧めします。次の代替RewriteRulesを検討しましょう。
+
ユーザーログインとユーザー登録にも SSL を使用することは良い考えです。次の更新版 Rewrite ルールを検討してください。
  
===== 安全ではない書き方 =====<!-- Insecure -->
+
===== セキュアでないホスト <span id="Insecure"></span> =====
  
 
<pre>RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]</pre>
 
<pre>RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]</pre>
  
===== セキュアな書き方 =====<!-- Secure -->
+
===== セキュアなホスト <span id="Secure"></span>=====
  
 
<pre>RewriteRule !^/wp-(admin|login|register)(.*) - [C]</pre>
 
<pre>RewriteRule !^/wp-(admin|login|register)(.*) - [C]</pre>
  
==== 443番または80番ポートでサイトを動作させるリライト====<!-- Rewrite for sites running on port 443 or port 80 -->
+
==== 443番または80番ポートで動作するサイトの Rewrite <span id="Rewrite_for_sites_running_on_port_443_or_port_80"></span>====
  
 
<pre>
 
<pre>
# BEGIN WordPress
+
# WordPress 開始
 
<IfModule mod_rewrite.c>
 
<IfModule mod_rewrite.c>
 
RewriteEngine On
 
RewriteEngine On
 
RewriteBase /
 
RewriteBase /
  
# For a site running on port 443 or else (http over ssl)
+
# 443番ポート等で動作するサイト (http over ssl)
 
RewriteCond %{SERVER_PORT}  !^80$
 
RewriteCond %{SERVER_PORT}  !^80$
 
RewriteRule !^wp-(admin|login|register)(.*) - [C]
 
RewriteRule !^wp-(admin|login|register)(.*) - [C]
 
RewriteRule ^(.*)$ http://%{SERVER_NAME}/$1 [L]
 
RewriteRule ^(.*)$ http://%{SERVER_NAME}/$1 [L]
  
# For a site running on port 80 (http)
+
# 80番ポートで動作するサイト (http)
 
RewriteCond %{SERVER_PORT}  ^80$
 
RewriteCond %{SERVER_PORT}  ^80$
 
RewriteCond %{REQUEST_FILENAME} -f [OR]
 
RewriteCond %{REQUEST_FILENAME} -f [OR]
171行目: 163行目:
 
</pre>
 
</pre>
  
=== まとめ ===<!-- Summary -->
+
=== まとめ <span id="Summary"></span>===
This method does ''not'' fix some [http://wordpress.org/support/topic/24558#post-154136 inherent security risks] in WordPress, nor does it protect you against man-in-the-middle attacks or other risks that can cripple secure connections.
+
  
However, this ''should'' make it much harder for a malicious person to steal your cookies and/or authentication headers (if using a server based [http://dev.webadmin.ufl.edu/~dwc/2005/03/10/http-authentication-plugin/ authentication mechanism], which is <strike>[http://norman.rasmussen.org/77/imap-authentication-plugin/ now possible]</strike> *) starting with WordPress 1.5) and use them to impersonate you and gain access to wp-admin.  It also obfuscates the ability to sniff your content, which could be important for legal blogs which may have drafts of documents that need strict protection.
+
この方法は WordPress に [http://wordpress.org/support/topic/24558#post-154136 内在するセキュリティリスク] を修正しません。また、内部ユーザーからの攻撃やセキュアな接続を脅かすその他のリスクからも WordPress を保護しません。
  
*) site no longer available
+
それでも悪意あるユーザーによる cookie や認証ヘッダの取得、および管理者を偽装した wp-admin へのアクセスを非常に難しくします。またコンテンツが盗み見される可能性を減らします。ドラフト文書を保持する法律関連のブログなど厳格な保護が必要なサイトでは重要です。
  
=== 認証 ===<!-- Verification -->
 
  
On the author's server, logs indicate that both GET and POST requests are over SSL and that all traffic to wp-admin on the insecure host is being shuttled over to the secure host.
+
=== 検証 <span id="Verification"></span>===
  
Sample POST log line:
+
筆者のサーバーログで確認したところ GET リクエストと POST リクエストの両方が SSL を使用し、セキュアでないホスト上のすべての wp-admin へのトラフィックがセキュアなホストに転送されました。
 +
 
 +
サンプルの投稿ログ:
 
<pre>
 
<pre>
 
[Thu Apr 28 09:34:33 2005] [info] Subsequent (No.5) HTTPS request received for child 6 (server foo.com:443)
 
[Thu Apr 28 09:34:33 2005] [info] Subsequent (No.5) HTTPS request received for child 6 (server foo.com:443)
189行目: 181行目:
 
</pre>
 
</pre>
  
More testing, preferably with a packet sniffer and some hardcore network analysis tools, would help to confirm.
+
実際には追加のテスト、可能であればパケットスニファーや本格的なネットワーク解析ツールを使用した確認が必要です。
 +
 
 +
 
 +
=== 制限 <span id="Limitations"></span>===
 +
 
 +
筆者の考えでは(検証はしていません)ユーザーが cookie を保存するか、フォームのフィールドベースでなく、何らかの外部の認証の仕組みを使用してブラウザにパスワードを保管し、<nowiki>http://www.mysite.com/wp-admin/</nowiki> にアクセスすると、パケットは平文で流れ、cookie または認証ヘッダを横取りされるのではないかと思います。したがって最大のセキュリティを確保するには、ユーザーは明示的に https ホストを使用するか、常に新しいセッションの最初でログインする必要があります。
 +
 
 +
 
 +
== 関連<span id="Related"></span> ==
  
=== 制限事項 ===<!-- Limitations -->
+
* [[関数リファレンス/force_ssl_admin | force_ssl_admin() ]] /[[:en:Function Reference/force_ssl_admin | en]]
 +
* [[関数リファレンス/force_ssl_content | force_ssl_content() ]] /[[:en:Function Reference/force_ssl_content | en]]
 +
* [[関数リファレンス/is_ssl | is_ssl() ]] /[[:en:Function Reference/is_ssl | en]]
  
The author assumes (but hasn't checked) that if the user has stored cookies/told their browser to remember passwords (not based on form fields but if using certain external auth mechanism) and hits <nowiki>http://www.mysite.com/wp-admin/</nowiki>, those packets are sent in the clear and the cookie/auth headers could be intercepted.  Therefore, to ensure maximum security, the user should explicitly use the https host or always log in at the beginning of new sessions.
 
  
{{原文|Administration Over SSL|94218}}<!-- 2010-10-30T03:38:46 AskApache  版 -->
+
{{原文|Administration Over SSL|155115}}<!-- 23:17, 26 December 2015‎ Atachibana版 -->
  
 +
{{DEFAULTSORT:かんりがめんでの SSL つうしん}}
 
[[Category:上級トピック]]
 
[[Category:上級トピック]]
[[Category:セキュリティ]]<!-- 試験的カテゴリ -->
+
[[Category:セキュリティ]]
 
[[Category:wp2.6]]
 
[[Category:wp2.6]]
 +
[[Category:wp4.0]]
  
 
[[en:Administration Over SSL]]
 
[[en:Administration Over SSL]]
 +
[[ja:管理画面での SSL 通信]]

2016年1月29日 (金) 12:22時点における最新版

管理画面へのアクセスを簡単にかつ強制的に SSL 接続にするにはサイトの wp-config.php ファイルに FORCE_SSL_ADMIN 定数を定義します。この定数をプラグインファイル内に定義しても十分ではありません。wp-config.php ファイルで定義する必要があります。なおここではサーバーの SSL 構成や、サイトの前でセキュアサーバー用に構成された(バーチャル)ホストはこの定数を true に設定しても正しく動作するものとします。

注意: FORCE_SSL_LOGIN は Version 4.0 で廃止されました。FORCE_SSL_ADMIN を使用してください。


SSLによる ログインと管理画面へのアクセスを強制する

すべてのログイン、およびすべての管理画面へのアクセスを SSL を通して行うには FORCE_SSL_ADMIN 定数を true に設定します。

  define('FORCE_SSL_ADMIN', true);

リバースプロキシの使用

SSL を提供するリバースプロキシにより WordPress がホストされ、自身は SSL なしでホストされる場合、このオプションを設定すると当初すべてのリクエストが無限リダイレクトループに陥ります。これを避けるには HTTP_X_FORWARDED_PROTO ヘッダーを認識するように WordPress を構成してください。ここでリバースプロキシは適切に構成されており、ヘッダーを設定するものとします。

define('FORCE_SSL_ADMIN', true);
if ( ! empty( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https' ) {
       $_SERVER['HTTPS']='on';
}

追加情報

この記事の後半では古いバージョンの WordPress を使っている場合(使うべきではありませんが)、または SSL 設定が異なる場合、たとえば SSL 証明書が異なるドメイン用のものである場合等の構成を説明します。

https プロトコルを使用したセキュアな接続上で wp-admin 全体を動作させたいとします。このとき大きく以下の手順で設定します。

  1. 同一 URL (ブログ URL) で、セキュア (SSL 通信) とセキュアでない2つのバーチャルホストを設定する。
  2. セキュアなバーチャルホストでは、wp-admin 以外のすべてのトラフィックをセキュアでないサイトへ転送する Rewrite ルールを設定する。
  3. セキュアでないバーチャルホストでは、wp-admin のすべてのトラフィックをセキュアなバーチャルホストへ転送する Rewrite ルールを設定する。
  4. プラグイン経由で wp-admin 内のリンク用のフィルタを定義する。一度有効化されると、管理画面へのリンクは https を使用するように書き換えられ、cookie は暗号化した接続でのみ動作するように編集される。

以下のガイドでは WordPress 1.5 と httpd.conf(.htaccess ではなく)の Rewrite ルールを使用した mod_rewrite 稼働の Apache を使用します。他のホスティングのケースでも簡単に修正して適用できます。

バーチャルホスト

セキュアでないサイトに追加して、セキュアサーバー用に設定された(バーチャル)ホストが必要です。この例ではセキュアなバーチャルホストがセキュアでないホストと同じ DocumentRoot を使用します。仮に wpadmin.mysite.com のような異なる名前を使用する場合は DocumentRoot を wpadmin ディレクトリにリンクしてください。

セキュアなバーチャルホストの設定については、利用しているISPに問い合わせてください。管理者権限を持つ場合には自分で設定することもできます。注意: 異なる SSL サーバーの識別に名前ベースのバーチャルホストは使用できません。参照: http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts2


セキュアでないホストの Rewrite ルール

セキュアでないホストの .htaccess または httpd.conf のバーチャルホスト部分に次の Rewrite ルールを追加します。http://mysite.com/wp-admin/ や http://mysite.com/wp-login.php を表示する際に自動でセキュアなホストに転送されます。

メインの WordPress 系 Rewrite ブロックの上に追加する必要があります。

  RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
  RewriteCond %{HTTPS} !=on [NC]
  RewriteRule ^/?(wp-admin/|wp-login\.php) https://mysite.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]

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

上のコードで重要な点は「THE_REQUEST」の使用です。これにより実際の http リクエストのみが書き換えられ、include や fopen のようなローカルでのダイレクトなファイル要求は書き換えられないことが保証されます。


セキュアなホストの Rewrite ルール (オプション)

以下の Rewrite ルールはオプションです。このルールによりセキュアな接続上のパブリックなサイトへのアクセスは無効化されます。以下のプラグインを使用してサイトのパブリックな部分にログインしたままにしたければ、このルールを追加しないでください。暗号化されていない接続上でプラグインが cookie を無効化します。

セキュアなバーチャルホストでは .htaccess ファイル内、またはバーチャルホストの宣言内で2つの Rewrite ルールを定義する必要があります (Rewrite の詳細については「パーマリンクの使い方」を参照してください)。

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

最初のルールは次の2番目のルールの対象から wp-admin ディレクトリを除外します。2番目のルールはセキュアサイトへのアクセスをセキュアでないサイトへのアクセスに変換します。閲覧者が意識することはなく快適さが保たれます。

WordPress URIを設定する

ある種のプラグインの動作のため、または何らかの理由によりオプションに WordPress URI を設定し https プロトコルを反映するには https://mysite.com を設定します。ブログのアドレスは変わりません。

構成例(一部)

注意: 以下の構成は WordPress 2.8 以上と 100% 互換ではありません。これは WordPress 2.8 が wp-includes フォルダーからファイルを使用するためです。はじめの Rewrite ルールによるリダイレクトからセキュリティの警告が出る場合があります。詳細情報については http://core.trac.wordpress.org/ticket/10079 を参照してください。

<VirtualHost nnn.nnn.nnn.nnn:443>
        ServerName www.mysite.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 ^/(.*) http://www.mysite.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.mysite.com/wp-admin/$1 [C]
                        RewriteRule ^.*$ - [S=40]
                        RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]
                        ...
                </IfModule>
         </Directory>
         ...
</VirtualHost>

ユーザーログインとユーザー登録の Rewrite

ユーザーログインとユーザー登録にも SSL を使用することは良い考えです。次の更新版 Rewrite ルールを検討してください。

セキュアでないホスト
RewriteRule ^/wp-(admin|login|register)(.*) https://www.mysite.com/wp-$1$2 [C]
セキュアなホスト
RewriteRule !^/wp-(admin|login|register)(.*) - [C]

443番または80番ポートで動作するサイトの Rewrite

# WordPress 開始
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# 443番ポート等で動作するサイト (http over ssl)
RewriteCond %{SERVER_PORT}  !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
RewriteRule ^(.*)$ http://%{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 に 内在するセキュリティリスク を修正しません。また、内部ユーザーからの攻撃やセキュアな接続を脅かすその他のリスクからも WordPress を保護しません。

それでも悪意あるユーザーによる cookie や認証ヘッダの取得、および管理者を偽装した wp-admin へのアクセスを非常に難しくします。またコンテンツが盗み見される可能性を減らします。ドラフト文書を保持する法律関連のブログなど厳格な保護が必要なサイトでは重要です。


検証

筆者のサーバーログで確認したところ GET リクエストと POST リクエストの両方が SSL を使用し、セキュアでないホスト上のすべての wp-admin へのトラフィックがセキュアなホストに転送されました。

サンプルの投稿ログ:

[Thu Apr 28 09:34:33 2005] [info] 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?acti
on=edit&post=71" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3"

実際には追加のテスト、可能であればパケットスニファーや本格的なネットワーク解析ツールを使用した確認が必要です。


制限

筆者の考えでは(検証はしていません)ユーザーが cookie を保存するか、フォームのフィールドベースでなく、何らかの外部の認証の仕組みを使用してブラウザにパスワードを保管し、http://www.mysite.com/wp-admin/ にアクセスすると、パケットは平文で流れ、cookie または認証ヘッダを横取りされるのではないかと思います。したがって最大のセキュリティを確保するには、ユーザーは明示的に https ホストを使用するか、常に新しいセッションの最初でログインする必要があります。


関連


最新英語版: WordPress Codex » Administration Over SSL最新版との差分