PHP7で追加される整数型、浮動小数点型タイプヒントの問題点
PHP7では整数型、浮動小数点型、配列型のタイプヒントが追加されます。データ型をより厳格に取り扱うようになるのは良い事ですが、データ型を変換してしまうため問題となる場合もあります。
データ型は指定した型に変換すればよい、という単純な物ではありません。私はデータ型を変換しない方のRFCを支持していました。残念ながらこちらのRFCでなく、問題が多い方のRFCが採用されることになりました。
参考
安全なAPI過信症候群 – 普通のRDBMS編
昨日書いた安全なAPI過信症候群の処方箋 – execv/SQLite3編はSQLiteの仕様がRDBMSとしてエキゾチック過ぎて、さらっと書いたよくあるRDBMSでの「安全なAPI過信症候群」を全く理解して頂けなかったケースもあるようなのでもう一度書きます。
プリペアードクエリには色々問題もあり、セキュリティ対策としてそれだけ教えるのはNG、と考えている方はプリペアードクエリ過信症候群ではないので、このエントリを読む必要はありません。
開発者はセキュリティ問題を自己解決できるのか？
ソフトウェア開発において開発者はセキュリティ問題を自己解決できるのか？それとも自己解決できないのか？どちらが正しいのか考えてみます。
知らないと勘違いする「合成の誤謬」の罠
今回は情報技術者にも役立つ経済学の用語を紹介します。多くのWebアプリケーション開発者、もしかすると他の技術者も知らない合成の誤謬です。「合成の誤謬」（ごうせいのごびゅう）とはもともとは経済学用語で、以下のように定義されています。
《 fallacy of composition 》個人や個々の企業がミクロの視点で合理的な行動をとった結果、社会全体では意図しない結果が生じること。例えば、企業が経営を健全化するために人件費を削減すると、個人消費が減少し、景気の低迷を長引かせる結果となることなど。
注：誤謬（ごびゅう）とは「誤り」「間違い」を意味する言葉です。解りやすく書くなら「合成の誤り」です。あまり一般的な用語ではないと思いますが、経済学用語なのでそのまま使っています。
攻撃者が”嫌う”セキュリティ対策とは何か？
「攻撃者が”嫌う”セキュリティ対策＝効果的なセキュリティ対策」です。これに異論は無いと思います。
攻撃者が最も困るセキュリティ対策とは何でしょうか？それは境界防御です。なぜ境界防御が攻撃者が最も困るセキュリティ対策なのでしょうか？それはCWEやCVEを見ればわかります。CWEやCVEに登録されている脆弱性の多くが、境界防御で守れるからです。
情報セキュリティの概念・用語
基礎、基本が大切です、とブログに書いてきました。しかし、情報セキュリティを語る上で最も基礎的と言える情報セキュリティの概念について、まだ書いていません。今日は情報セキュリティの用語の定義、概念を紹介します。
用語の定義、概念レベルで認識の違いがあると、コミュニケーションはなかなか成り立ちません。情報エンジニアは次々に現れる新技術や日々の業務に追われ、情報セキュリティの概念について学ぶ機会はなかったと思います。一般の教育機関は勿論、情報セキュリティ教育・対策を専門で行う組織であっても目の前にある個々の脆弱性対策教育に追われ概念の解説を行えない状況でしょう。
この結果、異なるITセキュリティの概念が幾つも生まれ、コミュニケーション自体が難しくなっている状況にあると思います。特に情報セキュリティ対策の定義は重要であるにも関わらず、あまり浸透していないように思えます。このエントリが少しでもこの状況を改善する一助となれば幸いです。
もっと読む
サニタイズは絶対的な悪か？
いつも堅苦しく「こうするほうが良い」とばかり書いているので、たまには「あまり良くない」と言われているセキュリティ対策も、有用かつ必要である例を紹介します。サニタイズの話です。
サニタイズ（Sanitize）とは消毒、汚れた物を綺麗にする事を意味します。汚れた物、つまり悪い物を除去・変換して綺麗にする処理がサニタイズ処理と言われています。悪い物を定義し排除する典型的なブラックリスト型の処理です。ブラックリスト型の処理を行うと「悪い物」の指定に「漏れ」が発生しやすく、間違いの元なのでセキュリティ処理では基本的に使わないことが推奨されています。
「サニタイズはするな！」これはほとんどの状況でサニタイズしない方が安全になる可能性が高くなるので正しいと言えます。しかし、これは全ての状況で正しいでしょうか？
そもそもエスケープとは何なのか？
まずエスケープ処理について全て書こう、ということでPHP Securityカテゴリで様々なエスケープ処理について書いてきました。しかし、「エスケープ処理とは何か？」を解説していなかったので解説します。
エスケープ処理は文字列処理の基本中の基本です。
「エスケープは要らない、知る必要もない」という意見を稀に聞きますが、プログラムに於ける文字列処理とその重要性を理解していないからでしょう。全ての開発者はエスケープ処理の必要性を理解し、確実かつ適切にエスケープできなければなりません。
もっと読む
エスケープファースト、この順序は変えられない
アプリセキュリティ対策の根本的なセキュリティ対策は教育です。セキュリティ対策を教育する場合、エスケープファースト（エスケープを一番）にすると最も高い効果を期待できます。汎用性もあり、自己解決する能力も付きます。
エンジニア必須の概念 – 契約による設計と信頼境界線
少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。
契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。
もっと読む
入力バリデーションはセキュリティ対策の基本
徳丸さんとはホワイトリスト VS ブラックリストの議論から楽しく話をしています。私はホワイトリスト型で対処する方がよりセキュアであると考え、徳丸さんはブラックリストも変わらない。としています。考え方が反対なので楽しいのです。残念ながらあまりブログなどに時間を取りなくないのですが、わざわざ徳丸さんがブログを書いた、とツイッターで教えていただいたので簡単に返信しておきます。
http://tumblr.tokumaru.org/post/55587596019
私は「バリデーションはセキュリティ対策とは言えない」と思っているのですが、実は「世界の常識」という点に異論があるわけではなくて、話は逆なのです。「従来からバリデーションはセキュリティ対策としてとらえられてきて『世界の常識』となっているが、実はそれはおかしいのではないか?」という問題提起をしているのです。なので、「世界の常識だろ」と言われても、それでは反論になっていません。
結論からいうと入力パラメータのバリデーションは世界のセキュリティ専門家によって非常に有用なセキュリティ対策だと認められています。
ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
参考：プログラムが正しく動作するには、正しい「データ」と「コード」両方が必須。データのバリデーション（＝セキュリティ対策）がない対策はあり得ない。