えんぴつぶろぐ

子育て中のフロントエンドエンジニアのブログ。

Welcart for WordPressで常時SSL化を実施したメモとSearch Replace DBの注意点

最近、Welcartを導入したWordpress常時SSL化を行う機会があったので手順や調べたことについて備忘録。
SSL化って業務では苦労した記憶しかなかったけど、個人でやるような小規模でシンプルなサイトなら意外と簡単にできることがわかった。
実際に今回は多機能が売りのエックスサーバーを使っていたのもあり、半日ちょっとで作業は完了できた。

Welcartとは

www.welcart.com

WordPressECサイトを構築するためのプラグイン&テーマ。
基本無料で使用することができる。
公式マニュアルやフォーラム上の情報も充実しているため、開発の際は公式サイトを見るだけで大抵のことが解決できたのでとても助かった。
有償のプラグインやテーマ、保守サービス、専用のサーバーなども提供されているが、スモールスタートなら無料で十分だと思う。

常時SSLのメリット

おさらい。

セキュリティリスクに対抗できる

SSL/TLSで暗号化されてないと…特に暗号化されていない公衆のWi-Fiネットワークを使ったときに、

  • Cookieの盗聴
  • ログイン情報等、通信内容の盗聴
  • 通信を乗っ取り、マルウェア(仮想通貨のマイニングなど)を仕込まれる

などのリスクがある。 SSLにより通信途上で盗聴や改ざんなどがされないことを保証する。

フィッシング被害からユーザーを守る

サイトが正規の所有者によって運営されていることを証明することで、ユーザーを偽サイトに誘導するフィッシング詐欺に対抗できる。
ただし、「自分が本物のサイトである」と証明するには、「企業実在性認証型(OV)」もしくは「EV SSL証明書」を取得しないとあまり意味がない。
今回使う「Let‘s Encrypt」というオープンソースのDV証明書は、攻撃者がフィッシングサイトのために使うケースもあるのでぶっちゃけ「本物だと証明しユーザーに安心感を与える」効果はない…。
が、今回の目的はそこではなかったのでこの問題は許容することにした。

SSL証明書の種類

  • 自己署名型
  • ドメイン認証型
    • 正当なドメイン保持者である、ということしか証明できない。フィッシングサイトの運営者がこれを使用しているケースも有る。
  • 企業実在性認証型(OV)
    • 企業が実在することを認証する。
  • EV SSL証明書
    • 実在する事業所の住所まで証明できる

ブラウザーに警告表示がでなくなる

ChromeFirefoxではアドレスバーの部分に「保護されていません」という旨のメッセージが出てしまう。

参考:主要ブラウザ(Chrome, Firefox, Edge, IE, Safari)のSSL関連挙動一覧 | briccolog|東京都渋谷区のウェブ制作会社ブリコルール

SEOに有利

Googleでは2014年8月からHTTPS対応のWebサイトの順位を優遇するロジックとなっている。

(HTTP/2を使用した場合)Web表示速度の向上

HTTP/1.1に比較して表示速度が高速なHTTP/2はSSL化が必須。

アクセス解析の精度が向上

Googleはすでに常時SSLされているため、自分のサイトがHTTPSであればリファラが引き継がれる。
HTTPSページからHTTPページへの移動では、リファラリンク元)の情報が引き継がれない。

開発効率の向上

環境がHTTPSに統一されることで、HTTP/HTTPSを行き来する際の実装について考慮しなくて済む。

例えばCookieはセキュア属性を使うとHTTPSでのみ送受信可能で、HTTP環境とは共有できない。
かといって使わずにセッションIDなどをCookieに保存すると盗聴・なりすましのリスクもあった。

参考

常時SSL化の手順

基本的にWelcart上のマニュアルの手順通り進めればOK。
今回は、エックスサーバーを使った手順となっている。

参考

1.SSLをサーバーにインストール

