セキュアコーディング／セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。（※ 対策の目的が何か？などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません）
どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング／セキュアプログラミングのガイドラインなどがどうなっているのか？紹介します。
このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング／セキュアプログラミングとは何か？は過去のブログをご覧ください。
記事を探すことができなかったのですが、少し前に元記事が英語で日本語訳された記事に「セキュアプログラミング・コーディングはハイプ（誇大な宣伝）である」とする記事がありました。これには全く賛同できません。
なぜセキュアプログラミング”だけ”でセキュアなプログラムが作らないのか？理由を考えてみたいと思います。
目的と手段、これを取り違えて大きな誤りを犯してしまうことはよくあります。これはセキュリティ対策に限ったことではありません。
対策をセキュリティ対策の目的と手段を取り違えると、根本的な誤りを犯してしまいます。
備考：目的と手段の取り違えが根本的な原因と言えますが、「セキュリティ対策」定義を取り違えているとこのブログの内容は理解しずらいかも知れません。セキュリティ対策に「緩和策」や「リスク増加」が含まれることを認識されていない方はまずセキュリティ対策の定義を確認ください。
このブログを継続的に読んでいる方なら私が「個々のセキュリティ脆弱性対策も重要だが、基本的考え方や概念はより重要である」と考えていることがわかると思います。「個々の脆弱性対策だけやれば良い」とする議論がありますが、これには色々な欠陥があります。このため、「個々の脆弱性対策だけやる」では効果的なセキュリティマネジメントができません。つまり、より危険なセキュリティになってしまいます。
追記：このエントリだけではなぜマネジメントが大切なのかは伝わらないと思うので、容易に導入できるセキュア開発メソドロジー – OpenSAMM を書きました。こちらも参照ください。
徳丸さんとの議論は終わっている いるので議論することはありません。しかし、 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ というおかしなスライドが目に入ったのでコメントしておきます。今現在で2万近くのビュー回数もあると放っておけません。
”セキュリティ専門家”という肩書を持つ方が非論理的／非科学的な独自のセキュリティ理論を展開されるようでは、誤解してしまった開発者がセキュアでないコードを書いてしまいます。どのように非論理的／非科学的なのか簡単にコメントします。
昨日書いた安全なAPI過信症候群の処方箋 – execv/SQLite3編はSQLiteの仕様がRDBMSとしてエキゾチック過ぎて、さらっと書いたよくあるRDBMSでの「安全なAPI過信症候群」を全く理解して頂けなかったケースもあるようなのでもう一度書きます。
プリペアードクエリには色々問題もあり、セキュリティ対策としてそれだけ教えるのはNG、と考えている方はプリペアードクエリ過信症候群ではないので、このエントリを読む必要はありません。
またプリペアードクエリなど、安全とされるAPI万能と考えている方に会ったのでエントリを書きました。広く病気として治療すべき、と思いエントリを書きます。安全なAPI過信症候群と名付けました。
安全なAPI過信症候群（同類にプリペアードクエリ過信症候群など）：「安全」とされるAPIを使えば安全と、盲目的に信用し考慮すべきリスクを考えない症候群。ITエンジニアが発症し最も重要なセキュリティ対策である入力バリデーションを「必要ない、できない、セキュリティ対策ではない」エスケープは「必要ない、有害である」とする場合、かなり重度の場合が多い。
このブログでは既に何度もプリペアードクエリクエリは不完全である、と指摘しています。プリペアードクエリを使っていれば安全と盲目的に信じている方向けの基礎知識を紹介します。コマンド実行APIのexecvと最も多く利用されているRDBMS、SQLite3が題材です。
現実を知れば安全とされるAPIを盲信することも危険だと解り、安全なAPI過信症候群を完治できると思います。
ツイッターでの議論を見て「SQLエスケープを教える必要はない」とする原因は「教育の基本」と「セキュリティの基本」の理解不足が「根本的な原因」だと解ってきました。この事についてもブログを書くかも知れませんが、今日は「オレオレSQLセキュリティ教育」、言い換えると「自分の環境に特化したSQLセキュリティ教育」について書きます。一般論・基礎としてのセキュリティ教育は、自分の環境に特化したセキュリティ教育では困る、という話です。
このエントリは「貴方が普段言っている事が間違っている」と非難または攻撃しているのではありません。実務で「プリペアードクエリ・プレイスホルダ・ORMを使いましょう」と言うことは全く間違っていません。セキュリティ教育はこういう手順で教えたほうが解りやすいです、と提案しています。
もっと読む
追記：このエントリの背景となる根拠の一部となる開発者は必修、SANS TOP 25の怪物的なセキュリティ対策に書きました。こちらも合わせてご覧ください。
今日のエントリは「セキュリティ業界ジョブセキュリの為のセキュリティー対策になっていないか？」という話です。
知らないと仕事にならないような、雇用を守る作用を持つ手法や知識のこと。
セキュリティ対策は様々な対象を守る為に行いますが、このエントリではアプリケーションセキュリティを維持することだけを考えます。
Webアプリの入力はバリデーションできない、と誤解している方は少なく無いようです。システム開発に関わる人でなければ誤解していても構わないのですが、システム開発者が誤解していると安全なシステムを作ることは難しいでしょう。
Webアプリの入力はバリデーションできない、と誤解している開発者にも理解できるよう噛み砕いて解説してみます。
徳丸さんとはホワイトリスト VS ブラックリストの議論から楽しく話をしています。私はホワイトリスト型で対処する方がよりセキュアであると考え、徳丸さんはブラックリストも変わらない。としています。考え方が反対なので楽しいのです。残念ながらあまりブログなどに時間を取りなくないのですが、わざわざ徳丸さんがブログを書いた、とツイッターで教えていただいたので簡単に返信しておきます。
http://tumblr.tokumaru.org/post/55587596019
私は「バリデーションはセキュリティ対策とは言えない」と思っているのですが、実は「世界の常識」という点に異論があるわけではなくて、話は逆なのです。「従来からバリデーションはセキュリティ対策としてとらえられてきて『世界の常識』となっているが、実はそれはおかしいのではないか?」という問題提起をしているのです。なので、「世界の常識だろ」と言われても、それでは反論になっていません。
結論からいうと入力パラメータのバリデーションは世界のセキュリティ専門家によって非常に有用なセキュリティ対策だと認められています。
ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
参考：プログラムが正しく動作するには、正しい「データ」と「コード」両方が必須。データのバリデーション（＝セキュリティ対策）がない対策はあり得ない。
徳丸さんから「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい 」とあったのでツイッターで返信するには少し長いのでこちらに書きます。まだ直していない脆弱性を詳しく解説するのはあまりよくないのですが、今なら影響を受けるアプリはほぼないと思うので構わないでしょう。
まず前提として、Webサーバと同様にJavascriptからもクッキーが設定できます。Javascriptインジェクションに脆弱なコードがサイトに1つでもあると、サイト上のセッションアダプション脆弱性をもつアプリへの攻撃が可能になります。この攻撃を緩和する対策もありますが、それはそれ、これはこれなので省略します。
セッションアダプションに脆弱なセッション管理機構で困る代表的なケースは以下の通りでしょう。
PHPのセッションアダプション脆弱性がどのように影響するのか、広く誤解されているようです。セキュリティ専門家でも正しく理解していないので、一部のPHP開発者が正しく理解しなかったのは仕方ないのかも知れません。
Webセキュリティの第一人者の一人である徳丸氏は「PHPのセッションアダプション脆弱性は脅威ではない」と書いていますが、いろいろ間違いです。私は2005年頃から現在まで様々な機会に問題であると何度も繰り返し説明しており、しばらくすれば間違いに自分で気付くのでは？と思っていたので特に反論していませんでした。しかし、まだ気づかれていないようなので、幾つかある攻撃パターンのうち解りやすい例を1つだけ紹介しておきます。
一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。
その間違いとは
です。(※0)
私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。
不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。
参考：エンジニア向けにもう少し解りやすいブログを最近書いています。