終わらないパスワード議論と、広告に求められる誠実さと：セキュリティクラスターまとめのまとめ 2014年2月版

2014年2月は6桁のパスワードや人を騙す広告など、利用者側ではどうしようもないことに怒りが集中しました。

» 2014年03月11日 18時00分公開

[山本洋介山（bogus.jp），＠IT]

　情報セキュリティ月間ということもあって、セキュリティ系イベントが多数開催され、その様子が多数ツイートされたのを見て、うらやましく思うことが多かった2月です。

　そんな2月は、JALのWebサイトが不正アクセスを受け、マイルを奪われてしまった事件から始まります。原因は設定できるパスワードの短さにあるのではないかということもあり、パスワードの話題が好きなセキュリティクラスターの格好の餌食となります。そしてYahoo!の検索連動型広告がフィッシングサイトの広告を掲載するということも大きな話題となりました。

　技術系の話では、CSRF対策のトークンにセッションIDを使うのはどうなのかというトピックで盛り上がり、多数の意見が飛び交った2月のセキュリティクラスターでした。

JALへのパスワード攻撃と高木先生怒りの連続ツイート

　2月はJALのWebサイトが不正アクセスを受け、60人の被害者がマイルを奪われてしまったことから始まりました。このニュースに対し、たまっていた怒りをJALに向けぶつけたのが高木浩光先生（@HiromitsuTakagi）です。

　最近は業務の関係もあって、あまり積極的にツイートを行っていなかった高木先生も、久しぶりに怒りをあらわにして連続ツイートを行いました。それによると、氏は10年以上前からJALとANAのパスワードが6桁、4桁の数字にしか設定できないことを問題として捉えており、これまでその是正を勧告してきたものの、ほぼ受け入れられず現在に至ったということでした。

　そこで「リスト型攻撃に遭いにくい航空会社のアカウント」との皮肉に満ちた（他のサービスのパスワードにはこんな短くて単純なものを設定できませんからね）ブログを書こうとしていた矢先に、今回の事件が起こったということです。

　こんな短いパスワードであれば何度再設定しても攻撃に遭いやすいのは当たり前ということで、今回のケースは攻撃を受けた航空会社の方にも責任があるのではないかと考えているようです。

【関連リンク】

JALマイレージWebサイトへの不正アクセスに関する高木浩光先生のつぶやき

http://togetter.com/li/625093

　パスワードの定期変更の是非について議論となることが多かったセキュリティクラスターのタイムラインですが、十分な長さのパスワードを設定できないサイトは定期変更させる以前の問題ということで、高木先生が怒りの声を上げるのに納得するツイートが多かったです。

　それとともに、単純なものしか設定できない他のサービスをツイートしたり、他の航空会社のパスワードを調べたりしている人もいました。

Yahoo!が広告をろくに審査せずフィッシングサイトの広告を掲載してしまう

　2月19日に京都銀行の「個人向けインターネットバンキング」の取引画面を装ったフィッシングサイトへ誘導するような広告が、Yahoo!の検索連動型広告「スポンサードサーチ」により検索ページの上部に表示されていたことが分かり、問題となりました。Yahoo!検索を使い「京都銀行」と検索した結果、とても目立つところに京都銀行を名乗る偽広告が表示されるわけですから、ユーザーが騙されてクリックしてしまうのも無理もありません。

【関連リンク】

「Yahoo！JAPAN」の検索連動広告に京都銀行の偽サイト、不正送金を確認　ヤフーの審査すり抜ける

http://www.itmedia.co.jp/news/articles/1402/21/news134.html

　そこで広告掲載を行うヤフーが、どうしてユーザーを騙すような詐欺広告を掲載してしまったのかということが問題になりました。理由は簡単で、広告の内容をほとんど審査していなかったからだそうです。ワードに対して高い入札額を示せば誰でも広告を出稿できてしまったわけで、詐欺に利用するのも簡単だったのです。

　ヤフーに大きな責任があるのは明白だということで、セキュリティクラスターのタイムラインでは高木先生を筆頭にたくさんの人から非難の声が上がりました。

　京都新聞のサイトには大手銀行では必ず使用されている、ブラウザーのURL表示欄の色が変わることでおなじみの「EV SSL」が採用されていたのですが、京都銀行の場合は銀行名が出ないということだったので、より被害に遭いやすかったのではないかと指摘している人もいました。

　京都銀行へのフィッシング以外にも、ヤフーやbingの検索連動型広告が原因で、「hao123」というアドウェアが仕込まれるサイトへ誘導されるようになっていると指摘するツイートも多く見られました。

CSRF対策のトークンにセッションIDを使うのはどうなのか

　WebサイトのCSRF脆弱性の対策としてよく使われていることに、トークンを埋め込むというやり方があるのですが、その埋め込みトークンとしてセッションIDを使用することはダメなのではないかということについて盛り上がりました。セッションIDをそのまま使用するというやり方は情報処理推進機構（IPA）の「安全なウェブサイトの作り方」にも書かれているやり方で、採用している人も多いかもしれません。

　きっかけは@co3kさんの「CSRF 対策用トークンの値にセッション ID そのものを使ってもいい時代は終わりつつある」というブログエントリでした。このブログではCookie内のセッションIDはHttpOnly属性を付与することで盗まれにくくなっていることと、SSL 通信に対する BREACH attackでトークンにセッションIDを使っていた場合、セッションIDを推測されやすくなるので、リスクを減らすためにもセッションIDそのものは使わない方がいいという主張です。

　それに呼応するかのように@bulkneets氏も「CSRF対策用トークンの値にセッションIDそのものを使ってもいい時代なんて、そもそも無かった」というブログを書きます。最初からセッションIDをトークンに使用することは間違いだったということです。

　これらを踏まえて多くの意見が出ますが、だいたいの人はセッションIDそのものを使うのはもう止めた方がいい、もともとすべきではなかったという意見でした。トークンにセッションIDそのものを使用するということに感覚的な気持ち悪さを感じていた人もいたようですので、これからはセッションIDそのものではなくセッションIDのハッシュなどが使われるようになる流れのようです。

　そして、HTMLの一部分だけを盗むことが可能なバグについて言及している人もいました。埋め込まれたトークンが盗まれることで、セッションハイジャックされるという内容です。

　するとCSRF対策のトークンにセッションIDを使用することを推進していた@HiromitsuTakagi氏からは、セッションID以外の乱数を公的な標準として定めるには、誤りのない理由が必要との反論がありましたが、肝心の使用することのリスクについては触れずじまいでした。

　この他にも2月のセキュリティクラスターはこのような話題で盛り上がっていました。3月はどのようなことが起きるのでしょうね。