入力バリデーションが甘いソースコードの検査は本当に大変

入力バリデーションが甘いアプリケーションのソースコードの検査は大変です。何が大変なのか、簡単に紹介します。

ついでに入力バリデーションが甘いアプリケーションの脆弱性診断はかなり簡単でであることも簡単に紹介します。

入力バリデーションが甘いアプリに必要なコード検査

入力バリデーションが甘いアプリに攻撃可能な脆弱性がないことを保証しようとすると、膨大な作業量の検査が必要になります。

入力バリデーションが甘い／ないアプリの場合、入力データが不正なデータであった場合にもインジェクション攻撃ができない状態か確認する必要あります。

• 不正なデータで誤作動しないか一々確認しなければならない
• その確認にはフレームワークコードの確認
• 更にその下のライブラリコードの確認
• 更にその下のライブラリコードの確認
• ….(続く)….
• 更にその下のC言語などライブラリで実際の処理をする箇所の確認

これらが必要になります。マニュアルだけで”不正なデータ”（＝攻撃データ）がAPIに渡された時に、どのように動作するのか理解れば良いのですが、判らないことが多いです。

実際、私がソースコード検査をする場合、クリティカルな箇所ではRuby/Python/PHP/Java/Scala/C#のアプリケーションコードだけでなく、フレームワークのコード、その下のライブラリのコード、最終的にはCのコードまで読んでいます。お陰でプログラムを作らない言語のフレームワークやライブラリにも結構強くなりました。

しかも、私がソースコード検査する場合はプラットフォームの得意／不得意で検査結果に大きな差がでないよう、アプリケーションコード以外の調査時間は検査時間に含めていません。

全ての検査時間をお客様負担にすれば、作業量が雪だるま式に増える入力バリデーションが甘い／ないアプリケーションのコード検査は丸儲け、ですがそれでは真っ当な商売をしていると胸を張って言えません。曲がったことが許せない性質なのでこうしています。

入力バリデーションが甘いアプリケーションの場合、実際に攻撃可能な脆弱性が見つかる事が多いです。このためお客様には喜ばれるのですが、入力バリデーションが甘いことが原因でクリティカルな問題が見つかってもあまり嬉しくありません。

入力バリデーションが甘いアプリケーションのコード検査は大変で儲らない（無料で調査する範囲が大きい）ので、CERTやISOの言う通りに全部の入力データはキッチリとバリデーションして欲しい、が本音です。正しい／妥当なデータで正しく動作するコードの検証や容易ですが、不正なデータが困った動作をしないことを検証するのは大変なのです。

一番嬉しいのは何度かコード検査をさせて頂いたコードが、少なくともこれならインジェクション攻撃を試みられても大丈夫、と文句の付けようがないコードになっている時です。

入力バリデーションが甘いアプリの脆弱性検査

コード検査では困りモノの入力バリデーションが甘いアプリは、外部からの脆弱性検査だと大助かりです。

ここでいう脆弱性検査とは外部から”攻撃用データ”を送信し、アプリに脆弱性がないか検査するタイプの検査を指しています。よく利用されているセキュリティ検査はこのタイプだと思います。

入力バリデーションが甘いアプリのソースコード検査で問題になることが、外部から脆弱性を炙り出す脆弱性検査では助かります。外から検査して何も見つからないのは良いことですが、何か見つかった方が有り難がられます。

ソースコード検査で以下の最下層の実装レベル問題の確認は困難なので問題なります。しかし、外部からの脆弱性検査だと、不確実性が高いですが、簡単に問題を見つける機会を飛躍的に増やします。

• 不正なデータで誤作動しないか一々確認しなければならない
• その確認にはフレームワークコードの確認
• 更にその下のライブラリコードの確認
• 更にその下のライブラリコードの確認
• ….(続く)….
• 更にその下のC言語などライブラリで実際の処理をする箇所の確認

外部から脆弱性を検査する場合、一々実装を調べる必要はありません。攻撃用データを送り、アプリケーションがおかしな動作をしないか確認するだけです。

SELECT * FROM tbl WHERE id = 攻撃用データ;

といった脆弱なコードを見つける時と同じ作業で、様々なインジェクション攻撃パターンのデータを送ってアプリケーション動作に問題がないか確認するだけで

• アプリケーションコードの確認
• フレームワークコードの確認
• 更にその下のライブラリコードの確認
• 更にその下のライブラリコードの確認
• ….(続く)….
• 更にその下のC言語などライブラリで実際の処理をする箇所の確認

まで出来てしまいます。コード検査はあまり効率的に自動化／パターン化できません。¹ 一方、「攻撃用データを送る作業」は割と効率良く自動化／パターン化が可能です。

入力バリデーションが甘いアプリケーションがおかしな動きをした時に、その動作が脆弱性によるモノなのか、アプリケーション仕様による妥当なエラーによるモノなのか、見分ける勘も必要ですが自動化／パターン化により

• お客様のアプリケーションコードの脆弱性（多くの場合、出力時のフェイルセーフ対策問題）
• その下のフレームワーク／ライブラリの脆弱性

の両方を見つけることが可能になります。²

入力バリデーションが甘い／ないアプリケーションはありとあらゆる問題の原因を大っぴらにしている状態です。検査する側としては脆弱性を見つけやすい好都合なアプリケーションと言えます。

脆弱性を隠す対策は良くない？！

プログラムが正しく動作（誤作動／脆弱性なく動作）するには

• 正しい／妥当なデータ
• 正しいコード

が絶対に必要です。これはプログラムの動作原理です。

サンプルが１人なので、この人だけかも知れませんが「入力バリデーションは脆弱性を隠す対策なので良くない対策である」とする意見を脆弱性検査サービスを提供している人から直接聞いた事があります。

出鱈目なデータを使い誤作動／脆弱性が生まれるのもコードがあるのも問題です。不正なデータでフェイルセーフ機能が働く、は必須のセキュリティ機能です。しかし、正しい／妥当なデータであること、はプログラムが正しく動作する為の必須条件です。

ISO 27000やCERT、SANSは10年以上前から入力バリデーションがアプリケーションセキュリティで最も重要だとしています。IPAも周回遅れですが去年から加わりました。

同じ人が「ISOなどの標準などどうでも良い」といい、Webアプリファイアーウォールの構築サービスも提供しています。

アプリケーションには厳格な入力バリデーションは必要ないとし、その上でWebアプリケーション用に弱いブラックリスト型の入力バリデーション機能であるWebアプリファイアウォール（WAF）を売るのどういうことなのか？？WAFと診断サービスを売りたいだけ？？と感じたので強く印象に残っています。

アプリの奥深くに眠っている脆弱性、普通にデータバリデーションさえしていれば問題にならない問題、をインターネットに公開させた状態が良い、とする意見には一ミリも賛成できません。

まとめ

入力データのバリデーションが甘いとソースコード検査が大変ということは、異常なデータでも正しく動作するアプリケーションであることの保証が難しい、ことを意味ます。全てのアプリケーション入力を厳格にバリデーションしましょう。³ その方が何倍も簡単です。

入力データをアプリケーションの境界でキッチリ検証していないアプリケーションは、ファイアウォール無しでインターネットに接続しているネットワークシステムと同じ状態です。

CERTやISOが勧めるように入力データをバリデーションすると確実にアプリケーションセキュリティは向上します。（＋セキュリティ問題とならないバグも少なくります）⁴

コード検査型の検査でも、外部からの脆弱性診断でも、攻撃可能な脆弱性を大幅に減らせます。

最後にコード検査をしていて良く見つかるクリティカルな問題の例はブログに書いているので紹介します。