NHKのスマホセキュリティ対策と今のWebアプリセキュリティ対策は基本構造が同じ

NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。

ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。

• Androidの設定から「提供元不明のアプリ」のチェックボックスをオンにしてはならない、必ずオフにする、の説明が無かった。
• セキュリティベンダー広報担当者の説明を長々と回りく引用し説明に終始し、インストールしないことが大事であるのに、インストールしてしまった場合の症状や攻撃手法を羅列した。
• 「見覚えのないアプリは速やかに削除すること。そして、自分がどんなアカウントを利用していたかを確認し、パスワードを変更したり、企業に相談したりするなどしてほしい」などど、そもそもインストールしない、怪しいアプリをインストールできないようにする、の説明がなかった。

要するに著者は、最も根源的かつ基本的なセキュリティ対策である「検証もされていないダメなアプリを入れてはダメ」が抜けた上で、

▽セキュリティー対策ソフトを入れる。

などといった”遅すぎる事後対策”かつ”ベンダーの商売に利する対策”を啓蒙したことが問題である、との認識だと思います。

NHKが紹介した対策ページではスクリーンショット等も交えながら

▽アプリは公式アプリストアからのみダウンロードする。

としているのに、「提供元不明のアプリ」（Android 8ではアプリごとの「不明なアプリ」）のチェックボックスをオフにする、を説明しないのは何事だ！という事です。

確かにその通りだと思います。「提供元不明のアプリ」のチェックボックスは必ずオフにする、は一般スマホユーザーが何がなくてもいの一番にすべきセキュリティ対策でしょう。実際に「提供元不明のアプリ」インストールが原因で攻撃が多数成功しているのですから。

このスマホセキュリティ対策と同じようなことがソフトウェアセキュリティ対策で当たり前に行われている、と感じていました。手元の「危険なアプリの構造、安全なアプリの構造」（公開していません）の導入部分に追加したスライドを紹介します。

NHKのスマホセキュリティ対策が問題に

既に書いた内容の通りです。（画像クリックで拡大）

そもそも検証されていないアプリをスマホにインストールすべきではありません。ITエンジニアの方なら誰でも実践していると思います。

実際、問題のNHKページを見てみましたが「そもそも入れない」の記述がありません。SNSでも流石にこれは不味い説明だとする意見しか見かけませんでした。

同じ構造のセキュリティ対策がWebセキュリティでも

同じ構造のセキュリティ対策がWebセキュリティ対策でも見かけます。「アプリ」を「データ」に置き換えるだけでです。Webアプリセキュリティの方が若干構造が複雑ですが、基本的な構造は同じです。

そもそも何の検証もしていないデータをWebアプリで処理すべきではありません。コンピュータプログラムは妥当な入力でしか正しく動作できず、HTTPプロトコルは汎用プロトコルで基本何でも送信できるからです。しかし、ほとんどのWebアプリが何の検証もないまま、Webアプリにデータを処理させているの現状です。データ検証がない為に不必要に攻撃可能な状態になってしまったWebアプリは数え切れません。運用するWebアプリは攻撃実験用でも、セキュリティ研究家の研究対象でもありません。

参考：

NHKのスマホ対策の説明と同じく、攻撃用データを入れてしまったらどうなるか？といった説明、セキュリティ対策として「入ってしまった攻撃用データ」でいかに攻撃をできないようにするのか？といった事後対策の説明、これらをWebアプリセキュリティ対策としてよく耳にします。NHKのスマホセキュリティ対策指南と変わりがありません。

「入ってしまった攻撃用データ」は多くの場合が「出鱈目なデータ」です。コンピュータは出鱈目なデータでは正しく動作できません。出鱈目な結果を出しても、出鱈目なデータを保存しても、出鱈目は出鱈目です。

データ出力時に「出鱈目なデータが無害（インジェクション攻撃できない）であること」を保証しても、エラーになったり、出鱈目なデータを処理することになります。

出鱈目なデータに対する出力対策は「フェイルセーフ対策」であり、本来は動作してはならない対策です。出力処理に入る前に出鱈目なデータは全て廃除されていなければなりません。これは「そもそもダメなデータは入れない」入力データ処理から始まります。

参考：NHKのセキュリティ対策と同じようようなWebアプリセキュリティの解説

• 安全なPHPアプリケーションの作り方2016

このスライドだと「そもそもダメなモノを入れない」が無視どころか、有害であるとさえ勘違いしそうです。2017年の講演では「ロジックでの入力バリデーション」を入れた分、改善されています。それでも全く基本が無視した説明になっています。

攻撃者とセキュリティ業者が喜ぶ対策であることも同じ

攻撃用アプリをインストールできるようにしているスマホは、攻撃者とセキュリティ業者にとっては好都合です。両者ともビジネスになります。セキュリティ業者はアンチウイルスソフトがより売れるようになります。

攻撃用データが入り放題になっているWebアプリも、攻撃者とセキュリティ業者にとっても好都合です。両者ともビジネスになります。セキュリティ業者はWebアプリケーションファイアーウォール（WAF）が売れるようになります。更にアプリケーション内部に隠れてている数えきれない程ある脆弱性を外部からのWeb脆弱性検査で発見しやすくなります。（理由は後述の組み合わせ爆発を参照）

両方共、そもそも入れなければ発生しない問題、が大半を占めます。

ダメなスマホセキュリティ対策とダメなWebアプリセキュリティ対策

