PostgreSQL 11がリリースされました。このリリースでto_number()、to_char()、to_date()、to_timestamp()関数の仕様が変更されました。これらは名前の通り入力を変換する関数です。その際に
を行います。保存されるデータ形式は、保存可能な形に変換されます。しかし、これは十分ではないです。遅すぎるサニタイズがダメな例として紹介します。
※ エスケープやプリペアードクエリもサニタイズ（無害化）の一種です。
もっと読む世の中のソフトウェアには危険なコードが埋もれています。これがセキュリティ問題の原因になっています。なぜ危険なアプリケーションが書かれるのか？その仕組みを理解すると、対策が可能です。
もっと読むITセキュリティ対策の概念で最も足りていないモノは「構造化」ではないでしょうか？
システム開発者は常に「システムの構造化」を考えています。構造化プログラミング、オブジェクト指向設計、DoA、DDDなど「システムの構造化」には様々な構造が考えられています。
何故か「セキュリティの構造化」を十分考えていないのが現状です。その結果、「”基本構造が無い”場当たり的セキュリティ対策」に終始しています。
ソフトウェアにバグがあった場合、そのバグは”ただのバグ”で”単純に意図しない余計な動作をする箇所を直す”、で万事OK！でしょうか？
ここでは”ただのバグ”とは”問題が起きた時に問題が起きた箇所を直せばOK”なバグとして話を進めます。
もっと読むセキュアコーディング／セキュアプログラミングはコンピューター動作の基礎的原理から構築されています。初めてプログラムが書かれた時から現在に至るまで、全てのプログラムは同じ基本構造を持っています。
基本原理／基本構造に合わないセキュリティ対策/構造では満足できるセキュリティ状態の達成は不可能です。残念ながら大半のWebアプリが原理に反する脆弱な構造を持っています。
IPAが出鱈目なセキュアプログラミングを啓蒙していた責任は大きいと言わざるを得ないでしょう。昨年、修正しましたが誤りを訂正すべく十分な啓蒙を行っているとは言えないように見えます。
もっと読むAttack Surface （攻撃可能面=攻撃可能な箇所）の管理はセキュリティ対策の基本中の基本です。あまりに基本すぎてあまり語られていないように思います。
攻撃可能面を管理するには先ず攻撃可能な箇所がどこにあるのか分析（＝リスク分析）します。その上でできる限り攻撃可能な箇所を削減（＝リスク削減）します。攻撃可能面の分析と管理とはリスク分析と管理です。セキュリティ対策そのものと言える、基本的な管理です。
Attack Surface (攻撃可能面)
The attack surface of a software environment is the sum of the different points (the “attack vectors“) where an unauthorized user (the “attacker”) can try to enter data to or extract data from an environment.[1][2] Keeping the attack surface as small as possible is a basic security measure.
出典：Wikipedia
日本語訳すると以下のようになります。
もっと読むソフトウェア環境における攻撃可能面は不正なユーザー（攻撃者）がデータを攻撃対象に入力または取り出し可能な様々箇所（アタックベクター）の集合である。攻撃可能面を可能な限り小さくするのは基本的なセキュリティ対策である。
プログラミングを覚えたら先ず知るべきコーディングガイドラインを紹介します。このブログではこれらのガイドラインを時々紹介していましたが、まとめて紹介するのは初めてだと思います。これから紹介するガイドラインはセキュアプログラミング／防御的プログラミング／セキュアコーディングと呼ばれる考え方に基づいたガイドラインです。
ここで紹介する考え方や基本はコンピューターサイエンティストらによって原理／論理から導き出された概念／考え方です。
論理的に出鱈目なセキュリティの考え方が当たり前かのように啓蒙され、脆弱なアプリケーションの作成を助長しています。最後にアンチプラクティスの例として紹介します。
NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。
ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。
要するに著者は、最も根源的かつ基本的なセキュリティ対策である「検証もされていないダメなアプリを入れてはダメ」が抜けた上で、
▽セキュリティー対策ソフトを入れる。
などといった”遅すぎる事後対策”かつ”ベンダーの商売に利する対策”を啓蒙したことが問題である、との認識だと思います。
NHKが紹介した対策ページではスクリーンショット等も交えながら
▽アプリは公式アプリストアからのみダウンロードする。
としているのに、「提供元不明のアプリ」（Android 8ではアプリごとの「不明なアプリ」）のチェックボックスをオフにする、を説明しないのは何事だ！という事です。
確かにその通りだと思います。「提供元不明のアプリ」のチェックボックスは必ずオフにする、は一般スマホユーザーが何がなくてもいの一番にすべきセキュリティ対策でしょう。実際に「提供元不明のアプリ」インストールが原因で攻撃が多数成功しているのですから。
このスマホセキュリティ対策と同じようなことがソフトウェアセキュリティ対策で当たり前に行われている、と感じていました。手元の「危険なアプリの構造、安全なアプリの構造」（公開していません）の導入部分に追加したスライドを紹介します。
で構造化プログラミング／オブジェクト指向プログラミングの世界観（パラダイム）では、抽象化を行い問題を関数やオブジェクトの中に閉じ込める。つまり、プログラムの内部奥深くに”問題”を閉じ込めようとする。
セキュアコーディングの世界観では、”正しくないデータはどう処理しても正しく処理不可能である”プログラム原理と”失敗する物はできる限り早く失敗させる”Fail Fast原則に従い、できる限り問題となる”データ”を早い段階で廃除する、つまり問題を中に入れずに入り口で対策する、と紹介しました。1
一見すると相反するように見えますが、これら２つの世界観を持つ概念は二者択一ではありません。
rustcを通らないコードは間違っているに以下のような記述があります。
「そのコードがRust wayではない」という点で「間違っている」。microなスタイルからmacroな設計まで、ありとあらゆる点でRust的なコードであることを暗黙的ではあるが極めて強く要求する。それがRustというプログラミング言語だ。
Rustはコンパイル時点で可能な限りの正しく実行できないコードが生成されないような言語になっていることは比較的良く知られていると思います。このブログはこの違いを「世界観」が異なるという視点でまとめています。
Rustの場合、マルチスレッドプログラミングでデータ競合が起きないような書き方をしなければならない制約があり、従来のプログラミング言語とは異なる考え方（＝世界観）が要求されている。自分のコードは正しくても「Rustの世界観では間違っている」としています。
「世界観」の違いで言語やプログラミング方式を捉える考え方は面白いと思います。
ほとんどセキュリティ問題は「想定外の動作」が原因です。例えば、インジェクション攻撃は開発者にとって「想定外の動作」でしょう。ソフトウェア開発者が意図しない想定外の動作のほとんどは「想定外のデータ」が原因です。
この事実をから簡単に分かる「想定外」を無くす方法があります。たった2つの方法を”両方”行うだけで、現在あるアプリの9割程度の脆弱性が無くなります。
今まで出来る限り正確に「どうすれば想定外をなくせるか？」を紹介してきましたが、今回は出来る限り簡潔にどうすると良いのか、ダメなのか紹介したいと思います。 もっと読む
セキュリティの原理、原則、ベストプラクティスに自分でコメントを追加しました。以前、論理的にセキュリティ対策を検証する方法や論理的なセキュリティ対策の評価方法は書いたのですが、論理的にセキュリティを構築する方法は書いていないことを思い出しました。追加したコメントと欠陥だらけのソフトウェアセキュリティ構造を紹介したブログをベースにセキュリティを論理的に構築する方法を紹介します。
このエントリの解説はCERT、つまり米カーネギーメロン大学、の資料をベースにしています。
バリデーション、と一言で言っても一種類／一箇所だけではありません。バリデーションには3種類のバリデーションがあります。
バリデーションは重要であるにも関わらず誤解が多い機能の筆頭だと思います。日本に限らず世界中でよくある議論に
があります。どこかで見た事があるような議論ですが、世界的にこのような考えの開発者が多いことは、この入力バリデーション用のPHP拡張モジュールを書いた時の議論で分かりました。1PHP開発者MLで議論したのですが、紹介したような議論をした方が少なからず居ました。少し続くとすかさず「そもそもActiveRecordパターンでないモデルも多数あるし、ActiveRecordパターンのモデルだけのバリデーションだと遅すぎ、その間に実行させる機能が悪用されるケースは山程あって、しかもそれが奥深いライブラリのどこで起きるか分らんだろ」的なツッコミがあるところは日本での議論とは異なった点です。
実際、多くのWebアプリケーションフレームワークは入力バリデーション機能をデフォルトでは持たず、アプリケーションレベルでの入力バリデーションを必須化していません。開発者が上記のような考えになっても当然と言えるかも知れません。しかし、必要な物は必要です。何故？と思った方はぜひ読み進めてください。
流石にこの時の議論ではありませんでしたが、以下の様な議論も見かけます（ました）
全てセキュアなソフトウェア構造を作るには問題がある考え方です。最後の「入力バリデーションはソフトウェアの仕様でセキュリティ対策ではない！」とする考え方の問題点は”セキュリティ対策の定義” 2セキュリティ対策＝リスク管理、にはリスクを増加させる施策も含め、定期的にレビューしなければならないです。（ISO 27000／ISMSの要求事項）リスクを増加させる施策、例えば認証にパスワードを利用など、は定期的にレビューしその時々の状況に合ったリスク廃除／軽減策をタイムリーに導入しなければならない。リスク増加要因を管理しないセキュリティ対策＝リスク管理は”欠陥のある管理方法”です。 を理解していないと問題点は見えないかも知れません。
このセキュリティ対策の定義はISO 27000／ISMSの定義をまとめたモノです。
何事も原理と基本が大切です。基礎的な事ですがプログラムの基本構造と動作原理を正しく理解しておく必要があります。
入力対策と出力対策は両方必要でバリデーションはセキュアなソフトウェア構築には欠かせません。
アプリケーションの入り口で入力バリデーション（入力検証）をしていないアプリはセキュアでない構造です。
入り口以外に入力検証がないアプリもセキュアではない構造です。セキュアなアプリには最低限、入り口でのデータ検証と出口でのデータ無害化（エスケープ／無害化API／バリデーション）が必須です。
多層防御 3ソフトウェアに限らずセキュリティは多層で防御します。必ず必要な対策と無くても大丈夫なハズの対策（フェイルセーフ対策）の2種類がある。フェイルセーフ対策は万が一の対策であり、本来フェイルセーフ対策は動作してはならない。動作した場合はプログラムに問題がある。「動作してはならない」は「必要ない」ではない。実用的なプログラムは複雑であり失敗してしまうケースは十分にある。入力バリデーションが甘い／無いプログラムだとフェイルセーフ対策が機能してしまうことは当たり前に起きる。 は重要なのに勘違いされているソフトウェアセキュリティ要素の１つです。
バリデーションには3つの種類があります。
※ 出力時のエスケープ／エスケープが不必要なAPIの利用によるデータの無害化は、必須の対策が半分、フェイルセーフ対策が半分です。
※ “入力ミスの確認”を”バリデーション”と考えたり、言ったりすると混乱の元です。”入力ミス／論理的整合性の確認エラー”は処理の継続、”あり得ないデータによるバリデーションエラー”では処理の中止、が必要なので区別する方が良いです。
※ ソフトウェア基本構造の入力処理では”あり得ないデータによるバリデーションエラー”、ロジック処理では”入力ミス／論理的整合性の確認エラー”、になります。
※ リスク分析の経験があれば自然にセキュアな構造を思い付くことも可能だと思います。
イメージ図：
参考：データもコードも一文字でも間違い／不正があるのはNG
まず結論から。タイトルの通り「出力対策だけのセキュリティ設計は設計ミス」です。
なぜ「出力対策だけのセキュリティ設計は設計ミス」なのか？
「しっかり出力対策”だけ”するのがセキュリティ対策のベストプラクティス」とする考え方1があります。しかし、これはベストプラクティスどころかアンチプラクティスです。
アンチプラクティスをベストプラクティスと勘違いしている限り、満足のいくセキュリティ対策（＝リスク管理）は不可能です。セキュリティ対策は総合的なリスク対策です。「これ”だけ”やれば良い」とするセキュリティ対策は大抵アンチプラクティス2です。
※ 今まで出力対策”だけ”がセキュリティ対策だと勘違いしていた方には確証バイアスが働きやすいようです。論理的／構造的にどうすればリスクを効果的に削減できるのか？を考えると理解るはずです。