エックスサーバーでは無料独自SSLが使える。

  • エックサーバーに設置するWebサイトを対象なら無料で使用できる。
  • SSLサーバー証明書ブランドは「Let's Encrypt」
  • 発行されるSSL証明書の署名アルゴリズムは「SHA-2」
  • SNI SSL(ネームベース)で提供
  • 証明書の期限は90日間だが、自動で更新をしてくれる。

以下の手順に従う。

無料独自SSL設定 | レンタルサーバー【エックスサーバー】

.htaccessを編集してリダイレクトの設定

http:// でのアクセスを https:// にリダイレクトするためにApacheの設定をする。

以下の記述を .htaccess に追記。
Wordpressに関する記述よりに記述する。

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

※記述内容はサーバーによって異なるので毎回確認すること。
エックスサーバーの場合はこちら

解説

RewriteEngine On

RewriteEngine ディレクティブをONにしてURLの書き換え処理を行う。

RewriteCond %{HTTPS} !on

このRewriteCondディレクティブの条件(=HTTPS通信じゃなかったら)を満たした場合に、直後の RewriteRule ディレクティブの書き換えが行われる。

HTTPS Will contain the text "on" if the connection is using SSL/TLS, or "off" otherwise. (This variable can be safely used regardless of whether or not mod_ssl is loaded).

CondPattern(条件)の詳細:https://httpd.apache.org/docs/current/expr.html

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

任意の文字列0回以上の連続のURLにアクセスしたらhttps://から始まるURLにリダイレクト。
レスポンスコードは301。
URLの書き換え処理を終了し、以降のルールは実行しない。

.htaccessに関する資料

2.WordPressの設定を変更する

3.Welcartの設定を変更する

  • ダッシュボードの「Welcart>システム設定」の「SSLを使用する」というチェックを外す。
  • WCEX Mobile プラグインを使う場合は、「SSLを無効にする」にチェックを入れる
    • ただ、このプラグインはすでに販売終了しており、もはや必要がない。

4.ソース内のhttp:// の記述を全てhttps://に置換する

大規模なサイトほどこの手順が一番面倒かと思う。

  • エディタ等で手動で置換
  • データベースを一括置換

の二通りの方法が考えられる。 今回は小規模サイトといってもWordPressプラグイン内にプロトコルを含んだURLが大量に存在(2000箇所くらい)したのと、 シリアライズされたデータの考慮が面倒だったので、Welcartのマニュアルにある通り以下のツールを使うことにした。

interconnectit.com

Search Replace DBの使用手順

マニュアルにもライトな感じで紹介されていたツールだけど、
これはデータベースを操作できるツールを誰にでもアクセスできるWeb上に設置するので、 そのことを認識しておかないと非常に危険。
Search Replace DBのサイトにも再三危険性について記載がある。
だけど日本語でSearch Replace DBを紹介しているページには、あまりリスクやその回避方法について詳しく書かれていないのでちょっと心配になる…。

Search Replace DBのTOPに掲載されている警告文:

It has come to our attention that some users have been leaving this script on their servers despite advice to the contrary. Due to the very real dangers it can present when used that way, we now ask that you complete a form where we make sure you’re aware of these risks in order to receive the download link.

意訳:

アドバイスにもかかわらず、このスクリプトをサーバーに置きっぱなしにしているユーザーがいることがわかりました。
そのような使い方は非常に危険なので、ダウンロードリンクを受け取るためのフォームに、リスクを承知しているかを確認する欄を設けているから記入してね。

参考:

## Usage

1. *Do backups.*
2. Migrate all your website files.
3. Upload the script folder to your web root or higher. 
4. Browse to the script folder URL in your web browser.
5. Fill in the fields as needed.
6. Choose the `Dry run` button to do a dry run without searching/replacing.

データーベースとサイトの全ファイルのバックアップ

データベースを書き換える前に、必ずバックアップを取っておく。
うっかり置換作業を失敗すると詰む。
今回はバックアッププラグインBackWPupを使う。

