PHPのheader関数とheaders_remove関数の注意点
PHPのheader関数とheader_remove関数の注意点です。あまり使わないと思いますが、Set-Cookieヘッダーや他のヘッダーで注意しないと問題になります。普段はsetcookie関数でクッキーを設定していてたまたまheader関数でクッキーを設定した、という場合にheader関数とsetcookie関数の仕様の違いにより、思ってもいない結果になります。
「セキュアコーディング方法論再構築の試み」を再構築してみる
セキュアコーディングに関して大きな誤解がある資料があったのでこのブログを書いています。
一つ前のブログは二つ以上の議論を理解しながら読まなければならないので解りづらい、とご意見を頂いたので”「セキュアコーディング方法論再構築の試み」を再構築してみる”として書き直してみました。
セキュアコーディングを理解できていない例
追記：解りづらい、とご指摘があったので「セキュアコーディング方法論再構築の試み」を再構築してみるとして書き直してみました。このエントリの方が詳しいですが、よろしければこちらもどうぞ。
セキュリティの専門家と呼ばれる人であってもセキュアコーディング／セキュアプログラミングを正しく理解していない例は散見されます。今回はそのケースを紹介します。
参考1：セキュアコーディングについて詳しくない場合、このブログを読む前にセキュアコーディング／セキュアプログラミングの歴史は理解しておた方が良いかも知れません。
参考2：そもそも、原理的／論理的に入力対策を無視／軽視したセキュリティ対策は誤りです。
参考3：前提知識として入力データには三種類しかなく、不正なデータはソフトウェアにとって百害あって一利無しのデータであることを知っている必要があります。
PHPの制限一覧
PHPには他の言語と同様に様々な制限があります。まとまった資料が見つからなかったのでまとめておきます。PHPの制限と言っても実行時間の制限のようにマニュアルに記載されているINI設定などは記載していません。
セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない？！
セキュアコーディング／セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。（※ 対策の目的が何か？などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません）
どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング／セキュアプログラミングのガイドラインなどがどうなっているのか？紹介します。
このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング／セキュアプログラミングとは何か？は過去のブログをご覧ください。
セキュアプログラミングの７つ習慣
セキュアなプログラミングには基本的な考え方があります。それ守ることによりセキュアなプログラムを作ることができます。基本的な考え方を無視または意識しないでセキュアなプログラミングを目指しても遠回りだったり、漏れが生まれたりします。基本的な考え方を無視・意識しないでセキュアなプログラミングを行おうとしても無理があります。
ここで紹介するのは私の考えであり、どこかで標準化されている物ではありません。しかし、基礎からまとめると概ね同じような物になると思います。
ほとんどのセキュリティ問題はインジェクション問題 – インジェクションパターンとして理解すると簡単
セキュリティ問題のほとんどはインジェクション問題と考えることができます。インジェクション問題として考えられるセキュリティ問題のモデル化を考えます。
実際のセキュリティ問題は多種多様で非常に複雑ですが、シンプルなモデルで考えると理解り易く、多くのセキュリティ問題を体系的に理解できます。
メソッド／関数呼び出しによるコード実行問題とその対策
言語の機能としてシリアライズされた”データ”からオブジェクトを生成（PHPの場合、unserialize関数）したり、呼び出すメソッド／関数を指定できる機能（PHPの場合、call_user_func関数／call_method関数など）を使ったりすると意図しないメソッド／関数が呼ばれるケースを想定しなければなりません。
ISO 27000とセキュアプログラミング
セキュアプログラミングの啓蒙にも少々食傷気味ですが、今回もセキュアプログラミングの話題です。IPAのセキュアプログラミング講座Web編は削除予定であるとFacebookではお伝えしましたが、ブログではまだだったので合わせて紹介します。
ISO 27000がセキュアプログラミングついてどのように書いているのか紹介します。ISO 27000シリーズはISMS（Information Secuirty Management System – 情報セキュリティマネジメントシステム）認証の根幹となっている国際セキュリティ標準です。ISMS導入で自動的にセキュリティ問題に対応できる！といったモノではありませんが、体系的なセキュリティ導入にとても役立つ規格で2015年6月29日時点で４６４６組織の認証登録があります。
個々の脆弱性に対応する効果的な方法
全体的なセキュリティ対策やセキュリティ対策の基本的概念の話が続いたので、個々の脆弱性に対応するための効果的な方法を紹介します。前提知識なく、個々の脆弱性に対応するには、個々の脆弱性全て知る必要があります。
セキュアなソフトウェアアーキテクチャー
セキュアなソフトウェアアーキテクチャーに関するプレゼンを公開しました。
http://www.slideshare.net/yohgaki/ss-49863218
これだけだと契約プログラミングがどういうモノなのかよく分からないと思います。
を参考にしてください。
ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション 〜 ただし出力対策も必須です 〜
入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか？を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか？
ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。
厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。
重要：セキュア／防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。どちらかをすれば良い、ではなく入力と出力の両方で対策を行います。よく誤解されるので注意してください。
重要 その2：ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。ホワイトリストによる入力バリデーションは”無害化”ではありません。”妥当性の検証”です。
重要 その3：あまり広く理解されていませんが、セキュアコーディングの第1原則は「全ての入力をバリデーションする」、第7原則が「全ての出力を（エスケープ／API／バリデーションで）無害化する」です。セキュアコーディングはISMS／PCI DSSなどの認証規格の要求事項です。
なぜこのようなブログを書いたか？というと入力バリデーションしていても、”ほぼ全てのインジェクション攻撃を無効化／防止できる入力バリデーション”でない場合、入力時のセキュリティ処理だけでは”残存リスク”としてインジェクション攻撃が可能になる、という事を理解して欲しいからです。
参考：
今時の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の怪物的なセキュリティ対策
- セキュアプログラミング（防御的プログラミング）の歴史をざっと振り返る