東急お客様センターのFAQサイトがリニューアル

投稿

東急お客様センター(www.tokyu.co.jp) がリニューアルされましたね。

以前のページはフレームを使用した構造となっており、入力画面のURLやサーバー証明書が確認できないという、セキュリティに問題があるものでした。リニューアルに際し、フレームを排除して（一部iframeを使ったページがありますが）本来のURLが確認できるようになり、またアクセシビリティ的にも使いやすくなったのは嬉しいところです。

ところで、ＦＡＱサイトについて(www.tokyu.co.jp) にこんな記載がされています。

■ ＦＡＱサイトのＵＲＬは、「http://tokyu.okweb3.jp/」の表示となります。

(中略)

■ お問い合わせフォームから投稿する際のＵＲＬが、「https://ssl.okweb3.jp/tokyu/EokpControl?　」であることをご確認ください。

■ お問い合わせフォームのＳＳＬサーバ証明の発行もとは、ssl.okweb3.jpです。（ＯＫＷａｖｅ社の共用ドメインです）

外部サイトを使っていることをこれでもかと念押ししています。それ自体は結構なことだと思いますが、記載内容がいろいろおかしいですね。以下、ひとつずつ突っ込んでいきます。

  1. FAQサイトのURLが違う
  2. 投稿画面のURLも違う
  3. サーバー証明書の発行元が違う
  4. ユーザーに何を確認させるべきか

FAQサイトのURLが違う

§

■ ＦＡＱサイトのＵＲＬは、「http://tokyu.okweb3.jp/」の表示となります。

このページの下部にある「了承（FAQへ）」ボタンを押すと、表示されるページのURLは http://tokyu.okweb3.jp/EokpControl?&event=TE0008 となり、記載と異なります[1]。

厳密には、次のような経路でリダイレクトが行われます。

  1. http://tokyu.okweb3.jp/ にアクセスすると、HTML内に書かれた指定（meta refresh）により、http://tokyu.okweb3.jp/EokpControl へリダイレクトされる。
  2. 302 Moved Temporarilyにより、 http://tokyu.okweb3.jp:80/EokpControl?&event=TE0008 にリダイレクトされる。

たとえば「FAQサイトのURLは http://tokyu.okweb3.jp/ です。」なら結構なのですが、の表示となります(www.tokyu.co.jp) は事実と異なるので直した方が良いと思うのです。

投稿画面のURLも違う

§

■ お問い合わせフォームから投稿する際のＵＲＬが、「https://ssl.okweb3.jp/tokyu/EokpControl?　」であることをご確認ください。

FAQサイトの下部にある「新規お問い合わせ・ご意見・ご要望はこちらから」リンクを選択すると、表示されるページのURLは https://ssl.okweb3.jp/tokyu/EokpControl?&event=DE0001&cid=128576 となり、記載と異なります。

  • ちなみに https://ssl.okweb3.jp/tokyu/EokpControl? にアクセスすると、302によるリダイレクトが2回行われてFAQのトップに戻ってしまいます。

そもそも、URLを確認する意味はあるのでしょうか。正しいドメイン名を知っているなら「ssl.okweb3.jp」というドメインであることと、URLが https: で始まっていること（鍵アイコンが表示されていること）を確認すれば十分で、URLをフルに覚えている必要はありません。ドメイン名を知らない場合はサーバー証明書を表示して運営者名を確認する必要がありますが、この場合もURLまで確認する必要はありません。

一つ考えられるのは、OKWaveの運営する別事業者向けのページと間違えないために、URL確認を指示しているのかもしれませんが、その場合でも https://ssl.okweb3.jp/tokyu/ で始まっていることを確認すればよいだけで、「EokpControl?」以降を確認する意味はないでしょう。

サーバー証明書の発行元が違う

§

■ お問い合わせフォームのＳＳＬサーバ証明の発行もとは、ssl.okweb3.jpです。（ＯＫＷａｖｅ社の共用ドメインです）

まず発行もとという用語が謎なのですが、発行者のことでしょうか。発行者は「VeriSign, Inc.」で記載と異なります。

なお、発行対象は「OKWave Inc.」でその一般名称が「ssl.okweb3.jp」となります。万が一この値がドメイン名と異なっていたら、ブラウザが警告を出すはずなので、通常は利用者が気にする必要はありません。

よって、OKWaveの共用SSLであることを利用者向けに明記したいなら、「発行対象は OKWave Inc. です。」とするのが正しいのです。

ユーザーに何を確認させるべきか

§

根本的な話として、この注意が書かれているページ自体が暗号化されていないという問題があります。このページの記載内容がユーザーの元に届くまでに、通信経路上で改ざんされている可能性があるので、そもそも信用してよいか判断できません。

ではどうすれば安全になるか。もっとも良いのはOKWaveが契約した事業者ごとに独自の証明書での運用を可能にすることでしょうが、それができるならとっくにやっているでしょうから、他の方法を考えてみます。

次善の策として、東急電鉄が独自にサーバー証明書を取得し、お客様センターのトップページをそれで暗号化、そこからOKWaveのFAQサイトにリンクすることで安全性は確保されます。当然のことながらOKWaveへの契約料とは別に、サーバー証明書の費用がかかってしまいますが、共用SSLだけでは安全を確保することができないのですから仕方のないことでしょう。また、ユーザーは運営者を確認した後、入力ページまでの全てのページが暗号化されていることを確認しなければならないため、ちょっと面倒です。

もう一つ、鉄道事業者は駅や車内など、広告を出せる物理的な場所を持っています。東急電鉄の場合、HOTほっとTOKYU(www.tokyu.co.jp) などの広報誌も発行しているので、これらの媒体でOKWaveのURLを提示すれば信用できると言えるでしょう。もしかしたら、広告や広報誌が何物かによって差し替えられている可能性もありますが、そこは駅員が定期的にチェックしていると信用して、「数日経っても同じであれば偽物ではない」と考えて良いのではないかと思います。もちろん日常的な利用者でなければ確認できないため、あまり良い策とは言えませんが、安全でないシステムをむりやり安全に利用しようとすると、このような無理のある方法しか私には思いつきません。

脚注

  • 1.

    Cookieが無効な場合はURL中にセッションID（と思われるもの）などが含まれたものになりますが、いずれにしても記載とは異なるものです。 ↩ 戻る