<前の日記(2004年09月06日) 次の日記(2004年09月12日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 1223   昨日: 2328

2004年09月11日

エンドユーザにできるフィッシング対策

フィッシング詐欺の被害に遭わないため、エンドユーザが本来習得しておくべきWebの基礎リテラシーは、次の行動をとることである。

  • 重要な情報を入力する直前に
    • アドレスバーに表示されているURLのドメイン名が、自分が記憶している本物サイトのドメイン名に一致しているかを確認する。
    • SSLによる暗号通信がサポートされているサイトならば、ステータスバーにある錠アイコンをクリックしてサーバ証明書を表示し、本物サイトの運営者の英文組織名が書かれていることを確認する。
  • サイトを訪れる前に
    • いかなるメールであっても(本物サイトが発行するメールマガジンやニュースリリースに見えるメールであっても)そこに記載されたURLを信用せず、ジャンプしない。
    • 本物だと知っているURLをアドレスバーに手入力してアクセスし、ブックマークに登録し、それ以降はブックマークで当該サイトを訪れるようにする。
  • 普段から
    • アドレスバーや鍵アイコンの偽装ができてしまう(偽サイトなのに本物サイトの情報を偽って表示できてしまう)ブラウザの欠陥の存在が発覚することもあるので、セキュリティ脆弱性の修正プログラム(パッチ)は常に適用するようにしておく。

しかし、ドメイン名が一致しているかを目で確認するというのは、神経が疲れるし、そっくりの偽ドメインに気付かないかもしれない。サーバ証明書に記載された組織名を確認するのも、面倒だし、英文しか使えない現状では、組織名の英文正式名称を覚えていられるかという問題がある。

また、常にメールを信用しない、常にブックマークを使うというのも現実的でない場合がある。(常にトップページから入らなければならないサイトが不便であるのと同様に。)

そこで次の方法を考えた。

  1. 今見ている画面が本物だと確認できている状態で、そのドメインでのみ有効なcookieを自分のブラウザに手作業でセットする。具体的には以下のURLをアドレスバーに入力してエンターキーを押す。
    javascript:document.cookie="mycookie="+escape("本日は晴天なり")+"; path=/; expires=Thu, 1-Jan-2030 00:00:00 GMT";
    「本日は晴天なり」の部分は、パッと見で自分だけが書きそうだとわかるユニークな文章(ただし他人に知られてもかまわないもの)とする。

  2. 次回以降、そのサイトに訪れたときにそこが本物かどうか確認するには、以下のURLをアドレスバーに入力してエンターキーを押す。
    javascript:unescape(document.cookie);
    「本日は晴天なり」という文字列を含むものが画面に表示されれば、以前自分が上の1.の操作をしたサイトとドメインが一致していることを機械的に確認できる。

これらの操作を簡単にするため、2つのそれぞれのJavaScript文をブックマークに登録する(いわゆる「Bookmarklet」とする)とよい。具体的には、実行した直後にブックマークの操作をすればよい。

上記1.のスクリプトを「オレオレCookie登録」、2.のスクリプトを「Cookie表示」とし、さらに「Cookie削除」の機能([memo:4027]参照)もBookmarklet化し、リンクバーにボタンとして置いた様子を以下の図に示す。

ただしこの方法には以下の使用上の注意点がある。

  • 登録した文字列は、当該サイトのサーバに対して常に送信されることになるので、サイト管理者に知られてもかまわない文字列とする必要がある。
  • 登録した文字列がユニークであると、サイト管理者は、送信されてくるcookieを調べることで、複数のアクセスが同じ人からのものであると知ることができてしまうため、追跡されてもかまわないと信用できるサイトに対してしか使えない。
  • 「mycookie」の部分の名前は何でもよいが、サイト側が発行してくるcookieに同名のものがあると上書きされてしまうことがあるので、ぶつかり難い名前とするのがよい。
  • Netscape 7では文字化けすることがあるため、英文で登録する必要がある。
  • ブラウザにcookieが漏洩する欠陥がある場合には、登録した文字列を第三者に閲覧される可能性があり、閲覧されると、それを偽サイト上でセットされる恐れが生ずるので、セキュリティ脆弱性の修正プログラム(パッチ)は、いずれにせよ常に適用しておく必要がある。
  • サイトにクロスサイトスクリプティング脆弱性がある場合には、登録した文字列を第三者に閲覧される可能性があるため、そのような脆弱性がないだろうと信頼できるサイトに対してしか使えない。

この方法は、「cookieは本物サイトと同じドメインにしか送信されない」という原理に基づくものである。これと同じ原理に基づく仕組みをサーバ側で用意することもできるが、それは効果が薄い。その理由は次の通りである。

サーバ側で用意する場合には、キーワードをユーザに入力させる画面を設けることになる。つまり、ログインする前ないし後に、「キーワードを入力してください」という画面が現れ、入力してボタンを押すと、cookieが発行されるという仕組みとなる。

しかし、本物サイトがそのような作りになっているときには、フィッシングでユーザを騙そうとしている詐欺師は、キーワードを入力させる画面自体を偽サイトに設置するだろう。

このことは、ソニー銀行の「事前登録のパソコンでしか取引できない」という仕組みが、フィッシング詐欺対策としては効果が薄いのと同じである。それについては、昨年5月12日の日記「事前登録のパソコンでしか取引できないという対策」に以下のように書いたが、それと同じ理屈である。

これをネットカフェで実行したとき、キーロガーが仕掛けられているとどうなるか。当然ながら、最初のパスワードと、次の暗証番号と、3つの合言葉は、全部そろって盗まれる。つまり、ネットカフェでキーロガーを仕掛けられて銀行口座を乗っ取られたという事件報道の文脈において、

3種類の「合言葉」を答えないと利用できない仕組み。さらに事前登録のパソコンでしか取引できないという対策も講じている。

というのは、何ら効果のある対策ではない。

つまり、自力でcookieをセットするという今回示した対策方法が効果を持つのは、サイトの指示に従ってではなく、自発的に操作するところにミソがある。

したがって、この対策方法は、元々偽サイトに対する警戒心のあるユーザが対象であり、ドメイン名の一致確認を目視でやってもいいところを、もっと簡単にパッと見でできるようにしたという仕掛けにすぎない。

銀行の深夜営業ATMの入り口ドアにあるカード読取機に注意

  • カード情報盗み預金窃取か ATM脇に読み取り装置, 産経新聞, 2004年9月6日

    調べでは、半田市内の30代の主婦が8月上旬、このATM脇に「防犯上、ご利用のお客さまはカードをお通し下さい」と張り紙のある小さな箱状の磁気情報読み取り装置にカードを通した。同月下旬になって、別のATMから預金計約1000万円が引き出されていることが判明したが、(略)

というニュース記事を読んだ。「フィッシング詐欺のリアル版」……という言い方は変か。昔からあった手口なのかもしれない*1

そういえば、以前、早朝まで都内で飲んでいた帰りに、現金を確保しようと深夜営業のATMに入ろうとしたとき、ドアが開かず「どうなってんの?」と知人に聞いたところ、ドアにカードリーダがあるからそこにキャッシュカードを通すのだと指摘されたことがあった。

そのとき、直感的に嫌なものを感じつつ、カードを通したのだったが、今思えば、それが偽リーダだったらヤラれていたわけだ。

そんなことを思い出していたところ、UFJ銀行からこういう注意喚起の知らせが出ていた。

平成16年8月、ATMコーナーに「防犯のため、この機械にカードを通してください」と記載した貼り紙と共に「カード読取機」が、何者かによって設置されるという事件が発生いたしました。

当行では、深夜0時以降も稼動するATMコーナーに限り、カード読取機を設置しておりますが、他のATMコーナーには設置しておりません。これ以外の不審な機械には、決してキャッシュカードを通さないでください。

おいおい、じゃあ、深夜営業するATMコーナーではどうしろというのだ?

「どうやって本物だと見分けるか」を写真付きで説明するのが、ここでなすべきことだろう。どうしてこう、どいつもこいつも銀行の人たちはそういうことをサボるのか。

ようするに、「お客様の安全のために注意喚起している」のではなく、単に一定の説明責任を果たしさえすれば免責されるという発想で仕事をしている様子が透けて見えてくる。

ところで、ATMのドアがキャッシュカードがないと開かないようにする仕組み自体、効果があるのか疑問に思った。最初は、UFJ銀行のキャッシュカードでないと開かないのかと思ったが、他の都市銀行のカードで開いた。それだったら、銀行のカードを持たない人の侵入を防ぐという程度の効果しかない。

キャッシュカードは本来、ATMにしか通さない「神聖なもの」(安易に得体の知れないカードリーダに通さないもの)という常識があったが、こうしたドアの登場により、そうした感覚が崩れていってしまうのだろう。その結果、事件被害者の主婦のように、「防犯上、お通し下さい」と書かれているだけで通してしまうことが起きてくる。

あのようなドアは廃止すべきではなかろうか。

デジタルコアの合宿討論会に行ってきた

先週、日経デジタルコアの合宿討論会に行ってきた。その様子が以下にレポートされている。

この場で、ビットワレットの川合成幸社長にご挨拶し、少しお話しするお時間を頂いた。7月10日の日記の最後の段落に書いたam/pmの問題点の件を(概略だけであるが)川合社長にお伝えした。私からもam/pmに問い合わせてみるとも伝えた。

おサイフケータイのシリアル番号?

コロラド大学の木實新一さんが、ご自身のblog「Ubicomp+Shopping」の9月3日のエントリで、以下の疑問を呈されていた。

非常に基本的なことなのですが、以下の点がよくわかりません:

  • 電子マネーの端末はRFIDチップのRAMの値の読み書きだけでなくシリアル番号も読んでいるのか?
  • おサイフケータイのタグを利用者が好きなときに取り替えることができるのか?
  • おサイフケータイのタグのシリアル番号は利用者の個人情報とネットワーク上のデータベースで関連づけられているのか?

シリアル番号には複数のものがあるらしい。1つにはカード製造者が製造時に記録したもので、カードの「管理権限」があるときにしか読めないようになっていると聞いたことがある。もうひとつは、アンチコリジョンを実現するためのユニークナンバーを持つカードがあり、これは、通常のリーダライターでも読まれているはずである。ただし、読み取った番号を記録しているかどうかは不明である。

トラブル時の対応目的で記録している可能性はあるが、それをCRMにまで活用しようということは、日本の普通の企業ならば、一般的には、そのような行為は非常識であるとして行わないところがほとんどだろうと、個人的には信じている。

問題は、何らかの拍子にそうした番号をCRMに使ってよいという感覚が生じて、なし崩し的にそのようになっていくことであり、それは食い止めるべきである。また、悪意ある者(詐欺師等)が番号を読み取って悪用することが懸念される。

am/pmの件については、問い合わせて回答が得られしだい、報告する予定。

*1 「ニセ夜間金庫」(昭和49年警察白書 第4章より)なる事件は昔あったそうだが、直接現金を入れさせるのではなく、IDとパスワードを騙して入れさせるという点がフィッシングに近い。

検索

<前の日記(2004年09月06日) 次の日記(2004年09月12日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2004年09月06日) 次の日記(2004年09月12日)> 最新 編集