ネットバンキングの決まり文句は「万全の対策を実施しています。ご安心下さい」。ところが，今年3月に多額の金が盗まれる“なりすまし”事件が起きた。編集部で調べた結果，同様なリスクを持つネットバンキングのサイトは少なくなかった。その状況を生み出しているのは「パスワード漏えいの死角」と「サイトなりすましの死角」であった。
 |
| 図1●ネットバンキングにおけるリスク回避のための3つの対応策 ネットバンキングには，ネットならではの危険が潜んでいる。銀行サイドがリスクを回避するために，取るべき対応が3つある |
国内の銀行144行のWebサイトを対象に，ネットバンキングのログイン画面の作りなどを調べた。その結果，なりすましの被害に遭うリスクは他の一部のネットバンキングにもあることが浮かび上がってきた（図1[拡大表示] ）。
なりすましのリスクを発生させている原因は一つではない。一般的に知られていない問題が，Webサイトの作り方にいくつか潜んでいる。大別すると「パスワード漏えい」と「サイトなりすまし」である。これらの“死角”はネットバンキングに限らず，一般のECサイトでも同様にある。
なりすまし対策は主に，ID/パスワードを使った認証システムの作り方にかかっている。対策が甘いとサイト側に落ち度があると判断され，民事的な責任が生じる可能性がある。免責を記載していても，不正に取引された金額を補償しなければならない。
ただ，ID/パスワードはサイト側だけでなく，顧客自身でも管理する。なりすましが発生する責任は，場合によって顧客にもある。サイト側としては，認証システムの強化だけでなく，どのようなリスクがあり得るかを顧客に明示しておく必要がある。
パスワード漏えいの死角
ネットバンキングのサイトを調べた結果，ログイン画面で要求される認証キーが，顧客番号などのログインIDとパスワードの組み合わせだけのケースが少なくとも50行以上ある。パスワードに4ケタの数字しか要求されない銀行もあった。これでは比較的容易に，パスワードが漏えいしてしまう（表1-A[拡大表示]）。
ネットバンキングのセキュリティに詳しい産業技術総合研究所 グリッド研究センター セキュアプログラミングチーム長 高木浩光氏は「認証チェックが，クラッカにとってパスワード検証機能になってしまう」と指摘する。やり方は簡単だ。ランダムな数字をID/パスワード欄に入力し続け，ログインできればそれが正規の値だと分かる（図2[拡大表示] ）。
|
|
通常は，入力を一定回数間違えるとロックがかかり，パスワードが無効になる。ところが，パスワードの方を固定してIDの値を変えていけば，ロックがかからず，何回でも試せる。実際，ある銀行のサイト構築担当者に確認したところ「IDの方を変えていけば，ロックはかからない」と言う。つまり，特定のIDに対するパスワードを盗む行為は防げても，不特定な正規のID/パスワードを盗む行為は防げない。
対策は，パスワードを複雑にするほかない。多重に要求する，ケタ数を上げる，文字列を英数混じりにする，といった方法が有効だ。同じIPアドレスから同じパスワードが連続して送信された場合に，そのリクエストをはじく方法も考えられる。ただ，それで精度が十分かどうかは分からない。
そこまでしても，キーロガーなどのキー入力記録ソフトをパソコンに仕掛けられると，漏えいを防げない。キー入力がそのままテキスト・ファイルに記録されるからだ。対抗手段は，乱数表を利用した簡易ワンタイム・パスワードを使い，1回ごとに異なる値を求めることである。国内のメガバンク5行6システムのうち，4システムが認証に乱数表を利用している。
コストや利便性との兼ね合いで，以上の対策が取れないなら，顧客にリスクを説明し，顧客の側で回避してもらうよう促すべきだろう。3月の事件以降，インターネットカフェからの利用を控えるよう記載しているサイトも増えている。
認証チェックに欠陥がある以上，サイト全体の運営もそれを想定しておく必要がある。特に「ログイン時の認証をいくら強力にしても，申込時の本人確認が甘いと危険だ」（高木氏）。例えば，口座番号と4ケタのパスワードがあれば，ネットバンキングへの申し込みと，そのログイン・パスワードを設定できるサイトも過去発見されている。顧客が，知らない間にネットバンキングを申し込まれ，操作されてしまう危険にさらされていた（表1-B[拡大表示]）。
編集部で確認した範囲では，この対策は施されてきている。例えば，最初にログインするための初期パスワードを銀行で採番した上で自宅に郵送すれば，本人確認の精度は格段に高まる。
サイトなりすましの死角
今回の調査でもう一つ目立ったのが，身元を隠すサイトの多さである。確認できただけでも，144行中32行がログイン画面のアドレス・バーを非表示にしており，うち18行が右クリックを禁止している（表1-C[拡大表示]）。こうしたサイトは，サイト自体をなりすまされるリスクがある。銀行のサイトに似た偽サイトを立ち上げられると，ID/パスワードを盗まれてしまう。
例えば「キャンペーン実施中！」などの偽メールを配信し，そこから偽サイトに顧客を導く。そうとは知らず顧客は偽サイトにID/パスワードを送信してしまう。送信後は「ただいまサービス停止中です」といった画面を表示したり，正規のサイトへ中継したりすれば，すぐに気付きにくい。アクセスを中継すれば，不正な資金移動までされてしまう可能性もある。
こうした偽サイトを銀行側が監視するのは，事実上不可能だ。対策としては，顧客がサイトの身元を確認できる環境を用意しておくことである。身元を証明する情報を普段から表示していないと，偽サイトにアクセスさせられても，顧客は分からない。
サイトの身元は，SSL証明書のサブジェクトやURLで確認できる。URLは，アドレス・バーまたは右クリックから開くプロパティ画面で確認できる。SSL証明書のサブジェクトは，ブラウザにもよるが，暗号化された画面で表示される鍵マークをクリックすれば確認できる。
中には，暗号化されたページをわざわざ暗号化されていないフレームで覆い隠している銀行もあった（表1-D[拡大表示]）。これでは，暗号化されていることを顧客は確認できない。右クリックしてHTMLのソースを見れば暗号化されたページに直接アクセスできるのだが，顧客にそこまでの操作を強要するのは間違いだろう。
さらに，システムをアウトソーシングしている銀行の場合，ログイン画面のURLやSSL証明書のサブジェクトがアウトソーシング先のものとなってしまい，銀行のページであることが確認しにくい（表1-E[拡大表示]）。そうしたケースも71行あった。振込先や金額といった重要な情報を送信するのだから，銀行以外のサイトにシステムを預けるなら，その旨を分かりやすく説明すべきだ。サイト上では，そうした説明は確認できなかった。
セッション管理にも注意
最後に，可能性は低いがセッションIDの奪取による，なりすましの危険性も示す。ログイン中にセッションIDを奪取され，すぐに不正アクセスされると，セッションを横取りされる。
セッションIDの管理によく使われているのは，CookieとHTMLフォームのhiddenフィールドである。Cookieは，クロスサイト・スクリプティングで漏えいすることが知られている。昨年大きく報道されたこともあり，その対策は進んだようだ。ただ，Cookieが漏えいするブラウザのバグが新たに報告されている。顧客がパッチを適用していなければ，リスクは残る。
セッションIDをHTMLフォームのhiddenフィールドに格納すれば，漏えいのリスクは格段に減る。しかし，この場合「戻る」ボタンを押すと画面にエラー表示が出るなど，制約がある。
制約を嫌ってCookieを使うなら，動作確認を表示するだけでなく，セキュリティ・ホールのないブラウザをサイト上で明示する，ブラウザへのパッチ適用を促す，など対処すべきだろう（表1-F[拡大表示]）。編集部でチェックした限りでは，Cookieを発行しているサイトでこうした注意書きは確認できなかった。
