2016/01/07追記：このブログ全体を独自ドメインでHTTPS化しました。以下のページは関連する内容としてご参考ください。
最近このブログやGoogle+でつながりを持った方と交流させていただいています。日々勉強になるなぁ、と感じています。で、今年やろうかと思っていた「お問い合わせフォームのSSL化」が丁度話題になりまして。これをやってみようかな～、なんて思いました。
「お問い合わせフォームを共用SSL環境下に置き、キャプチャコードもつけてスパムメール防止」
えっと、セキュアなお問い合わせフォームを目標にしていました。ですが、調べるうちにいろいろわかってきたというか、自分の認識と視点を変える必要があると感じました。下記はその経緯と結論をメモしたものです。メモといえど、本気で書いています。お時間がございましたら是非、ご覧下さい。
１．お問い合わせフォームの「SSL対応」は当然だと思っていた
このブログはロリポップサーバで公開しています。（※2013/01/20 エックスサーバに移転しました）私の契約プランでは、共用SSL領域の利用がサービスの中に含まれています。で、お問い合わせフォームは当たり前のように共用SSLを使うことを当然と思っていました。
独自SSLにするまでもない、共用SSLでもどっちでもいい。
暗号化通信ができるのであれば、全然かまわないと思っていました。
サービスとして使っていない資源を有効活用してるんだよ～、とでも思っていたくらいです。
２．WordPressで共用SSLに対応する方法がないか探しました
お問い合わせフォームの設置の前提もできたので、実装方法を調べることにしました。このブログはWordPressで作られています。WordPressと言えば、プラグイン。欲しい、と思った機能はほぼ手に入る便利なプラグイン。巷にはWordPressの技術情報があふれています。嘘も本当も自分で実戦しないと結果はわからないのですが、先に実装されている方の記事は参考になりますね。
で、やっている方法としては、
- お問い合わせフォーム：「contact form 7」プラグイン使用
- SSL対応：「WordPress HTTPS」プラグイン使用
上記二つのプラグインの併せ技＋phpコードを一部編集。または、phpファイルを複製する、など。驚くほど、プラグイン「contact form 7」を使うやり方がほとんどでしたね。この方法が主流なのか、と私は認識しました。
で、私はこれに、
- キャプチャコード：「Really Simple CAPTCHA」プラグイン使用
を加えたいと思って実装テストをしました。
しかし、できませんでした。これには1つ問題がありまして、
「WordPress HTTPS」と併用すると動作しませんでした。
３．お問い合わせフォーム＋共用SSLを批判している方、発見しました
本当にできないのかな～、って思ってキャプチャコードの解析と同時進行でネット情報をさらに調べました。それでたまたまこのフォーラムに出会いました。共有SSLのサブミット先のURLの書換についてフォーラムの回答者は「contact form 7」、「Really Simple CAPTCHA」の開発者の方です。その方のサイトはこちら：http://ideasilo.wordpress.com/
この方のコメントが私には衝撃でした。
Contact Form 7 プラグインは「共有SSL」環境下では動作しません。
おそらく他の問い合わせフォームプラグインでも同様と思います。
「共有SSL」ではなく本来の真っ当な SSL の使用を推奨します。
「共有SSL」で Contact Form 7 を使用する「ハック」だの「修正」だのといった
いい加減なブログ記事をよく見かけますので、
この機会に(読んでいる皆さんにも)忠告させてもらいますが、
どれも内容は単にプラグインの動作処理を毀損しているだけのことで、
その結果重大なセキュリティ上の欠陥を招く恐れもあります。
通信を保護するために SSL を導入しているはずが結果的には脆弱にしてしまっています。
そこまでして「共有SSL」を使う意味があるのか考えてみてください。
これを見て私はビックリしました。「共用SSLはまっとうなSSLではない」といった趣旨の発言でした。また、巷の「contact form 7」 の共用SSL化の技術情報を「いい加減」とし、否定しています。確かに、巷の記事はお世辞にもあまり核心を突いた方法は紹介されていません。根本的な解決になっていないというか。phpプログラムのコードを変更する、など。
ですが、この開発者の方に対して私なりの意見はありました。そもそも個人情報を扱うプラグインを開発した方が今や一般的に当たり前のように、レンタルサーバ業者で提供されている共用SSLについての考慮をしていないのかと思い、正直ショックでした。私は思いました。こんな方が作ったプラグインなど使う価値は、ない。と。
４．ありえない、と思ってさらによいプラグインをさがしました
上記のことから、「cotact form 7」に対して少し使用することに距離を持つようになりまして、この時点でも共用SSLを使うことに意固地になっていた私は、「contact form 7」を使わない方法を探しました。他のサイトはいったいどうしているんだろう・・・みたいな。
たぶん国内・国外300サイトくらい見ました。おそらく多くも少なくもない数だと思います。ですが、お問い合わせフォームに共用SSLを対応しているサイトは私は見事に1件すら見つけられませんでした。
そして不思議なことに出くわしました。お問い合わせフォームに共用SSLの対応方法を紹介している記事があるにもかかわらず、自サイトのお問い合わせフォームには軒並み共用SSL対応していないという・・・これはとても違和感を覚えました。
ここで、「ちょっと意味がわからない」と感じるようになりました。
５．共用SSLの危険性を知ることで、意識をほぼ変えることになった
これまで私が調べて実践したことと、こうすればよいかも、みたいな提案をいくつか挙げたりして、あれやこれやとGoogle+で議論などをしていたのですが、そんな中、さくらインターネットのfaqページを教えていただきました。（※提供者：小嶋さん）
同サーバ利用者によるデータの盗聴 | さくらインターネットfaqページ
そして以下の掲載文を見ることになりました。
共有SSLは、利用するドメインによって危険性が変わります。
独自ドメイン形式 (https://secure***.sakura.ne.jp/******/) 【非推奨】
CookieやHTTP認証、プラグインによる通信内容などの機密情報を
悪意のある第三者が共有(盗聴)することが可能です。
さくらインターネットでは共有SSLと呼んでいるようですね。共用SSLと読み替えていいでしょう。
で、えっと・・・ん？
共有SSLの利用は非推奨？盗聴が可能？
これは、どういうことなんだろうか。
で、また探っていくうちに下記サイトを教えていただきました。（※提供者：Kenichi さん）
共用SSLサーバの危険性が理解されていない | 高木浩光＠自宅の日記
この記事はとても衝撃でした。
SSLの共用サーバとなると、サーバ証明書を1つで済まそうとするためか、
同じホスト名のサーバ上にパス名で分けて提供するところが後を絶たない。
なんですって。
さくらインターネットの場合は、自由にCGIプログラムを設置できるというくらいであるから、
JavaScriptの記述は自由なのだろう。そうすると、さくらインターネットが挙げている以下のケース
https://secure101.sakura.ne.jp/example.com/ のCookieは
https://secure101.sakura.ne.jp/hoge.net/ のCGIでは取得できない。
は、たとえ example.comがpath指定無し、あるいは「path=/example.com/」の指定でcookieを発行していたとしても、
攻撃者は、https://secure101.sakura.ne.jp/hoge.net/ 上に以下のようなスクリプトを設置することで、
example.comのcookie等を取得することができてしまう。
<iframe src="/example.com/" name="foo"></iframe> <ul> <li><a href="javascript:alert(foo.document.cookie)">Get cookie</a> <li><a href="javascript:alert(foo.document.body.innerText)">Get text</a> <li><a href="javascript:alert(foo.document.body.innerHTML)">Get html</a> </ul>この例にあるように、取得できるのはcookieだけではない。
cookie（やBASIC認証など）を用いてログイン状態となっているページの
コンテンツ（秘密であるはずの）も取得できてしまうし、
コンテンツの内の入力欄やボタンを操作して、あらゆる不正な操作が可能になってしまう。
では、同じホスト名の共用サーバ上
（他の利用者が自由にCGIやJavaScriptの記述ができるところ）において、
どういうことならやっても安全か（共用する他の利用者に攻撃される余地がないか）というと、
それはなかなか簡単に結論がでない。仮に条件を示せたとしても、
利用者に理解可能なものにはならないと思われるので、そもそもこのような
共用SSLサーバのサービスはやめるべきだろう。
少なくとも、ホスト名で分けて、サーバ証明書を一枚で済ませたいなら
ワイルドカード型の証明書を使えばよい。
・・・・この文章でまたショックを受けました。
６．自分にサーバ構築の経験があったことで、危険性を納得せざるを得なくなった
私はサーバ構築経験があります。共用SSLのルールも一般的なレンタルサーバの構築ルールを倣ったもの（つまり、一般のレンタルサーバ業者がしているように、パスで分けて共用SSLとして領域を作成する方法です）でした。これを当時会社に所属していた時に提案したところ、社内・社外共に全く反対はもらいませんでした。
それだけ、共用SSLに対しての危険性の認知度はとても低い。
業者ですらそうなんだから。（私が所属していた会社はお世辞にも技術力は高くはありませんでしたが）一般的には、暗号化通信されて通信系路上で盗聴されなければ別に構わない。一枚のSSL証明書を使いまわすことに、全く違和感を感じていませんでした。ですが、その構築概念が根本から間違っていたのかもしれない・・・と思うようになりました。
まるで、元々信じていたものが実は全部嘘だったと思うくらいに、です。
７．では、そもそも共用SSLの存在はなんなのか
ここで私は素朴な疑問を感じました。そもそもなぜ、レンタルサーバ業者は「共用SSL」をサービスとして提供しているのか。
私は以下を思い浮かべました。
- 独自ドメイン利用者にとって、共用SSLのドメインはかっこ悪い。それを認識させた上で独自SSLへの切り替えを自然と促すため
- SSL通信という言葉は今や昔よりは広く知られているので、標準機能として備わってないと他者比較をされた時に競り負けてしまうため
- 情報セキュリティが大きく謳われているので、暗号化通信の手段の１つとして利用者に提供するため。しかし1クライアントずつそれぞれ独自SSLでの提供だとどうしても運用コスト高。そこで証明書1枚でSSL領域を使いまわす共用SSLと言う手段をただ考え付いただけ
ちょっと隔たりがあるでしょうか。どれも業者目線ですね。利用者としての目線もあるとすれば、サービスを提供するからには責任が付いてまわると思います。同時に利用者の判断に委ねる必要もあると思います。危険性を提示した上で、利用者側に選択肢を提示する必要がある、と思います。
ちなみに、レンタルサーバ業者で共用SSLの危険性を掲載してあるのは、これだけたくさんの業者がありながら、私が見たところさくらインターネットくらいですね。そのさくらインターネットも以前までは「安全な接続」として共用SSLの利用を掲載していた事実があるようです。詳しくは 共用SSLサーバの危険性が理解されていない | 高木浩光＠自宅の日記 をご覧下さい。そして共用SSLを使い続けることに恐怖を感じるようになりました。共用SSLだから大丈夫だと思い、共用SSL環境下での公開や助言・環境構築を今まで遂行していたことに反省をしました。
私のサイトでは共用SSLは使わないことにしました。
８．お問い合わせフォームは、どの環境下に設置するのがベストか
私のブログでしたら、独自ドメイン「imamura.biz」に対して独自SSLを対応させ、その環境下でお問い合わせページを作成する。さらにスパムメール防止のため、キャプチャコードを入れるのが広く一般的だと思います。
９．お問い合わせフォームとして扱う情報は、何か
そもそも私がお問い合わせフォームとして扱う情報は具体的に何か？
- 名前
- メールアドレス
- お問い合わせ内容
です。で、どんなアクションを期待するのか。それぞれ上記の必要事項を入力して、「送信」ボタンを押す。この送信ボタンを「押す」に足る信頼をサイトが補償できるか、この疑問は残ります。しかし、SSL対応をしているだけで信用しきってもいいのかどうか。これも疑問です。
１０．そして私はこう設置しました
お問い合わせフォームは本来どうあるべきか、色々な意見を知ることができました。私は今まで、独自SSLだろうが共用SSLだろうが、単純に独自SSLならドメイン名の統一と、認証局から正式に署名をもらった証明書である、といった認識だけで、SSLをあまりよく知らずに利用していただけにすぎない、と感じるようになりました。で、これまでの経緯を踏まえて、私がどう設置したかと言うと・・・全てのページのフッター部に設置しました。
2016/01/23追記
フッターに表示⇒お問い合わせ専用ページでお問い合わせ受付に変更しました。
【全ページフッターに設置】
SSL環境ではありません。独自SSLで個別でページを設けて設置するのがベストでしょうが、私がお問い合わせフォームとして頂く情報は、独自SSL環境で設置する理由はないと判断しました。また、お預かりした個人情報の取扱いについても明記してあります。
みなさん心配なのは個人情報の流出でしょうが、SSL通信だからといって流出しない、とは限りません。ちなみに、お問い合わせフォームの場合、SSLの有効な範囲としてメールサーバまでの通信経路を暗号化しているだけに過ぎないので、メールサーバには平文でメールが残ります。サーバのセキュリティが甘いとカンタンに、メールサーバのメールが読めます。
また、いつまでもメールサーバにメールを溜める（コピーを置くのももちろんダメ）を行っていないか。受信側にも注意が必要になってきます。サーバにメールのコピーを置く設定は、最小限にするのが得策だと私は思います。
何でも所詮は人が作ったものなので、完璧なものなど存在はしません。リスクは全てにおいて付いてまわります。リスクに対してどう対処するかが重要になってくると思います。例えば、巷にコンピュータウィルスが蔓延しているので、ウィルス対策ソフトをいれましょうね～といった喚起にはっと気づいて、いざソフトを導入しても、感染する時は感染します。ただし、感染の確率はいくらか減るかも知れませんが。
ところで、ウィルス対策ソフトに何十万もお金を出せますか？一般家庭的な感覚で考えてみてもらいたいです。私は出せませんね。他のフリーのウィルス対策ソフトを入れるか、値段の割にそこそこ感染を防いでくれる、つまりコストパフォーマンスがよい製品を選ぶでしょう。
何でもそう。コストパフォーマンスが優れている手段を、人は選んでいると思います。このお問い合わせフォームについても同じ考えを当てはめたまでです。
そんなに高いウィルス対策ソフトは必要ありません。お問い合わせフォームの設置にそんなに高い独自SSLは必要ないです。かといって、共用SSL環境下で設置したフォームを「暗号化で安全な通信」と言うわけにもいきません。
私は、今回の件で周りに与えるリスクを理解した上で、非SSL対応ページにお問い合わせフォームを設置しています。これをどう受け止められるかは、閲覧する方のご判断にお任せいたします。「SSLによる暗号化通信」を信頼しきってはいけない、ということです。
また、違う方法としてお問い合わせフォームの設置を辞めようとも思いました。単純にクリックするとメールクライアント（windowsメールなど）が立ち上がる。
これでいいのではないかと。しかし、それではお問い合わせの「送信ボタンを押してもらえる」ハードルが上がってしまう。メールクライアントからメールを送るのって結構抵抗あります。私は。このお問い合わせフォームを介して様々な方との交流を持たせていただいているので、必要です。そして、一度は距離を置いた「contact form 7」と「Really Simple CAPTCHA」を併用しています。これはまた巷の技術対応状況によって変更するかもしれません。
１１．まとめ
以上のポリシーの元、私はこのブログにお問い合わせフォームを設置しています。ご理解いただける方は、お気軽にご利用くださいませ。
※また、今回情報提供いただきました小嶋さん、Kenichiさんには当記事をご確認いただき、ご了承の元掲載しておりますが、本記事はあくまで私個人の意見として掲載しております。何卒、ご理解賜りますようお願い申し上げます。
このページを共有する