スマホもWebアプリも、そもそも攻撃アプリ／データを入れなければ問題の大半に対応でき、より安全に利用できます。

ダメなモノを入れてから、では遅すぎるのです。

ダメなモノはそもそも入れない。これはスマホセキュリティでも最も重要かつ基本的な対策です。Webアプリでも全く同じです。

攻撃用アプリを入れてしまったことによって発生する問題は数えきれません。完全でなくても（アプリストアの検証も完璧ではない）、少なくとも検証済みのアプリだけに限定すると大幅にリスクが低下します。

攻撃用データを入れてしまったことによって発生する問題も同じように数えきれません。バリデーションにより妥当なデータだけに限定すると大幅にリスクが低下します。

出鱈目な攻撃用データを入れる問題 ｰ 組み合わせ爆発

攻撃用アプリと攻撃用データでは話が違うのでは？と思うかも知れません。しかし、攻撃用アプリを入れてしまって発生する数えきれない問題と同じく、アプリが想定しない攻撃用データはプログラムに数えきれない程の問題を発生させる場合があります。

コンピュータプログラムが正しく動作する（＝脆弱性なく動作する）ことを証明する技術に「形式的検証」があります。数学的にアルゴリズムの正しさを検証する方法と総当たりでプログラムが正しく動作することを検証する2つ方法があります。

数学的にアルゴリズムの正しさを検証する方法は計算量は少ないのですが、適用するのが困難です。副作用がある場合、数学的検証はほぼ無理です。この場合、総当たりでプログラムが正しく動作することを検証することになります。

検証するプログラムが単純なら総当たりでも大して問題にはなりません。コンピューターで十分に計算可能です。

しかし、実用的なアプリケーションプログラムが正しく動作すること保証するには、アプリケーションプログラマーが書いたコード以外に

• アプリ言語のフレームワークのコード（PHP、Ruby、Pythonなど）
• アプリ言語のライブラリのコード（PHP、Ruby、Pythonなど）
• アプリ言語自体のコード（CやC＋＋）
• アプリ言語以外のライブラリのコード（CやC＋＋）
• アプリが利用する外部システムのプログラムコード
• アプリが利用する外部システムやそれが利用するフレームワークやライブラリのコード全て

など全てコードが検証対象になります。

どんなに出鱈目なデータを渡しても、プログラムがプログラマの意図通りに動作することを証明するには、膨大な量の計算（試行）が必要です。

実用的なアプリでなくても、単純に2つの64bit整数の足し算が正しく実行されることを総当たり方式で検証するには、2^64*2^64回の計算が必要です。単純な整数でさえ膨大な計算量です。

テキストデータなら、計算するまでもなく、「総当たり方式」での検証は不可能である、と解ります。

組み合わせは指数的に増えます。これにより組み合わせ爆発が発生し、妥当なデータのみであっても、容易にコンピューターでさえ正しく動作することを証明不可能な計算量になります。

参考：

備考： セキュリティの要素

「（特定の）攻撃を出来ないようにするのがセキュリティ対策」と勘違いしている方も少くありません。ISO 27000では機密性、完全性、可用性、信頼性、真正性、否認防止、がセキュリティ対策の要素と定義されています。GDPRという恐ろしい法律もある今、ISO 27000と整合性がない勝手なセキュリティ定義／概念では危険すぎます。

まとめ

出鱈目なデータをプログラムに与えても、望まない結果とならないことを保証するのは不可能です。

妥当なデータをプログラムに与えた場合だけに限っても、プログラムが望む動作となることを保証することさえ非常に困難です。

スマホに攻撃用アプリを入れると何が起きてもおかしくない。これと同じく、Webアプリに攻撃用の出鱈目なデータを入れると何が起きてもおかしくありません。

攻撃者が、アプリのコードではなく、Cライブラリのバッファーオーバーフロー問題を利用してアプリに攻撃をしかけることはよくある攻撃です。

ここで紹介したような原理と論理があるので、コンピューターサイエンティストのセキュリティ専門家は口を揃えて、セキュリティ対策として

• まず全ての入力データをバリデーションしなさい

と言っています。¹

アプリケーションの入力処理で、入力データバリデーションを行わないのは構造的な欠陥ですが、残念ながら今のWebアプリのほとんどがこの欠陥を持っています。

IPAでさえ出鱈目な入力対策を長年（10年以上？）啓蒙してきたので、一般開発者が誤解してしまうのは無理もないでしょう。（セキュリティ専門家は除く。基本くらいは知っていて当たり前）

まずダメなモノは入れない

これはどんなセキュリティ対策にでも共通する当たり前にすべき対策です。

ダメなモノはブラックリスト型で対策しません。データなら以下のようになります。

ネットワークシステムに例えるなら、インターネットと接続するルーターでのファイアーウォール機能をザル状態にして、内部の個々のネットワークデバイスでセキュリティを維持する、などいう構造のセキュリティ対策はあり得ません。ソフトウェア、特にWebアプリでは残念ながら、この構造が当たり前になっています。

最後にコンピューターサイエンティストが推奨しているセキュアなアプリケーションアーキテクチャーを図にすると以下の様な、多層防御、を実装した構造になります。

参考：

セキュアコーディングでないもの、はセキュアコーディングではないです。現在のWebアプリが脆弱な構造であるのは、セキュアコーディング概念の誤解、が大きな原因だと思われます。