利用中のWebサービスに関してセキュリティ上の懸念点に気付いた際に、専門家でなくともユーザサイドから啓発を試みるか、受け入れられなかった場合に利用中止も視野に入れた選択を行う必要があるか、という思案中(現在進行形)の話です。
Web上で機密データを送受信したい場合、httpsによってセキュアな通信が可能です。セキュアな通信を行う理由、逆に言えばセキュアでない場合に行われる不正は「盗聴」と「改竄」があります。
httpsの効能として私は主に盗聴を想定していました。例えば以下の様な形式でログイン処理を行う場合です。
- ユーザは、1-1のGET処理によってサーバにログインフォームの表示を依頼します
- サーバは、1-2のレスポンスにてログインフォームの埋め込まれたページを返します
- ユーザは、2のPOSTによってログインフォーム上に入力されたユーザIDとパスワードを送信します
「盗聴」を懸念する場合、ユーザからデータの送信時、つまり上図2のPOST通信がhttpsになっているか確認します。これで送信データがhttpsによるセキュアな通信で保護され、悪意ある第三者による盗聴が行われなくなり安全です。
と思っていました。
実際にはWeb上のセキュアでない通信は「改竄」が可能なので、「盗聴」を心配する場合においても、1-1及び1-2の時点でhttpsによるセキュアな通信が行われているか確認しなければいけません。
例えば、ログインフォームが自由に改竄可能なら、以下の様にhttpsを使わない送信フォームに掏りかえることが可能ということです。
正常なログインフォーム
<form method="post" action="https://example.com/login" ...
改竄されたログインフォーム
<form method="post" action="http://example.com/login" ...
それどころか自由に改竄可能なのであれば、そもそもの送信先すら変更が可能ということになります。
正常なログインフォーム
<form method="post" action="https://example.com/login" ...
改竄されたログインフォーム
<form method="post" action="https://phishingexample.com/login" ...
送信先そのものが、悪意ある第三者の用意したサーバでは、セキュアな通信が行われても何の意味もありません。
もし両者のあわせ技で来られたら、悪意ある第三者のサーバに送信する途中で、さらに別の悪意ある第四者？にまで盗聴される危険性すらあります。
httpsの使用時にきちんと暗号化されたセキュアな通信が行われているか、いくらテストをしたところで、そもそもの前提が崩されたら意味がありません。テストの結果が保障できるのは、正しいサーバにhttpsによる通信が行われている場合に限ったものです。
ここまでの話を前提とすると、ログインフォームが埋め込まれたWebページは表示する段階において常にhttpsを利用すべき、となります。
例えばmixiや、はてなでは、「https/SSL（セキュア)」に対して、httpの場合を「標準」と表示されていますが、むしろ機密データの送信はhttpsを「標準」とすべきではないでしょうか。
このような問題を把握した際に、私が実際に利用しているとある金融商品の取り扱い業者のサイトで心当たりがありました。その業者のWebサイトではトップページにログインフォームが埋め込まれています。
トップページは表示するだけであればセキュアである必要性は低いので、ブックマークにはhttp://で始まるURLを登録してあります。しかしログインを行おうとした際にアドレスバーから直接https://に書き換えてみたところhttp://にリダイレクトされたのです。
ソースを覗いて見たところ、プロトコルがhttps://でアクセスされた場合、http://で表示しなおすようなJavaScriptが記述されていました。またformタグのactionプロパティに設定されたデフォルトの送信先がログインフォームではなく、「JavaScriptをオンにしてください」という旨の記述されたエラーページでした。さらにこのページへのパスは相対パスで書かれているため、恐らくhttp://で通信される事と思われます。
つまり選択の余地無くhttp://しか使えないのです。送信ボタンクリック時にJavaScriptでactionの値を書き換えていると思われるため、http://へのリダイレクトを防ぐ目的でJavaScriptをオフにすると、送信先がログインフォームでなくなった上、パスワードがhttp://で通信経路を流れる事になります。受け取る側のページがただのWebページなので何も処理はしないのでしょうが、送信されてしまった以上、経路上で第三者に盗聴されるかもしれません。
この件について、前述の様な解説を簡略化したものを付け加え、こちらのアドレスとQ2への引用も付け加えサポートにメールしてみました。
まとめると以下の様な回答が来ました。
- パフォーマンスのためにトップはhttp://にしている
- 内部的には暗号化されている
- 暗号化を確認したければ HTTPヘッダーの解析ソフトなどを利用して欲しい
「内部的に」というのは、表示時のアドレスがhttp://だが、送信時のPOST先はhttps://になっているという意味だと思われます。
また、HTTPのヘッダ情報を見ろという指示はサポートセンターの受付から直接得られる回答ではないと思うので、多少なり技術部門の関係者に質問が届いたのであると思われます。
私の拙い説明を見て真摯に対応してくれた様子には感謝しますが、もし技術部門に質問が回った末の回答がこれだとしたら、こちらの意図した懸念が全く伝わっていないと思われます。
1通目のメールではログインフォーム以外にも、問い合わせフォームがそもそもセキュアな通信で送信されているのか？という2点の質問を一緒に送ってしまったため、2通目ではログインフォームの問題に主眼を置いて、表現を変えつつ再度質問をしました。
その際に、大手銀行のオンラインバンキングページではトップページにログインフォームを埋め込まず、「ログイン」と表示されたボタンはhttps://で表示可能なログインページへの遷移のみ行う、として幾つかの銀行サイトのURLも併記しました。
2通目の回答は、別途担当部署にて確認後回答をするのでしばらく待って欲しいとの事でした。気になったのは質問の案件名が「送信時の暗号化」と題されていた事です。懸念すべき点は「表示時」なのですが。
丁度ゴールデンウィークも挟んだので、回答を気長に待っていたのですが、1ヶ月経過しても返事が無いので催促の3通目を送りました。
そちらの回答をまとめると以下になります
- 問い合わせフォームの暗号化については検討中である
- 当該事由における情報漏洩は報告されていないが、セキュリティー強化をすべく、今後対応を進めていく所存
「ついては」という表現から、問い合わせフォーム以外にもログインフォームの件を把握しているとも読み取れますが、直接の言及の無さと2番目の回答の具体性の無さから、やはりログインフォームに関しては「何が問題なのか」が伝わっていない感じがします。
今のところWebページ上のログインは必ずしも必要ではないので利用を避けています。しかし最初のメールから1ヵ月半が経過した現在も、ログインフォームの仕様に変化がない状態です。もう少し様子を見て何もアクションが無いようでしたら、再度確認したうえで、最終的にサービスの利用を停止する(退会)という選択も考慮しなければならないのかと考えています。