セキュリティ標準では入力データの妥当性確認（入力バリデーション）が要求されています。具体的な方法はBS 7799（英国のJIS規格のような物、2000年に国際標準化）が作られた時（90年代後半）から記載されており、前の版までのISO 270001にも記載されています。2013年版のISO 27000ではセキュアプログラミングが普及したので具体的な方法などは省略しています。（日本では普及していないような。。）
セキュアプログラミングの基本中の基本がセキュリティ対策ではない、というような意味が全く解らない議論もあるのが現状です。
かなり昔に似たようなことを書いたようにも思いますが、記憶が定かではありません。今でも有効なので改めて（？）ブログにします。
ホワイトリストの考え方／作り方は難しくありません。しかし、間違えていることが少なくないようです。
GoogleがCSP（Content Security Policy – ホワイトリスト型のJavaScriptインジェクション対策）の利用状況を調べたところ以下のような結果が得られました。
we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies.
なんと、約95%のCSP利用サイトがCSPの保護が無効になるような設定になっていた、としています。
PHP 5.6.25/7.010以降で修正されたセッションデータインジェクション
の解説です。
この脆弱性を利用するとオブジェクトインジェクションが簡単に行えます。結構深刻な問題ですが、あまり話題にはなっていないように思います。
クロスサイト・リクエスト（他のWebサイトから自分のサイトへURLリンクやPOSTでアクセスする）を制限したいWebアプリケーションは結構あります。例えば、ホームルーターの管理ページを作る場合、クロスサイト・リクエストは有用などころか有害です。ホームルーターの管理ページにはクロスサイト・リクエストによる脆弱性が多数報告されています。
PHPの基本機能を使えば、クロスサイト・リクエストを簡単かつ丸ごと拒否することができます。CSRFやXSS1を完全かつ簡単に拒否する仕組みを作れます。
RSSで購読されている方が結構いる（ありがとうございます！）のでエントリに追記したことをお知らせします。
このエントリの最後に「残存リスク」の項目を追加しました。
思っているより多くの残存リスクがあり、これらも考慮しなければならないことが解ると思います。
不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。
は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。
簡単な証明：プリペアードクエリ”だけ”では、識別子（カラム／テーブル等）を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ／バリデーションが必須。(問題はコレだけはありません）
似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。
アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません。
参考：
ソーシャルメディアフィンガープリントがまた話題になっているようです。ソーシャルメディアフィンガープリントとは何か？およびその対策です。
ソーシャルメディアに限らず、ログインをサポートしているサイトであれば、全て対象です。
PHPスクリプトを分析するツールをまとめたページの紹介です。
セキュリティ対策において対策が「根本的」な対策であるかどうか？はあまり重要ではないです。セキュリティ対策において重要なのは対策が「効果的」であるかどうか、が重要だからです。
この基本を押さえた上で、ソフトウェアの「根本的な対策」とは何かを考えてみます。
PHPのheader関数とheader_remove関数の注意点です。あまり使わないと思いますが、Set-Cookieヘッダーや他のヘッダーで注意しないと問題になります。普段はsetcookie関数でクッキーを設定していてたまたまheader関数でクッキーを設定した、という場合にheader関数とsetcookie関数の仕様の違いにより、思ってもいない結果になります。
このブログで利用しているセキュリティ関係のプラグインを紹介します。こういう情報はあまり公開しない方が良いのですが、本気の攻撃者の場合はプラグインファイルの存在を総当たりで検出すれば判ってしまいます。
このブログのURLをhttpからhttpsに変更しました。これにより、幾つかの情報1が参照できなくなるので記載しておきます。
ブログをWordPressに移行してから設定されたURLは自動的にhttpsにリダイレクトされます。
このブログでは移行前に「仕方ないので諦める」ことにしたのですが、サイトのhttps化を検討されている方はこれらの情報が直接参照できなくなる点に注意が必要です。
ブログをhttps化する際にFAQ的な箇所でハマってしまいました。詳しくは WordPress + HTTPS + リバースプロキシ = このページにアクセスする権限がありません を参照してください。
ソフトウェアの開発環境は通常の環境と違う対策が必要です。その理由は開発環境には
※モノにはコード／ライブラリ／ツール／アプリ／システム などがあります。
などがある為です。開発環境はその他の環境に比べ「とにかく危険なモノがいっぱい」です。
更に最近ではソーシャルコーディングが当たり前になり、他人が書いた未検証のコードがどんどん実行される状態も当たり前です。それも1つ2つのライブラリではなく、依存性から何百、場合によっては何千というライブラリなどが自動的にダウンロードされ実行されています。
これがどういう状況かというと「PCがやっと使えるくらいのユーザーが、インターネットからプログラムをダウンロードしまくって実行している状況」とあまり変わりません。
リバースプロキシ環境で結構ハマったのでブログにします。結論から書くと、WordPressのドキュメントに
Note: FORCE_SSL_ADMIN should be set before wp-settings.php is required.
wp-settings.phpを読み込む前にFORCE_SSL_ADMINは定義しなければならない、と書いてありますがSSL関係の設定は全てこれの前に書かないと動作しません。