サポート » 使い方全般 » 特定のページをSSLにする場合のシンボリックリンク利用について

  • 解決済 ゆきんこ

    (@kitaguni_ht)


    httpとhttpsでディレクトリが異なるサーバーでお問い合わせフォームをSSL化しなければならず、お客様からシンボリックリンクの利用を提案されました。
    LinuxやUNIXの知識はなく、調べている中でなんとなくシンボリックリンクの仕組みや攻撃についてはわかってきましたが、完全に理解までは出来ていません。

    http://blog.tokumaru.org/2013/09/symlink-attack.html
    http://viral-community.com/blog/symbolic-link-hacking-1806/
    などを読み、共用サーバーではなくVPSなのですが、きちんと管理されているのならば問題ないのでは?と思ってきました。
    昨年のロリポップでの大規模な乗っ取り被害でシンボリックリンクの話題が出ていたので、いまのわたしでは大丈夫なのかと判断に迷っています。
    似たような質問(http://ja.forums.wordpress.org/topic/9983?replies=5)があり、回答にはシンボリックリンクを利用していると書いてありましたが、一年前の質問でしたので確信がもてません。
    httpとhttpsでディレクトリが異なるサーバーで特定のページをSSL化する場合にシンボリックリンクを利用しても問題ないのでしょうか?

6件の返信を表示中 - 1 - 6件目 (全6件中)
  • スレッドをつなげるのはここでいいでしょうかね? もう一つの投稿での情報がなくなってますが…

    共用サーバがクラックされた件で、攻撃者に利用されたことから奇妙な具合に有名になってしまいましたが、シンボリックリンク自体は、危険でも安全でもありません。インターネットが危険な存在にも、便利なツールにもなるというのと同じように、危険な使い方と安全な使い方があるだけです。ブログなどでセンセーショナルに、また、幾分かはお祭り騒ぎのように共用サーバの名前が溢れかえり、「シンボリックリンク」という言葉が「危険」という言葉を連想させる不幸な事態が広がってしまいましたけれど。

    シンボリックリンク自体が危険だと思うなら、金輪際そんなものは使わず、単純にハードリンクにすればよいし、リンクが嫌なら、コピーをすればいいのではないかと思います。そうではなくて、つまり、危険とは思わないなら、積極的に活用すればよいのではないでしょうか。UNIX 系の OS では普通に、さまざまな用途で使われていますし、ライブラリ関数 symlink() がなくなるという話しも聞きませんしね。

    kitaguni_ht さんの場合ですが、一般的にいえば、VPS でなら、共用サーバでのような近隣からの被害はありません。隣では別の OS が動いていますので、いくらシンボリックリンクがファイルシステムを越えられるといっても、隣の OS までは手が出せません。

    もちろん、Linux Programmer’s Manual が記述するとおり、シンボリックリンク自体のパーミッションには意味がないことも事実です(常に lrwxrwxrwx です)。ということは、その先にあるファイルやディレクトリのパーミッションには細心の注意を払う必要があるということです。が、これは権限を持ったサーバ管理者がするべきことです。

    他の投稿からわかることですが、kitaguni_ht さんは、どうやら、このサーバにアクセスできず、WordPress の管理画面しか触れないわけですよね? httpd.conf も php.ini もさわれず、それどころか、シェルアクセス権もないわけですから、サーバについては、「お客様」に任せる以外にありません。

    kitaguni_ht さんがするべきことは、WordPress 本体からの侵入を許さないように最善を尽くすことだけではないでしょうか(Apacheのログくらいは読めるようになっていた方がよいとは思いますが)。シンボリックリンクで実現できることなら、それを使えばよいし、できなければ他の方法を考えて実装すればよいと思います。完成したら、外からアクセスしてみて、セキュリティ上好ましくないことがないかどうかを調べてみればよいのではないでょうか。もちろん、うまくいったら、ここで報告をするとコミュニティの利益になります。

    以上は、私の個人的見解であって、何かを代表したり、擁護したり、批判したりする意図はまったくありません。

    Kjmtshさん>
    すみません、こちらで大丈夫です。
    もう一つの投稿(http://ja.forums.wordpress.org/topic/85488?replies=2)だと、長すぎて質問が明確になっていないかなと思いまして、質問をし直してしまいました(^^;)
    情報が分散してしまいましたね…。解決できた場合には、もう一つの投稿にもきちんとまとめて、この投稿へのリンクも貼っておきたいと思います。

    前回の質問ではお世話になりました。今回も返信ありがとうございます。
    お客さんの方には、ロリポップの件と質問に記載した2件のリンクもお見せしてあります。(反応が返ってきませんでしたが)
    最初はなんとかしなきゃと思っていましたが、サーバについては「お客様に任せる以外にない」とまさにそのような判断に至りました。もともとお客さんご自身でいろいろセキュリティ対策をしているようなので、基本的に今回のケースではサーバー管理には手を出さないことにしました。
    Apacheのログに関しても調べてみることにします。

    シンボリックリンクについては、調べて何度も読み返していくうちに、「今回のロリポップのようなケースには当てはまらないな」というところまでは理解してきまして、大丈夫ではないかと思ってきていました。
    今はっきり言われたので確信が持てました。とりあえずシンボリックリンクを試してみることにします。
    うまくいったら、まとめてご報告します。ありがとうございます。

    途中経過です。
    こちらの質問も合わせてお読みください。
    http://ja.forums.wordpress.org/topic/85488?replies=2

    お客様に、シンボリックリンクを試していただいたところ、うまくいかないようでした。
    お問い合わせフォームの”実体”は、てっきりお問い合わせフォームのページテンプレートでいいのかと思っていたのですが、どうも違うようです。

    動的なページでは上手くいかないということは、
    get_header();やget_template_part()、the_contentでお問い合わせフォーム(Contact Form 7)を呼び出しているのが、ダメなんでしょうか?

    ちょっとシナリオの理解が違うかもしれません。リンクを張るのは、「フォームの実体」ではなくて、WordPress のインストールディレクトリではないかなぁ。元記事もちゃんと書いてないので、何をどうしたかは定かではないのですが… 以下は想像です。

    ブラウザはテンプレートファイルに直接リクエストを出さないので、そこにリンクを張っても動作はしないのです。kitaguni_ht さんのイメージしているのは、フォームを表示する「ファイル」があって、そこにリンクを張るという感じだと思いますが、WordPress は少し仕組みが違うのですね。

    さて、前提から。通常の WordPress インストール先 URL が、

    http://example.com/wordpress

    そのディレクトリが、

    /var/www/wordpress/

    SSL 用の URL が、

    https://secure.example.com/

    そのディレクトリが、

    /home/rms/www/

    だとします。ここに別の WordPress をインストールすると、

    /home/rms/www/wordpress

    となりますが、その代わりに、/var/www/ 以下の WordPress 「ディレクトリ」へシンボリックリンクを張ると、こんな風になります。

    /home/rms/www/wordpress -> /var/www/wordpress

    実体はあくまで /var/www/wordpress となるようにするわけです。こうすると、FollowSymLinks が許可された Apache は、https://secure.example.com/wordpress/ へのリクエストがあったときに、/home/rms/www/wordpress/ を読み出しますが、これが /var/www/wordpress/ へのリンクなので、そちらから返ってきたデータをブラウザに送信するようになります。シンボリックリンクがある場所に通常のディレクトリがあるのと同じ振る舞いをするわけですね。たとえば、「問い合わせフォーム」が固定ページで作られていて、ページ ID が 10 だとすると、デフォルトのパーマリンク設定なら、

    https://secure.example.com/wordpress/?page_id=10

    で、そのフォームが表示されると思います。セッションは https だけれども、実際は http の方から内容が送られているという状態です。たぶん、デフォルトのパーマリンクでない設定(rewrite rule を設定している)の場合は、リンク先でも書き換えをしないとうまくいかないのではないかと想像しますが、確認していないのでわかりません。

    ただ、このとき、問題なのは、もとの WordPress 側では、要求されるままに普通の内容を Apache に渡しているだけなので、ヘッダやウィジェットやフッタなどに含まれるリンク先は全てもとのまま、

    http://example.com/wordpress/....

    をさしています。Apaceh も WordPress も言われたことをやっているだけ、結果については関知しないというわけです。一方、ブラウザはこれを認識しますから、https セッションなのに、http へのリンクが含まれているのはまずいよ、と警告を発するわけです。

    使ったことがないのでわかりませんが、たぶん、WordPress HTTPS (SSL) プラグインは、指定した特定のページの場合に、これらのリンクを

    https://secure.example.com/wordpress/...

    と書き換えてくれるのではないでしょうか。さらに、これらのリンクがクリックされたときに、もとの

    http://example.com/wordpress/...

    へリダイレクトするようになっているんでしょう。これで、「問い合わせフォーム」だけは https、他のページは http となるわけですね(あくまで想像です)。Apache もブラウザもまんまと騙されている、という感じでしょうか。

    「問い合わせフォーム」のためだけに、わざわざもう一つ WordPress をインストールするより省スペースで済みます。でもね、正直なところ、ちょっと面倒です。

    元記事での解決策、html ファイルを使う方法は、

    /home/rms/www/contact.html

    と、単独の「問い合わせフォーム」用の「ファイル」を作って設置し、WordPress 側では、フォームへのリンクを、

    https://secure.example.com/contact.html

    とするということでしょう。これはお手軽に設置できていいのですが、やはり弱点があります。

    1. 元の WordPress へのリンクがすべて http になる。
    2. ウィジェットなどで、最新投稿やランキングなどを表示していると、動的に書き変わらない。

    1. は、諦めてリンクしないという手もありますが、一旦「問い合わせフォーム」に飛んだら、ブラウザの「戻る」ボタンでしか WordPress に戻れないというのは、ユーザビリティとしてはいまいちですよね。2. は、デザインともかかわりますが、contact.php を作ってコードを書けば WordPress と同期できるとはいえ、またしても、リンクが http です。元記事の方がこれをどんな風に解決されたのかが書かれていないので、まったくわからないのですが、何らかの対策をしたことは間違いないと思います。読んだ感じでは、フォームだけ使って、リンクとかは全部外しているような気がしますけど。

    他の方法(mod_proxy?)も考えてみましたが、1 ページだけなら同じじゃん、ということで、新しい情報はありません。

    kjmtshさん>
    またまたお返事が遅くなってしまいました。すみませんm(_ _ ; )m
    いつもありがとうございます。

    どうも勘違いしていたようです。
    kjmtshさんの説明を聞いて気づいたのですが、本来のSSL化と同じとでも言いましょうか、
    一部ページだけSSL化するという考えではなく、全ページSSL化して必要なSSLページだけを呼び出すという考えで合ってますでしょうか?

    それから、先日この記事を見つけ、自分がやりたいことはこれでは!?と思いました。
    http://control.shado.jp/2013/0107025552.html
    http://qiita.com/shuhei@github/items/88b12ef6af87eb03b282

    このような構造にしなければならないみたいです。一部上記記事から抜粋しています。

    ├home
    │├.htaccess
    │└example.com
    │ ├.htaccess ⇒これをコピー
    │ ├index.php ⇒これをコピー
    │ └wp ⇒WordPress専用ディレクトリ
    └ssl
     └home
      ├.htaccess ⇒ここにコピー
      ├index.php ⇒ここにコピー
      └wp ⇒シンボリックリンク設定情報(0バイトファイル)

    サーバーが違うので、完全に当てはまるかはわからないのですが、まず.htaccessとindex.phpをコピーしなければならないようですね。非SSLディレクトリと同じ構造にする必要があるということでしょうか。
    ただ、SSLディレクトリの『wp ⇒シンボリックリンク設定情報(0バイトファイル)』がいまいちわかりません。最初、WordPressをもう一つインストールするのか?と思ったのですが、どうも違う気がします。phpファイルかなにかなんでしょうか?
    hosts_slink?を書いたファイル?

    あとは、URLをs付きにしなければならないですが、WordPress HTTPSが使えないとなるとURL直書きとかで対処しなければならないかもしれません。
    WPML使用で、WordPress HTTPS無しでちゃんとSSL化出来るのかこれまた不安要素が増えてしまいました。

    ちなみにお問い合わせフォームは全部で5つ。
    そのうちの一つはWPMLで英語化しています。と言っても、サーバーとプラグインの相性かなにかの問題でWPMLの機能で翻訳がうまくいかず英語用のお問い合わせフォームを新規で追加しました(^^;)
    なので、現在計6つあります。さらに多言語化するので増えていきます。

    今、htmlファイルを置くという話になっていますが、後の多言語化のためにテンプレート化をしなければなりません。言語追加の度に(クライアントが)htmlのテンプレを編集してお問い合わせフォームを制作し、もし何かデザインの修正があったときは、このhtmlも修正をしたのち、アップロードをお願いしたり…とさらにメンテナンス性が悪くなるなと思うとちょっと気が重たいです。
    おまけに英語用のhtmlはうまくいくんだろうかと。

    mod_proxyに関してはまだ理解があまり出来ていないので、今は手が出せなそうです。
    サーバーの問題なのかセキュリティか何かの問題なのかはわかりませんが、今回は正常に動作しないプラグインも多いので、サーバーによってこんなにも扱いが難しくなるものかと思っています。良い勉強にはなりますが(;´Д`)

    あぁ..kitaguni_ht さん、まだシンボリックリンク触ったことがなかったんですね… WordPress の開発者にとっては、必須の知識ではないですから無理もないのですが、説明が理解されていないということは痛いほどわかります。

    という考えで合ってますでしょうか?

    シンボリックリンクについては、やはり、理解できていないようです。でもね、

    wp ⇒シンボリックリンク設定情報(0バイトファイル)

    も間違えてますから、そんなに気にする必要はないかもしれません。この wp 自体がシンボリックリンクであって、「設定情報」というのは、これを書いた人がリンクを全く理解していないことを示しているだけです。知ったかぶりをしてコピペをしていると、こんなことが起こるのですね。自分でやってみればすぐわかるのに、わからなければ、書かなければいいのに、と思います。

    リンクの説明は前回書いて、それ以上の説明が思いつかないので、手元にあるタネンバウム先生の『モダン・オペレーティング・システム 第3版』から引用してみます(逐語訳ではないですが)。

    ファイルをリンクするアイディアの一つにシンボリックリンクがある。ファイルとして存在するデータ構造に二つの名前をつける代わりに、名前のついた小さなファイルを作り、それが別のファイルを指し示すようにすることができる。最初の小さなファイルが開かれると、ファイルシステムはパスをたどり、その先にあるファイルを見つけ出す。

    (シンボリックリンクは)それが指し示すファイルへのパスを含んでいて、それが開かれると、オペレーティングシステムは、そのパスをたどり、対象のファイルを開く。

    「一つのファイルに二つの名前をつける」のを「ハードリンク」、「小さなファイル」の方を「シンボリックリンク」または「ソフトリンク」と呼びます。しばしば誤解されますが、シンボリックリンクは「別名」というようなものではありません。他のファイルやディレクトリへのパスをその内容とする独立したファイルです。

    少し抽象的で難しいですかね? たぶん、この難しさは、小学生の体育の教科書のそれと似ています。教科書には、跳び箱の跳び方が書いてありますが、それを暗記するほど読んでも、跳び箱が跳べるようになるわけではありません。一方で、教科書の記述とは関係なく、生徒たちは易々と跳び箱を跳んでしまうことも確かです。私たちの世界には、体験する以外に会得することができないことがたくさんあって、これもそのひとつかもしれません。

    お示しの例にある、

    +--home--+--.htaccess(これは何のためにあるのか、意味不明)
    |        |
    |        +--example.com--+--.htaccess
    |                        |
    |                        +--index.php
    |                        |
    |                        +--wp <-----+
    |                                    |
    +--ssl--+--home--+--.htaccess        |
                     |                   |
                     +--index.php        |
                     |                   |
                     +--wp(シンボリックリンク)--+

    「意味不明」と書いた .htaccess 以外の .htaccess と index.php の中に何が書かれているか、わかりますか? あるいは、何のために、それらが置いてあるか、説明できますか? もし、理解できないようなら、Codex の Giving WordPress Its Own Directory(WordPress を専用ディレクトリに配置する)を検索して、隅から隅まで熟読してください。必要な情報は、そこに全て書かれています。また、Apache のドキュメントを併せて読めばより理解が深まります。

    上で書いたとおり、/ssl/home/ の下にある wp がシンボリックリンクです。内容は、絶対パスなら、/home/example.com/wp/ 、相対パスなら、../../home/example.com/wp/ となっています。前者なら、21 バイト、後者なら、26 バイトのサイズです。なぜそうなるかは、自分で考えてみてください。いずれにしても、0 バイトとなることは絶対にありえません。

    まず.htaccessとindex.phpをコピーしなければならないようですね。

    すでにシンボリックリンクが使えるなら、なぜ、それを使わずに、わざわざ「コピー」するのでしょう? 仮に .htaccess で、

    Options FollowSymLinks

    が記述してあると仮定しても(そんなこと一言も書いてありませんが)、index.php にリンクを張らない理由がわかりません。それに、symlink() を使わず、わざわざ、system() を使う理由もわかりません。

    kitaguni_ht さんが参照した二つのページを真似て作れば、理解はできなくとも、何とか動かせるとは思いますが、WordPress HTTPS (SSL) プラグインなしでは、問題が増えるだけで終わると思います。

    余計なお世話を承知で書きますが、kitaguni_ht さんに役立つのは、ウェブを検索するよりも、まず、職場か自宅の PC に Linux や FreeBSD のような OS をインストールして、実際にリンクを作ってみることではないでしょうか。あるいは、Apache をインストールして、mod_ssl や mod_rewrite モジュールを試すことではないでしょうか。必然的に、Apache のドキュメントを読むことになると思いますが、それもまた役立ちます。Im Anfang war die Tat(始めに、行為ありき)です。

    シンボリックリンクについては、正しい情報をもとに、ファイルシステムの構造からゆっくり学習されるのがよいと思います。「なぜそうなるのか」を知るためには、OS についての基本的な勉強が必要です。とはいえ、繰り返しますが、これは、WordPress でウェブページを作るだけなら、必須の知識ではありません。HOWTO さえわかれば十分です。

    今、htmlファイルを置くという話になっています

    現在の理解程度であれば、HTML ファイルを使うのが無難だと思います。HTML なら、100% 理解できるというのであれば、手間がかかったとしても、後々のメンテナンスコストが少なくて済みます。よくわからないが、とりあえず動くシステムを作っても、問題が起こったときに迅速な対応ができないからです。

    kitaguni_ht さんの投稿を読んでいると、HTML でも「危うい」と思ってしまうのですが、「問い合わせフォーム」なら、形式自体がすでに「テンプレート化」されているようなものではないですか? 英語が苦手とか、そういうことでしょうか? kitaguni_ht さん、HTML とスタイルシート、書けますか? 入力チェックは何でやるんでしょう? JavaScript? AJAX? それとも…? いずれにしろ、そのままでは、WordPress の機能を使うことができませんから、自分で作る以外にありません。

    HTML ファイルをいくつも用意するというのは、確かに無駄ではありますが、このとき、AJAX を使って、ブラウザから得られる情報をもとに、データベースから情報を得ればファイルは一つで済むなぁ、などと具体的なイメージが思い浮かばないのであれば、無駄であってもその解決方法が kitaguni_hi さんにとっては最良の選択になると思います。

    正常に動作しないプラグインも多い

    本来なら動くはずのプラグインが動かないというのは、正常な状態ではないですから、こちらは何をおいても解決すべき問題ではないでしょうか。単なる設定ミスなら問題ありませんが、複数のプラグインが正常動作しないということは、どこかに異常があります。単に顕在化していないだけかもしれません。正常動作する環境を作ってから利用してもらわないと、障害時のデバッグが難しくなり、逆にコストがかかります。

    気に障る表現があったかもしれませんが、悪意はありません。ご理解ください。

6件の返信を表示中 - 1 - 6件目 (全6件中)
  • トピック「特定のページをSSLにする場合のシンボリックリンク利用について」には新たに返信することはできません。