さらに、一部の機種では、setRequestHeaderメソッドによりHostフィールドを書き換え可能なものがあり、この場合は、従来推奨していた「Hostフィールドのチェック」によるアプリケーション側での対策がとれないことがわかった。

この部分ですか。
これでは防ぎようがないですね。

ガラケーでは通信を行うと自動でユーザーＩＤが添付されますから、
攻撃者の勝手サイトに設置したJavaScriptからなんとかして公式サイトにアクセスさせるだけで、
アクセスした公式サイトへのログインが完了してしまいます。
で、その結果を攻撃者のサイトに転送するなり何なりすれば個人情報げっちゅ。ウハウハ。
で、その「なんとかして別サーバーにアクセスさせる」ために「DNSリバインディング」を使うことができる。
ここまでドコモと一緒。

で、ドコモの場合は、ヘッダのHOSTを書き換えることができないので、そこをチェックすればサーバー側で止められたのですが、
ソフトバンクの場合には、ヘッダのHOSTすらもJavaScript側で書き換え可能なので、サーバー側で判定することはできないらしい。
対策は端末でスクリプトをOFF。

通信するだけでログイン完了ってのは実に恐ろしいですね・・・。

> そんなことをせずとも、きちんとバーチャルホストの設定をして、
バーチャルホストの設定は「かんたんログイン」とやらの設計そのものの根本的な欠陥を回避するためにやむなく行うことで、設定していないからと言って「きちんと」していないのではない。
「かんたんログイン」などさっさと捨ててしまうことこそ「きちんと」した対応。
> 予期しているホスト名を使用してのアクセス以外を弾いてしまえば、DNS Rebindingの影響は受けないのでは？
そもそもDNS Rebindingの影響を受けないとしても安全性など保証されていないけど、それ以前に今回のソフトバンクの件ではsetRequestHeaderでHostを書き換え可能な機種が存在するので明らかに安全ではない。せめてリンク先のアドバイザリくらい読んでから物言ったら?
> そうすれば機能的に損なう物もないですし。
別に端末IDがないと機能を維持できないわけではない。

誤解を招く可能性がある書き方だったので補足。
ソフトバンクのケータイでも無線LANを使うには別料金いります。