カテゴリー
Computer Development PHP Security Programming Secure Coding Security

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

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

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

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

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

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

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

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

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

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

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

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

カテゴリー
Computer PHP Security Programming Secure Coding Security

構造化設計とセキュアコーディング設計の世界観は二者択一なのか?

プログラミングの「世界観」

で構造化プログラミング/オブジェクト指向プログラミングの世界観(パラダイム)では、抽象化を行い問題を関数やオブジェクトの中に閉じ込める。つまり、プログラムの内部奥深くに”問題”を閉じ込めようとする。

セキュアコーディングの世界観では、”正しくないデータはどう処理しても正しく処理不可能である”プログラム原理と”失敗する物はできる限り早く失敗させる”Fail Fast原則に従い、できる限り問題となる”データ”を早い段階で廃除する、つまり問題を中に入れずに入り口で対策する、と紹介しました。1

一見すると相反するように見えますが、これら2つの世界観を持つ概念は二者択一ではありません。

カテゴリー
Computer PHP Security Programming Secure Coding Security

プログラミングの「世界観」

rustcを通らないコードは間違っているに以下のような記述があります。

「そのコードがRust wayではない」という点で「間違っている」。microなスタイルからmacroな設計まで、ありとあらゆる点でRust的なコードであることを暗黙的ではあるが極めて強く要求する。それがRustというプログラミング言語だ。

Rustはコンパイル時点で可能な限りの正しく実行できないコードが生成されないような言語になっていることは比較的良く知られていると思います。このブログはこの違いを「世界観」が異なるという視点でまとめています。

Rustの場合、マルチスレッドプログラミングでデータ競合が起きないような書き方をしなければならない制約があり、従来のプログラミング言語とは異なる考え方(=世界観)が要求されている。自分のコードは正しくても「Rustの世界観では間違っている」としています。

「世界観」の違いで言語やプログラミング方式を捉える考え方は面白いと思います。

カテゴリー
Computer Development PHP Security Programming Secure Coding Security

プログラムから「想定外」を無くす方法

ほとんどセキュリティ問題は「想定外の動作」が原因です。例えば、インジェクション攻撃は開発者にとって「想定外の動作」でしょう。ソフトウェア開発者が意図しない想定外の動作のほとんどは「想定外のデータ」が原因です。

この事実をから簡単に分かる「想定外」を無くす方法があります。たった2つの方法を”両方”行うだけで、現在あるアプリの9割程度の脆弱性が無くなります。

今まで出来る限り正確に「どうすれば想定外をなくせるか?」を紹介してきましたが、今回は出来る限り簡潔にどうすると良いのか、ダメなのか紹介したいと思います。

カテゴリー
Computer Development PHP Security Programming Secure Coding

セキュリティを論理的に構築する方法

セキュリティの原理、原則、ベストプラクティスに自分でコメントを追加しました。以前、論理的にセキュリティ対策を検証する方法論理的なセキュリティ対策の評価方法は書いたのですが、論理的にセキュリティを構築する方法は書いていないことを思い出しました。追加したコメント欠陥だらけのソフトウェアセキュリティ構造を紹介したブログをベースにセキュリティを論理的に構築する方法を紹介します。

このエントリの解説はCERT、つまり米カーネギーメロン大学、の資料をベースにしています。

カテゴリー
Computer Development PHP Security Programming Secure Coding Security

バリデーションには3種類のバリデーションがある 〜 セキュアなアプリケーションの構造 〜

バリデーション、と一言で言っても一種類/一箇所だけではありません。バリデーションには3種類のバリデーションがあります。

バリデーションは重要であるにも関わらず誤解が多い機能の筆頭だと思います。日本に限らず世界中でよくある議論に

  • バリデーションはモデルで集中的に行うべきだ!
  • なのでコントローラー(入力)でバリデーションなんて必要ない!
  • モデル集中型バリデーション以外の方法/場所でバリデーションするのは非効率で馬鹿馬鹿しい考えだ!

があります。どこかで見た事があるような議論ですが、世界的にこのような考えの開発者が多いことは、この入力バリデーション用のPHP拡張モジュールを書いた時の議論で分かりました。1

