ソフトウェアの不具合／脆弱性を無くすためには、出力先に対して無害であることを保障する出力対策が重要です。どんな出力でも3つの方法で無害化できます。 このブログでは基本として、セキュアコーディングの概念に基き説明しています。先ずはよくある入力対策と出力対策の区別がついていない誤りから紹介します。 参考：IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき…

バリデーション、と一言で言っても一種類／一箇所だけではありません。バリデーションには3種類のバリデーションがあります。 バリデーションは重要であるにも関わらず誤解が多い機能の筆頭だと思います。日本に限らず世界中でよくある議論に バリデーションはモデルで集中的に行うべきだ！ なのでコントローラー（入力）でバリデーションなんて必要ない！ モデル集中型バリデーショ…

数値の入力にはバリデーションは要らない、と考えているケースが少なからずあるようです。本当に数値に対するバリデーションは無意味なのでしょうか？ (さらに…)

まず結論から。タイトルの通り「出力対策だけのセキュリティ設計は設計ミス」です。 なぜ「出力対策だけのセキュリティ設計は設計ミス」なのか？ (さらに…)

「しっかり出力対策”だけ”するのがセキュリティ対策のベストプラクティス」とする考え方1があります。しかし、これはベストプラクティスどころかアンチプラクティスです。 アンチプラクティスをベストプラクティスと勘違いしている限り、満足のいくセキュリティ対策（＝リスク管理）は不可能です。セキュリティ対策は総合的なリスク対策です。「これ”だけ”やれば良い」とするセキュ…

セキュリティを考えると全ての入力データはアプリケーションがバリデーションすべきで、長さ／形式は厳格にバリデーションすべきです。1 厳格なバリデーションは開発者が意識／把握していない各種インジェクション脆弱性にも対応できること、インジェクション攻撃が持たらす被害が致命的であることが、その理由です。 適切なバリデーションは最強のセキュリティ対策の１つ2です。強い…

PHPにHKDF関数、hash_hkdf()が追加されましたが、そのシグニチャは褒められるモノではありません。 https://blog.ohgaki.net/php-hash_hkdf-insane-function-signature hash_hkdf()が脆弱なAPI仕様になってしまった主な原因は、開発者がハッシュ関数を利用して鍵を導出する場合に知っ…

PostgreSQLを使うならZFSで決まりです。数値で明らかです。ZFS以外を使うのは論外なくらいの性能差があります。 (さらに…)

追記：書き直しました。新しい方をご覧ください。 セキュアコーディングの原則1は「入力バリデーション」です。セキュアコーディングの原則1はソフトウェアセキュリティの一丁目一番地と言えるセキュリティ対策です。 入力バリデーションを第一のセキュリティ対策としているガイドライン： CERT Top 10 Secure Coding Practices OWASP S…

セキュアコーディングの原則1は「信頼できない入力を全てバリデーションする」です。この原則は国際情報セキュリティ標準でも当たり前の要求事項となっています。しかし、残念ながら「信頼できない入力を全てバリデーションする」が正しく実装されているアプリケーションはほとんどありません。 独自の定義や自分勝手なセキュアコーディング解釈をしているケースが散見されます。ここで…