アプリに暗号鍵をハードコーディング
Androidアプリの40%が欠陥品!? 原因は安易な開発姿勢
米企業がモバイルアプリを分析調査したところ、Androidアプリの40%から「深刻な問題を引き起こしかねない」問題が見つかった。解決にはアプリ開発者の意識改革が必要だ。
Android搭載端末向けのアプリケーション(アプリ)を開発しているモバイル開発者は、企業の開発者と同じ過ちを多数犯している。そしてそのコードの出来の悪さにより、暗号などのセキュリティ機能の効果を帳消しにしているかもしれない──。そんな実態が最新の調査で明らかになった。こうした欠陥のあるアプリがAndroidの脆弱性と組み合わさると、攻撃者にとって格好の標的になりかねないことも分かった。
セキュリティ診断を手掛ける米Veracodeがモバイルアプリの分析調査を実施した結果、Androidアプリの40%に少なくとも1件のハードコーディングされた暗号鍵が見つかった。同社共同創業者のクリス・ワイソパルCTO(最高技術責任者)によると、アプリの全ユーザーに同じ暗号鍵を付与するこの行為は、組織内の全員が自分のデータを保護するために同じパスワードを使っているのに等しい。Androidアプリは簡単に逆コンパイルできるため、攻撃者がハードコーディングされた暗号鍵を取り出して公開することも簡単にできてしまうという。
「Android搭載端末を紛失した場合、攻撃者がアプリにアクセスできてしまい、その組織の全員がアクセスできる全データにアクセスされる恐れがある」とワイソパル氏は解説する。
Veracodeが調べたのは、主に金融機関や医療関連企業の従業員が使う企業向けのAndroidアプリだった。ワイソパル氏によれば、開発者はアプリ開発を容易にする目的で暗号鍵をハードコーディングしているという。
ワイソパル氏はこう続ける。「開発者は、モバイルアプリ開発に移行する際に認証システムを開発し直すことを好まない」
暗号鍵のハードコーディングは、サーバサイドで実行するWebアプリでは一般的だ。この場合、サーバはバックエンドのデータソースに対して認証を行う。Webサーバにアクセスできるのはそのサーバの管理者のみであり、攻撃者に暗号鍵を取得されるリスクは極めて低い。これに対し、「モバイルでは誰もがその中にある鍵を使ってソフトウェアにアクセスできる」とワイソパル氏は指摘する。
同氏によると、モバイルアプリ開発のためのツールやフレームワークは成熟度が低く、モバイルアプリにはコーディングエラーが多い。モバイルアプリを専門に手掛ける企業は大量の仕事を請け負っている。というのも、ほとんどの組織の開発チームはJ2EE、Java、.NET Webアプリ開発のスキルは高くても、モバイルアプリのスキルは高くないからだ。モバイルアプリは組織外で、しかもずっと速いペースで開発されていると同氏は言う。
「われわれの顧客の中にはモバイルアプリを2週間で開発したというところもある。この種の開発作業においてセキュリティがおろそかにされている実態がここからうかがえる」(ワイソパル氏)
同氏は、モバイルプラットフォームのリスクとそれがどう攻撃されるかについて、組織はようやく理解し始めたところだと語った。Webアプリの場合、大きな問題となる脆弱性が理解されるまでに約5年を要した。SQLインジェクションとクロスサイトスクリプティングの脆弱性は今もWebアプリを脅かし続けている。
「こうした攻撃がモバイルにおいてどのように発生し、どうしたらそれを防げるのかについて理解するまでには数年かかるだろう。ただし、どのような攻撃に遭うかは分からなくても、モバイルアプリ開発において慎重を期すことはできる」とワイソパル氏。
Veracodeによると、暗号鍵のハードコーディング以外にモバイル端末に問題を引き起こすコーディングエラーとして、重要情報の漏えいや危険なデータ保存、危険なデータ転送などが挙げられる。また、機能面でも問題を誘発しかねない。例えばコードの出来が悪いアプリは攻撃者に改ざんされ、行動の監視や無許可のメッセージ送信などに利用される恐れがある。
プラットフォームに組み込まれたセキュリティ機能(コード署名、サンドボックス、パーミッション通知)は、ソフトウェア開発者がうまく使えばセキュリティの大幅な強化につながるとワイソパル氏は言う。コード署名ではアプリが正規の開発元のものであることをユーザーが確認でき、サンドボックスはアプリを重要なプロセスから隔離する。パーミッション通知では、アプリが位置情報やメッセージングなどのデータソースにアクセスしようとするとユーザーに警告を出す。
いずれのセキュリティ機能にも弱点はあるものの、手始めにはなる。ワイソパル氏は「こうしたものの多くは概念としては優れている。だが優れた強制の枠組みがないため実地ではうまくいっていない」と話している。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
新着ホワイトペーパー PR
-
技術文書・技術解説
[Jamf Japan 合同会社] MDMだけでモバイルセキュリティは十分? 不足する対策を16項目でチェック -
事例
[Wrike Japan 株式会社] 世界的な家電メーカーが実践する「クリエイティブプロセス効率化」の方法とは? -
事例
[Wrike Japan 株式会社] 世界的テクノロジー企業に学ぶ、プロセス標準化とプロジェクト納品自動化の秘訣 -
事例
[Wrike Japan 株式会社] ソニー・ピクチャーズ テレビジョンに学ぶ、次世代サービスデリバリーのヒント -
事例
[Wrike Japan 株式会社] ソミック石川に学ぶ、ICT浸透後に直面した「工数管理」の課題と解決策
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Copilot」はなぜ放置される? “議事録要約止まり”を脱する処方箋
-
2
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
3
「データストレージの活用方法」に関するアンケート
-
4
【基本情報技術者試験】「デュプレックスシステム」と「デュアルシステム」の違いは?
-
5
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4%
-
6
「Microsoft一択」で本当にいいのか 知らぬ間にライセンス費用が膨らむ真相
-
7
Oracle巨大ITプロジェクトはなぜつまずいたのか 8年で導入1割、追加で170億ドル
-
8
「プログラマー不要論」にThe Linux Foundationが示した答え
-
9
ANAが専用回線から移行した「NaaS」の全貌 ネットワーク準備が数カ月から数週間に
-
10
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
ホワイトペーパーランキング PR
-
1
マンガで解説:「ゼロトラスト」「SASE」の必要性とメリット
-
2
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
3
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
4
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
5
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
6
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは?
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
ドラマで分かる、標的型攻撃メールの被害を受ける企業と回避できる企業の分岐点
-
9
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
10
少額減価償却資産が40万円未満へ拡大、令和8年度税制改正で押さえるべき変更点
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー