スマートフォンで「できちゃうこと」って？：イチから始める！ Androidセキュリティ（1）（2/3 ページ）

[杉山俊春, Illustrated by はるぷ，株式会社ユービーセキュア]

HTTPSでカバーできるところとできないところ

クウ　「え。いままで携帯ってそんなことできたっけ？？？」

ユウヤ　「これスマートフォンだろ？ いままでと同じで考えたらいかんよ」

クウ　「いまはそんなんができるんね……。ただ単に便利になっただけかと思ったけど、『違うもの』って思わないとダメなのか……」

ユウヤ　「まあ、単純に便利になるだけってこともあるけど、便利になった分、考えなきゃいけないことは何かをちゃんと抑えておくべきだろ」

クウ　「でも、そしたらどうすればいいんだ……？ あ、HTTPSを使えばいいのか♪」

ユウヤ　「じゃあ、HTTPS使ってるサイトのパスワードものぞいてあげようか？」

クウ　「え？？ できるの？？ やめてー」

　通信内容の閲覧や改ざんへの対策を考える場合、HTTPSに代表される通信の暗号化が挙げられることが多い。ただし、どういったケースで有効な手法なのかを考えた上で対策を行うことが必要となる。

　例えば、正規のユーザーが端末を利用しているとき、第三者である攻撃者がその通信を盗聴するケースを想定しよう。このときHTTPSを利用すれば、不正な証明書が利用されていることをユーザーに対し通知可能となるため、対策として有効だといえる。

　しかし、端末を紛失した場合など、攻撃者が端末を利用できる状態の場合はどうだろうか。汎用的なWebブラウザのように、HTTPS接続時の証明書が不正であっても警告を無視して通信をさせることができれば、通信内容の閲覧自体は可能となってしまう。

図4　証明書に不正があるとブラウザに警告画面が表示される

　また、このように攻撃時には証明書が不正な状態となる場合を想定して、アプリケーション側で、正規の証明書ではない場合には通信できないような作りにした場合はどうだろうか。この場合も、攻撃者がAndroid端末上に独自の証明書をインストールできてしまえば、アプリケーションに対し、正規の証明書を利用しているように見せかけることができてしまう（注1）。

【注1】
端末への証明書インストールにはroot権限が必要だ。しかし、Android端末でのroot取得手法は広く知られている。従って、ある程度、root権限が取得されていることを前提に対策を考えることが望ましい。ただし、管理権限を取得可能な状態にすることが利用規約などに反する場合もあるため、注意が必要だ。

　上記では、HTTPリクエストを傍受・書き換える例を示したが、これは、HTTP通信に限った話ではない。Socketクラスなどを用いた独自プロトコルによる通信においても同様に、閲覧・改ざんは可能だ。このため、通信全般で同様の危険性を考慮しておく必要がある。

　最近では、攻撃者に端末自体を奪われた場合を想定し、端末にロックを掛けることが推奨されている。だがこの場合でも、タッチパネル方式を採用しているため、指の跡などを基に、パスワードを容易に判別できてしまうことも報告されており（研究者がスクリーンの汚れを利用した攻撃で、Androidの暗証番号を68％解読 - CNET Japan）、アプリケーション側での対策を考慮すべきであるともいえる。

図5　ディスプレイに残った指の跡を基に、高い確率でパスワードの判別が可能という

　このように、従来の携帯端末とは異なり、スマートフォンを対象にすると、通信内容が閲覧されてしまう可能性があることを想定してWebアプリケーションを設計することが必要になる。

　まず可能であれば、パスワードなどの重要な情報はローカルに保存しないようにすることが望ましい。しかしそうすると、利便性が損なわれるのも事実だ。ローカルに重要な情報を保存せざるを得ない場合は、個別にパスワードだけ暗号化したり、チャレンジレスポンス方式を採用するなど、パスワードが通信路にそのまま流れないように工夫したほうがよいだろう。逆コンパイルなどを想定すると、保存されたパスワードを直接解析されてしまい、暗号化しても対処できない可能性があるため、いっそうの注意が必要となる。

図6　端末、通信経路、サーバのそれぞれにおいて被害を想定した上で対策を取ることが重要

　今後は、PC向けサイトをAndroid端末のブラウザなどで閲覧する場合も増えるだろう。しかし、端末を紛失することを想定してID／パスワードを扱うようにしているサイトは非常に少ない。パスワード保存機能を利用する際には、ユーザー側がその危険性を認識して利用することが必要だ。