OWASP Secure Coding Practices – Quick Reference Guideの訳語が不適切ではないのか？とメールを頂きました。
ブログにして見ていただく方が良いと思ったので公開します。
(さらに…)不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。
は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。
簡単な証明：プリペアードクエリ”だけ”では、識別子（カラム／テーブル等）を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ／バリデーションが必須。(問題はコレだけはありません）
似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。
https://blog.ohgaki.net/output-only-security-is-anti-practice
アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません。
参考：
セキュアプログラミングの啓蒙にも少々食傷気味ですが、今回もセキュアプログラミングの話題です。IPAのセキュアプログラミング講座Web編は削除予定であるとFacebookではお伝えしましたが、ブログではまだだったので合わせて紹介します。
ISO 27000がセキュアプログラミングついてどのように書いているのか紹介します。ISO 27000シリーズはISMS（Information Secuirty Management System – 情報セキュリティマネジメントシステム）認証の根幹となっている国際セキュリティ標準です。ISMS導入で自動的にセキュリティ問題に対応できる！といったモノではありませんが、体系的なセキュリティ導入にとても役立つ規格で2015年6月29日時点で４６４６組織の認証登録があります。
キュアプログラミング（防御的プログラミング）の歴史をざっと振り返ってみたいと思います。セキュアプログラミングは防御的プログラミングとも言われるプログラミングの原則の１つ※です。古くからある概念ですが、誤解または理解されていない概念の１つではないでしょうか？
※ Defensive Programmingとして記載されています。
何故、一般に広く常識として理解されていないのか？その理由は防御的プログラミングの歴史にあるのかも知れません。
参考：
ソフトウェア開発において開発者はセキュリティ問題を自己解決できるのか？それとも自己解決できないのか？どちらが正しいのか考えてみます。
まずエスケープ処理について全て書こう、ということでPHP Securityカテゴリで様々なエスケープ処理について書いてきました。しかし、「エスケープ処理とは何か？」を解説していなかったので解説します。
エスケープ処理は文字列処理の基本中の基本です。
「エスケープは要らない、知る必要もない」という意見を稀に聞きますが、プログラムに於ける文字列処理とその重要性を理解していないからでしょう。全ての開発者はエスケープ処理の必要性を理解し、確実かつ適切にエスケープできなければなりません。
(さらに…)