個々の脆弱性に対応する効果的な方法
全体的なセキュリティ対策やセキュリティ対策の基本的概念の話が続いたので、個々の脆弱性に対応するための効果的な方法を紹介します。前提知識なく、個々の脆弱性に対応するには、個々の脆弱性全て知る必要があります。
「個々の脆弱性対策だけやれば良い」とする議論に組みしない理由
このブログを継続的に読んでいる方なら私が「個々のセキュリティ脆弱性対策も重要だが、基本的考え方や概念はより重要である」と考えていることがわかると思います。「個々の脆弱性対策だけやれば良い」とする議論がありますが、これには色々な欠陥があります。このため、「個々の脆弱性対策だけやる」では効果的なセキュリティマネジメントができません。つまり、より危険なセキュリティになってしまいます。
追記：このエントリだけではなぜマネジメントが大切なのかは伝わらないと思うので、容易に導入できるセキュア開発メソドロジー – OpenSAMM を書きました。こちらも参照ください。
今時のShellcodeとセキュア／防御的プログラミング
コンピュータセキュリティのことを考えるとShellcode（シェルコード）のことを忘れる訳にはいきません。Shellcodeとはバッファーオーバーフローを利用してコンピューターに任意コードを実行させるコードの総称です。そもそもは/bin/shなどのシェルを奪うコードが主だったので、この種のコードはShellcodeと呼ばれています。現在はシェルを奪う物だけでなく、他の操作を行う物もShellcodeと呼ばれています
Shellcodeを作る方は、山があるから登るのと同じで、Shellcodeが作れるから作る、のだと思います。
私個人はShellcodeを作ること、使うことに全く興味はないです。しかし、Shellcodeとそれを利用した攻撃は、防御の為に興味を持っています。簡単に今どきのShellcodeはどのようになっているのかまとめます。
CERT Top 10 Secure Coding Practices
CERTは米カーネギーメロン大学に設置されたコンピュータセキュリティ対策を行う老舗の組織です。CERTが設立される前もセキュリティが無視されていたのではありませんが、CERT設立後と前ではコンピュータセキュリティ、特にソフトウェアセキュリティに対する考え方が大きく変わりました。詳しくはセキュアプログラミング（防御的プログラミング）の歴史をざっと振り返るを参照してください。
CERTはSecure Coding Standardsとして
- SEI CERT C Coding Standard
- CERT C++ Coding Standard
- AndroidTM Secure Coding Standard
- SEI CERT Oracle Coding Standard for Java
- SEI CERT Perl Coding Standard
を公開しています。その中でもセキュアコーディング（セキュアプログラミング／防御的プログラミング）で最も重要なトップ10をTop 10 Secure Coding Practicesとしてまとめています。
日本語訳が無いようなので資料として利用できるよう私訳しておきます。
（追記：IPAのセキュアコーディングガイドは入力対策が出鱈目でした。 2017年からやっとIPAがCERT Secure Coding Practicesをセキュアコーディングの”原則”として紹介するようになりました。CERT版では出力対策を7番目に記載しています。IPAは順序を変えて2番目にしています。トップ10の原則とする際に順序を入れ替えるのは混乱の元です。オリジナルの順序のままにすべきだと思います。順序を変えると外国人とコミュニケーションが取れなくなります。）
よく勘違いされているので書いておきます。入力対策と出力対策は”独立したセキュリティ対策”です。間違えないようにしましょう。
入力バリデーションが第1位の対策であるのは科学的／論理的／原理的な理由が根拠となっています。最も重要な対策ですが、よく誤解されています。
参考：
OWASP Secure Coding Practices – Quick Reference Guide
OWASPのガイドラインはPCI DSSでも参照するように指定されているセキュリティガイドラインです。その中でも比較的簡潔かつ体系的にセキュアプログラミングを解説した資料がOWASP Secure Coding Practices – Quick Reference Guide (v2) です。
日本語訳がないようなので一部未訳ですが訳しました。CC-BY-SAライセンスです。クリエイティブコモンズライセンスに従って自由に配布できます。
チェックリスト形式になっているので、自分のコーディング／開発スタイルがどの程度適合しているのか、簡単にチェックできるようになっています。コーディングスタイルのみでなく、運用はシステム構成に関連する物も含まれています。私が解説／紹介しているセキュリティ対策を行っている開発チームであればこれらの殆どに適合しているはずです。どのくらい適合していたでしょうか？
イントロダクションでは、開発者に対して少々厳しいことが書いてあります。
この技術的不可知論文書は一般的なセキュアコーディングを実践に必要な要素をソフトウェア開発ライフサイクルに統合可能なチェックリストとして定義します。
「技術的不可知論文書」（不可知論：物事の本質は人には認識することが不可能である、とする立場のこと ※ ）としているのは、この文書が取り扱うセキュアコーディングの本質が理解されていない、理解されることがない、と嘆いていることを意味します。セキュアコーディングの本質の解説は諦めて作ったチェックリストであることを示唆しています。私も同じ感覚を共有しています。興味がある方はぜひ以下の参考資料を参照してください。原理と原則を知った方が応用範囲が広がります。
正確な直訳より分かり易さを優先しました。見直しをする時間まではありませんでした。誤り、誤解を招く訳などの指摘を歓迎します。
※ Agnostic（不可知論）について： このガイドは2010年に公開された文書です。最近、agnosticは「〜に依存しない」「〜に関わらず」「〜を問わず」「汎用的」「プラガブル」「詳しく知らなくても使える」といったコンテクストで割と一般的なIT用語として利用されています。2010年頃は哲学的意味が強かったと思いますが、現在は先に書いたような意味で使われているケースが多くあります。
参考資料：
- セキュアプログラミングの７つ習慣
- エンジニア必須の概念 – 契約による設計と信頼境界線
- CERT Top 10 Secure Coding Standard
- 開発者は必修、SANS TOP 25の怪物的なセキュリティ対策
- セキュアプログラミング（防御的プログラミング）の歴史をざっと振り返る
セキュアプログラミング（防御的プログラミング）の歴史をざっと振り返る
キュアプログラミング（防御的プログラミング）の歴史をざっと振り返ってみたいと思います。セキュアプログラミングは防御的プログラミングとも言われるプログラミングの原則の１つ※です。古くからある概念ですが、誤解または理解されていない概念の１つではないでしょうか？
※ Defensive Programmingとして記載されています。
何故、一般に広く常識として理解されていないのか？その理由は防御的プログラミングの歴史にあるのかも知れません。
参考：
開発者はセキュリティ問題を自己解決できるのか？
ソフトウェア開発において開発者はセキュリティ問題を自己解決できるのか？それとも自己解決できないのか？どちらが正しいのか考えてみます。
間違いだらけのHTTPセッション管理とその対策
HTTPセッション管理はWebセキュリティの中核と言える機能です。Webセキュリティの中核であるHTTPセッション管理に設計上のバグがある事は少なくありません。今回のエントリはPHP Webアプリ開発者ではなく、主にWebフレームワーク側の開発者、つまりPHP本体の方に間違いがあるという話しです。Webアプリ開発者の回避策も紹介します。
まずセキュリティの基本として「入力のバリデーションを行い、正当な入力のみを受け入れる」があります。しかし、PHPに限らず多くのセッション管理機構は当たり前の「入力のバリデーションを行い、正当な入力のみを受け入れる」を行っていません。セッションIDの再生成（リセット）も不完全な物が多いと思います。
参考：
Webアプリの入力はバリデーションできない、という誤解
Webアプリの入力はバリデーションできない、と誤解している方は少なく無いようです。システム開発に関わる人でなければ誤解していても構わないのですが、システム開発者が誤解していると安全なシステムを作ることは難しいでしょう。
Webアプリの入力はバリデーションできない、と誤解している開発者にも理解できるよう噛み砕いて解説してみます。