入力バリデーションに「エスケープやフィルタリングが含まれる」とする驚くべき解説
標準的な入力バリデーションに「エスケープやフィルタリングが含まれる」とする驚くべき解説があります。そのような入力バリデーションを定義した標準的なセキュリティガイドライン／規格は見た事がありません。標準的な入力バリデーションでは何をすべし、とされているのか紹介します。
もっと読むおかしなCWE-20の読み解き方（CWE-20入門）
徳丸さんが独自のCWE-20（≒入力バリデーション）解説を行っているので、CERT（1989年に米カーネギーメロン大学に設置された世界最古のコンピューターセキュリティ専門機関）が30年くらい前から提唱し、ISO 27000／NIST SP-800-171／PCI DSS等で要求されているCWE-20の解説を改めて書きます。
CWE-20（入力バリデーション）がなぜ重要なのか？それはCERT／MITRE／ISOが入力バリデーションをどのように解説しているかを見れば解ります。いずれも最も重要／一番最初の対策としています。（※ MITREはCWEを管理する組織で、CWEの本家と言える組織です）
徳丸さんのブログより前に、このブログでもCWE-20について以下のブログで既に書いています。CERT（≒米カーネギーメロン大学のコンピューターサイエンス学科）が提唱するセキュアコーディング／コンピューターサイエンスの基盤となる基礎概念の紹介では十分ではなかったかも知れません。
ソフトウェアに入力バリデーションは必要ない 〜 ただし条件付きで
「ソフトウェアには入力バリデーションは必要ない」そんな事がある訳けないだろう？！いつも言っている事と真逆でしょ？！と思うでしょう。
しかし、「入力バリデーションが必要ないソフトウェア（＝コード）」は沢山あります、条件付きですが。
もっと読むセキュリティ機能の利用はソフトウェアセキュリティではない
7PK（7つの悪質な領域 – CWE-700として定義されている業界標準のソフトウェアセキュリティ分類）では「セキュリティ機能はソフトウェアセキュリティではない」としています。明白なのは「他のソフトウェアやデバイスのセキュリティ機能によるセキュリティ」です。7PKでは例としてHTTPSを挙げています。
HTTPSは必要なセキュリティ機能ですが、HTTPSの利用＝ソフトウェアセキュリティ、ではありません。HTTPSを使って保護できる分野はありますが、HTTPSを使っても開発者が作っているソフトウェアのセキュリティを作る物ではないからです。
結局の所、他の”モノ”に頼らず開発者が作っているソフトウェアの中でセキュリティを作らないとソフトウェアは安全になりません。7PKの「セキュリティ機能はソフトウェアセキュリティではない」とは、「ソフトウェアセキュリティはそのソフトウェアを開発している開発者が実現する」ということです。
※ 7PKはソフトウェアセキュリティの基礎概念の一つと考えられています。 （CWE-700） セキュリティ機能を使うこと自体はセキュリティ対策になります。しかし、セキュリティ機能を使う＝ソフトウェアセキュリティ対策、にはなりません。「セキュリティ機能を使う」は「必要なセキュリティ対策」のサブセット（一部、それも極一部）でしかないからです。「セキュリティ機能を使う」＝「必要なセキュリティ対策」、こういった誤解が度々あるので7PKでは「セキュリティ機能」の解説として態々明示していると思われます。一言でいうなら「ソフトウェアセキュリティは”その”ソフトウェアを作っている開発者の責任に於て作るモノ」です。「◯◯、△△、を使えばOKではない」です。
もっと読む危険なコードを書くメカニズム
世の中のソフトウェアには危険なコードが埋もれています。これがセキュリティ問題の原因になっています。なぜ危険なアプリケーションが書かれるのか？その仕組みを理解すると、対策が可能です。
もっと読む開発者の自由を許容するセキュリティ、自由を束縛するセキュリティ
アプリケーション開発におけるセキュリティ対策は大きく別けて、自由を制限するセキュリティ対策と自由を許容するセキュリティ対策の2種類に分けられると思います。
「セキュリティ対策の為に自由を制限する対策”だけ”でなければならない」とする意見を時々見かけます。しかし、これでは必要な仕様を満すソフトウェアが作れなかったり、不必要なコストが要るソフトウェアになったりします。
プログラミングを覚えたら先ず知るべきコーディングプラクティス
プログラミングを覚えたら先ず知るべきコーディングガイドラインを紹介します。このブログではこれらのガイドラインを時々紹介していましたが、まとめて紹介するのは初めてだと思います。これから紹介するガイドラインはセキュアプログラミング／防御的プログラミング／セキュアコーディングと呼ばれる考え方に基づいたガイドラインです。
ここで紹介する考え方や基本はコンピューターサイエンティストらによって原理／論理から導き出された概念／考え方です。
論理的に出鱈目なセキュリティの考え方が当たり前かのように啓蒙され、脆弱なアプリケーションの作成を助長しています。最後にアンチプラクティスの例として紹介します。
NHKのスマホセキュリティ対策と今のWebアプリセキュリティ対策は基本構造が同じ
NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。
ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。
- Androidの設定から「提供元不明のアプリ」のチェックボックスをオンにしてはならない、必ずオフにする、の説明が無かった。
- セキュリティベンダー広報担当者の説明を長々と回りく引用し説明に終始し、インストールしないことが大事であるのに、インストールしてしまった場合の症状や攻撃手法を羅列した。
- 「見覚えのないアプリは速やかに削除すること。そして、自分がどんなアカウントを利用していたかを確認し、パスワードを変更したり、企業に相談したりするなどしてほしい」などど、そもそもインストールしない、怪しいアプリをインストールできないようにする、の説明がなかった。
要するに著者は、最も根源的かつ基本的なセキュリティ対策である「検証もされていないダメなアプリを入れてはダメ」が抜けた上で、
▽セキュリティー対策ソフトを入れる。
などといった”遅すぎる事後対策”かつ”ベンダーの商売に利する対策”を啓蒙したことが問題である、との認識だと思います。
NHKが紹介した対策ページではスクリーンショット等も交えながら
▽アプリは公式アプリストアからのみダウンロードする。
としているのに、「提供元不明のアプリ」（Android 8ではアプリごとの「不明なアプリ」）のチェックボックスをオフにする、を説明しないのは何事だ！という事です。
確かにその通りだと思います。「提供元不明のアプリ」のチェックボックスは必ずオフにする、は一般スマホユーザーが何がなくてもいの一番にすべきセキュリティ対策でしょう。実際に「提供元不明のアプリ」インストールが原因で攻撃が多数成功しているのですから。
このスマホセキュリティ対策と同じようなことがソフトウェアセキュリティ対策で当たり前に行われている、と感じていました。手元の「危険なアプリの構造、安全なアプリの構造」（公開していません）の導入部分に追加したスライドを紹介します。
何故こうなった？プログラムの動作原理を無視したセキュリティ対策
正しく動作するプログラムには
- 正しい／妥当なデータ
- 正しいコード
の両方が必要です。
仕様から間違っている場合を除けば、セキュリティ問題はプログラムの誤作動によって起こります。データかコード、どちらかの問題によって発生します。
当たり前の常識ですが、これを無視したセキュリティ対策がまかり通っている、それが現在の状況です。何故こうなってしまったのでしょう？
参考： プログラム動作の構造、原理と原則
”雑”なソフトウェアセキュリティ対策とは？
先日、ソフトウェアセキュリティ対策が”雑”である、という話題になり「どのようなソフトウェアセキュリティ対策が”雑”なのか？」を説明しておかないとならないと感じました。
［名］いろいろなものが入りまじっていること。区別しにくい事柄を集めたもの。「雑の部」「雑収入」
［形動］大まかで、いいかげんなさま。ていねいでないさま。粗雑。粗末。「雑な仕事」「雑に扱う」
プログラムが正しく（＝脆弱性がなく）動作するには
- 正しいコード
- 正しいデータ
の両方が”必ず”必要です。このため、丁寧なソフトウェアセキュリティ対策には「コード」と「データ」の両方を丁寧に扱う必要があります。
今あるWebアプリの多くは「データ」の取り扱いが”雑”です。 もっと読む
今のソフトウェアセキュリティが不十分である原因とは？
ソフトウェアのセキュリティを向上させよう！と日々奮闘している方も多いと思います。しかし現在、ソフトウェアセキュリティは十分、と言える情報からは程遠い状態です。
なにが足りないのか？なぜ不十分になるのか？基本的な部分の見落としに原因があります。
脆弱性を呼ばれた側の責任にする、は通用しない
脆弱性を呼ばれた側の責任にする、は常に通用する考え方ではありません。
- ライブラリに脆弱性があるなら、ライブラリの脆弱性を直す（呼ばれた側の責任にする）
- 外部アプリケーションに脆弱性があるなら、外部アプリケーションの脆弱性を直す（呼ばれた側の責任する）
は一見正しく見えます。しかし、通用しません。
理由は簡単で、セキュリティ上困った動作をするライブラリやプログラムであっても、それが仕様で脆弱性ではないことがあります。
そもそもライブラリやユーティリティプログラムは幅広い用途に利用できるよう、用途を限定しないよう汎用的に作ってある場合が多いです。こういった仕様の場合、脆弱性を呼ばれた側の責任にする、ではセキュリティ問題を作ってしまいます。
命令と引数を分離すれば安全、と考えてしまう”とんでもない誤解”はどこから生まれるのか？
SQL文やコマンド実行には命令と引数を分離するAPIがあります。便利なAPIなのですが、安全性について根本的な勘違いが多いです。
- プリペアードクエリ系のAPIさえ使っていれば安全
- execv系のAPIさえ使っていれば安全
これらは大きな勘違いです。
- データ処理の安全性は”出力先”の処理に依存する
SQLのデータもコマンド実行のデータも、そのデータ出力の安全性は出力先（コンテクスト）でどのように処理されるかに依存します。
SQLインジェクションもコマンドインジェクションも１つでも間違いがあると大問題となる脆弱性ですが、大きな勘違いはかなり広く浸透しています。どこからこんな”とんでもない誤解”が生まれて、広まるのでしょうか？
コード”だけ”に着目すると脆弱性が量産される
コード”だけ”に着目すると脆弱性が量産されます。それはコードだけでは片手落ちであることが理由です。
- コンピュータープログラムは「コード」と「データ」によって動作する
言い換えると
- コンピュータープログラムは「機能」と「データ」によって動作する
プログラムの目的は「特定の機能」をコードによって実装することが目的ですが、動作する為には「データ」が欠かせません。
「データ」にも着目するとソフトウェアセキュリティは向上します。今実装されているソフトウェアセキュリティ対策は「コード（機能）」に偏重しているために脆弱になっています。
例えば、JSONPが危険な理由は「本来データであるJSONをプログラムとして実行している」ことにあります。
X-Content-Type-Options: nosniff を指定するのは「本来データであるJSONをJavaScriptとして実行させない」ようにすることを目的です。X-Content-Type-Options: nosniff の導入は「データ」に着目したセキュリティ対策と言えます。「データ」として完全に分離し、「コード」として実行できないようにします。
開発者の多くはソフトウェアセキュリティを考える際、「どのようなコードで攻撃を防止するのか？」を考えていると思います。これだけでは何時まで経っても信頼性が高い（＝セキュアなソフトウェア）物は”原理的”に作れないです。
※ 「コードだけに着目するセキュリティ対策」とは「攻撃が発生する箇所（コード）だけに着目するセキュリティ対策」を指しています。
「脆弱性を局所的に潰す」はアンチプラクティス
本物の「セキュアコーディング」（セキュアプログラミング）を知ればもう議論など必要ない、と思っています。本物の「セキュアコーディング」を「知ろうとしない」と幾らでもアンチプラクティスを作ってしまいます。
議論は終り、と思っていたのですがそうも行かないようなので紹介します。セキュアコーディングの概念を全く知ろうとしないで、セキュリティを作るのは「ただの無駄」です。多数のアンチプラクティス／間違いが含まれるスライドの中から（一々指摘するとキリがない）
- 「脆弱性を局所的に潰す」
これ”だけ”だとアンチプラクティスです。
※ 契約プログラミングが流行らない理由はこいうアンチプラクティスも原因でしょう。特定の良いこと”だけ”を積み重ねても良い結果にならない、ことは合成の誤謬として知られています。