インストールと設定手順:
定期的にWPを自動バックアップするプラグイン「BackWPup」 | 三重県のHP制作会社エフ・ファクトリー

BackWPup>ジョブ>今すぐ実行 で、バックアップファイルをダウンロード。

万が一のために復元手順も予習しておく。

データの復元手順:

「BackWPup」のバックアップデータを復元する方法 | 三重県のHP制作会社エフ・ファクトリー

Search Replace DBのダウンロード

公式サイトDownload Search Replace DBに必要事項を入力してSubmitする。

Knowledge checkもきちんと確認する。

Knowledge check*
□ I accept this script can be a security risk
□ I understand that this script must not be left in a public facing web server
□ I am a developer and I know what I'm doing!

意訳:

□ このスクリプトはセキュリティリスクがあることを承諾します。
□ 一般に公開されているWebサーバーに置きっぱなしにしてはいけないことを理解しています。
□ 私は開発者なので自分がやっていることを理解しています。

するとメールが来る。 ここにも赤字で警告が書かれている。

Important: Search Replace DB is a professional developer tool, usually for helping with migrations where command line tools are not available. If you do not understand that this tool can easily damage your database then please do not use it and hire a professional. You should ensure that the script is placed in an obfuscated subdirectory that cannot easily be reached from the front end. If you wish to keep the script online permanently for some reason, make sure that as a bare minimum you set up http authentication for the folder in which it resides, otherwise you will leave your site open to hackers. And we don't want that, do we?

意訳:

重要:Searh Replace DBはプロフェッショナルディベロッパーツールです。
通常、コマンドラインツールが使えない場所でのマイグレーションに役立ちます。
このツールがデータベースに容易に損害を与えうるというリスクを理解していない場合は、プロフェッショナルを雇いましょう。
スクリプトは、フロントエンドから容易に到達できないように、難読化されたサブディレクトリに配置してください。
なんらかの理由でスクリプトを永続的にオンライン上に設置したい場合は、最低限、フォルダに対してhttp認証を設定してください。
さもなくばサイトはハッカーに対してオープンになりますよ。

注意事項を確認できたら 「Download Search Replace DB v 3.1.0 here. 」のリンクからダウンロードする。

フォルダの設置

zipをダウンロードして解凍したら、そのフォルダを wp-content/ と同階層に設置する。
ただし、再三「難読化しろ」と注意された通り、フォルダ名は推測されにくい名前にリネームしておく。
私はパスワード生成ツールを使って、ランダムな英数字を使った。
初期の名前のままアップロードはやめよう。

/susokusarenikuinamae ←ダウンロードしたSearch Replace DBのフォルダを推測されにくい名前にリネームして設置
/wp-admin
/wp-content
/wp-includes

Basic認証をかける

使ったらすぐに消すつもりだが、念のためツールのフォルダに対してBasic認識をかけた。
エックスサーバーは.htaccessを直接いじらなくてもサーバーの管理画面上から簡単にアクセス制限が設定できた。

ブラウザでツールにアクセス

ブラウザで設置したフォルダのパスを開く。

https://ドメイン/リネームしたフォルダ名/

Dry runでプレビュー

replaceに旧ドメインwithに新ドメインを入力。
※最後の/を入力しないように気をつける。

まずはDry runでプレビューする。

live run

Dry runの結果が問題なかったらいよいよ実行。live runをクリックする。
その後、このようなアラートが表示されたが、どうもBasic認証のid/passを正しく入れてなかったということに気づく。

f:id:empitsu88:20181222155735p:plain

再度live run を押して、表示されたダイアログにBasic認証のユーザー名とパスワードを入力。

delete me

作業が終わったら、必ずdelete meを押してディレクトリを削除しておく。

5.表示確認

一通りの画面をブラウザで確認する。
mixed content errors が出ていたら、読み込んでいるリソースのプロトコルhttpsに修正して完了。