実際、多くのWebアプリケーションフレームワークは入力バリデーション機能をデフォルトでは持たず、アプリケーションレベルでの入力バリデーションを必須化していません。開発者が上記のような考えになっても当然と言えるかも知れません。しかし、必要な物は必要です。何故?と思った方はぜひ読み進めてください。

流石にこの時の議論ではありませんでしたが、以下の様な議論も見かけます(ました)

  • 入力データはバリデーションはできない!
  • どんな入力でもWebアプリは受け付けて”適切”に処理しなければならない!
  • 入力バリデーションにホワイトリスト型は無理、適用できない!
  • ブラックリスト型とホワイトリスト型のバリデーションは等しいセキュリティ対策!
  • 入力バリデーションはソフトウェアの仕様でセキュリティ対策ではない!
  • 脆弱性発生箇所を直接または近い個所で対策するのが本物のセキュリティ対策である!

全てセキュアなソフトウェア構造を作るには問題がある考え方です。最後の「入力バリデーションはソフトウェアの仕様でセキュリティ対策ではない!」とする考え方の問題点は”セキュリティ対策の定義”2を理解していないと問題点は見えないかも知れません。

  • セキュリティ対策(=リスク管理)とはリスクを変化させる全ての施策で、多くの場合はリスクを廃除/軽減させる施策だが、それに限らない。

このセキュリティ対策の定義はISO 27000/ISMSの定義をまとめたモノです。

TL;DR;

何事も原理と基本が大切です。基礎的な事ですがプログラムの基本構造と動作原理を正しく理解しておく必要があります。

セキュアコーディングの構造/原理/原則

入力対策と出力対策は両方必要でバリデーションはセキュアなソフトウェア構築には欠かせません。

  • 原理1: コンピュータープログラムは「妥当なデータ」以外では正しく動作できない
  • 原理2: 何処かでエラーになるから、ではセキュアにならない遅すぎるエラーはNG

アプリケーションの入り口で入力バリデーション(入力検証)をしていないアプリはセキュアでない構造です。

入り口以外に入力検証がないアプリもセキュアではない構造です。セキュアなアプリには最低限、入り口でのデータ検証と出口でのデータ無害化(エスケープ/無害化API/バリデーション)が必須です。

  • プログラムは妥当なデータでしか正しく動作できない入力バリデーションは原理的に必須
  • 出力対策は必須の物とフェイルセーフ対策の物があるフェイルセーフ対策の場合は下層の多層防御です。そもそも”データが妥当でない場合”(=フェイルセーフ対策)のエラーは起きてはならない。当然ですが出鱈目なデータを処理するのもNG。

多層防御 3 は重要なのに勘違いされているソフトウェアセキュリティ要素の1つです。

バリデーションには3つの種類があります。

  • 入力バリデーション正しく動作する為に必須(主に形式検証)
  • ロジックバリデーション正しく動作する為に必須(主に論理検証)
  • 出力バリデーション –  大半が上の2つに失敗した場合のフェイルセーフ対策(追加の対策 – 安全な特定形式のみ許可の場合)

※ 出力時のエスケープ/エスケープが不必要なAPIの利用によるデータの無害化は、必須の対策が半分、フェイルセーフ対策が半分です。

※ “入力ミスの確認”を”バリデーション”と考えたり、言ったりすると混乱の元です。”入力ミス/論理的整合性の確認エラー”は処理の継続、”あり得ないデータによるバリデーションエラー”では処理の中止、が必要なので区別する方が良いです。

※ ソフトウェア基本構造の入力処理では”あり得ないデータによるバリデーションエラー”、ロジック処理では”入力ミス/論理的整合性の確認エラー”、になります。

※ リスク分析の経験があれば自然にセキュアな構造を思い付くことも可能だと思います。

リスク分析とリスク対応をしよう

イメージ図:

カテゴリー
Computer Development PHP Security Security

「出力対策だけのセキュリティ設計」が誤りである理由

まず結論から。タイトルの通り「出力対策だけのセキュリティ設計は設計ミス」です。

なぜ「出力対策だけのセキュリティ設計は設計ミス」なのか?