アプリケーション仕様とセキュリティ仕様の関係
アプリケーション（ソフトウェア）仕様とセキュリティ仕様の関係とその特徴は正しく理解しておく必要があります。この関係と仕様の特徴を正しく理解しておかないと根本的な部分での間違いにつながります。
SQLite3の全てのカラムがテキスト型である問題に対する誤解
以前にSQLite3のデータ型は基本的には全てテキスト（例外は整数型プライマリーキー ※）である、という解説をしました。
どうもこの問題は強い型を持っている言語には影響がないとの誤解があるようなので解説します。ついでに明らかだとは思いますが、他のリスクも紹介します。
※ 正確にはBLOB型も例外になります。テキストではないデータも保存できます。SQLiteのサイトでは整数型プライマリーキーは例外と記述されていましたが、手元のSQLiteで試すと文字列も保存できてしまいました。
参考：SQLite3のカラム仕様を理解している必要があります。
徳丸浩氏との長年の議論に終止符 – 論理的／体系的セキュリティとそれ以外
私が長年徳丸さんと議論していることをご存知の方も多いと思います。徳丸さんがなぜ論理的に矛盾する主張、明らかにセキュリティ標準規格／ベストプラクティスに反する主張を繰り返えしたのか、その理由が判明しました。それと同時に長年の議論に終止符が打たれ、徳丸さんの考えを完全に理解することができたと思われます。
徳丸さんがセキュリティ対策製品であるWAF（Web Application Firewall）を販売／推奨しつつ、アプリケーション側のファイアーウォールと言える「入力バリデーション」を「セキュリティ対策ではない」と主張されるのは、ジョブセキュリティやステスルマーケティングの類ではないのか？と思えるほどでした。アプリケーションがバリデーションしなければしないほどWAFの有効性は上がり、WAFが売れるでしょう。「WAFはセキュリティ対策」「アプリのバリデーションはセキュリティ対策ではない」としている方がWAFを売りやすいからです。
徳丸さんにもこのブログを書いたことを連絡し、もし誤解している部分があるのであれば反映したいと思います。これから紹介するように論理矛盾が明らかになった直後、今後議論をされないことを表明されましたが、この長いブログでも手法や論理的矛盾の誤りを指摘し尽くしていないので議論いたします。徳丸さん、反論を書かれるようであればご連絡ください。
追記：”原理／原則などに根拠がない”ことが判ったので議論することは無いのですが、IPAが誤りを正した後の2017年に間違ったセキュアコーディングを啓蒙されていました。これは指摘せざるを得ないのでブログに書きました。
科学的に出鱈目なセキュリティ対策で得をするのは、サイバー犯罪者とセキュリティ業者だけす。
TL;DR;
論理的思考で導ける必要条件と十分条件を理解している方にはここで解説している内容は読まずとも理解されていると思います。
Memcachedのプロトコル仕様とセキュリティ – Memcachedでもインジェクションが可能
Memcachedはテキストプロトコルとバイナリプロトコルの二種類を持っています。デフォルトはテキストプロトコルです。テキストプロトコルを利用している場合、テキストインターフェース処理の基本を理解した上で利用しないとセキュリティ問題が発生します。こういった処理のセキュリティ対策を行う、確認するには実は標準の方が簡単で明解 – セキュリティ対策の評価方法も参考になります。
Memcachedはキーバリュー型なのでSQLインジェクションのような脆弱性とは無縁、と思っていた方は是非読んでみてください。
実は標準の方が簡単で明解 – セキュリティ対策の評価方法
なぜセキュリティ対策の区別が異なるのか？長年疑問だったのですが、その理由の一つが判りました。
以下は、本質的には似たような入力確認である「WAFはセキュリティ対策」で「入力バリデーションはセキュリティ対策ではない」のか？と質問した時のツイートです。
@yohgaki どちらもセキュリティ上効果がありますが、WAFはセキュリティを主目的として、というよりセキュリティのためだけに導入するのに対して、バリデーションはセキュリティが *主目的ではなく* 元々実施すべきものだという主張です
— 徳丸 浩 (@ockeghem) February 6, 2015
どうも「目的」がセキュリティ対策であるか否か、の基準のようです。「セキュリティ対策の定義」が曖昧という問題もありますが、ここでは省略します。
IoT時代のセキュリティ対策に必須 – ISOでも定義する入力バリデーションの方法
項目を切り出して独立したブログエントリにしておく方が良いと思い書きました。IoT時代（IoT時代でなくてもですが）に最も必要なセキュリティ対策は厳格な入力バリデーションです。
- IoTソフトウェアのバージョンアップは非常に困難、不可能である場合も多い
- ソフトウェアには未知の危険性が存在している
セキュリティ対策としの入力バリデーションはIoTでは更に厳格に行う必要があります。
IoT時代のセキュリティ対策として入力バリデーションが強化が必要なのは、クラウドやレンタルサーバーサービスでWAFを導入する必要性が高いことと同じ理由です。これらのサービス業者はIoTと同様にソフトウェアをバージョンアップすることが非常に困難です。入力バリデーションを強化するのはソフトウェアのバージョンアップより更に困難です。このため、効率悪くや確実な防御が困難なWAFであっても導入しているサービスが多いです。
IoTデバイスを作る場合、非常に厳格な入力バリデーションを行うべきです。
参考：Onion Omega
本来、現在のISO 27000を紹介するべきですが元のブログは敢えて古い標準を使いたかったのでISO 17799を紹介しています。基本的な部分は変わっていません。
ニュートン力学と相対性理論 – エンジニアに見られるセキュリティ対策理解の壁
以前からセキュリティ対策の本質や定義について何度かブログを書いたり、講演もしてきましたがなかなか理解できない方も多かったです。その構造は
ニュートン力学と相対性理論の理解の壁
これと似ているのでは？と思い書き始めました。「エンジニアのセキュリティ対策理解の壁」は「ニュートン力学と相対性理論の理解の壁」と同類ではないでしょうか？
特に入力バリデーションはセキュリティ対策の基本ではない、と勘違いしている方は続きをご覧ください。
ホスト名バリデーションのやり方
徳丸さんのブログで私のブログ「GHOSTを使って攻撃できるケース」にコメントがあったようなので、好ましいホスト名バリデーションの方法を書いておきます。
特定の低レベルAPIのバグが10年ほど前に書いた本のコードで対応できていない、と議論するのもどうかと思いますがしっかりチェックする場合の例を書いておきます。