危険な脆弱性であっても名前を付けないとなかなか認知してもらえない、といったことがよくあります。「データ検証をしないアプリ仕様」は危険で脆弱な仕様ですが、基本的な対策を実装しない危険性はあまり認知されてないと思います。例えば、とんでもないGDPR制裁金を支払うといったリスクが高くなります。
名前が必要なのかも知れません。
実は新しく考えなくても既にOWASPが名前を付けています。
OWASP TOP 10 A1:2004 Unvalidated Inputとして第一番目の脆弱性として挙げています。
2007年版から消えていますが、これはセキュアコーディングとの兼ね合いで省略したのだと思われます。「2007年版から消えているので脆弱性ではなくなったのだ」とする自分勝手な解釈の解説を目にしたことがありますが、その2007年版には「リストから消したが変わらず重要な対策で、本年度版の脆弱性対策の手法としても記載」とする解説が書かれています。
標準的なセキュリティ対策の概念では「入力データ検証は非常に重要な脆弱性対策」です。
(さらに…)ソフトウェアにバグがあった場合、そのバグは”ただのバグ”で”単純に意図しない余計な動作をする箇所を直す”、で万事OK！でしょうか？
ここでは”ただのバグ”とは”問題が起きた時に問題が起きた箇所を直せばOK”なバグとして話を進めます。
(さらに…)インターネット上に16億件の企業ユーザーのメールアドレスとパスワードが公開されている、とニュースになっています。ほとんどの漏洩元はこれらの企業ではなく、他の一般公開されているWebサービスなどのアカウント情報漏洩※だと考えられています。
この事例から、非常に多くのWebサービスが情報漏洩を伴うセキュリティ問題を抱えているにも関わらず、気がつくことさえも出来ていないという現状があると考えるべきでしょう。（もしくは気付いていても公開していない）
侵入されたことを検知／対応する技術の導入も重要ですが、ここではなぜWebセキュリティはここまでダメになっているのか？を考えます。
※ 情報漏洩にはベネッセのケースのように内部の人による持ち出しも含まれていますが、外部の攻撃者が盗んだ情報も少なくないと考えるべきでしょう。
(さらに…)今のプログラムに足りないモノでセキュリティ向上に最も役立つ考え方のトップ2つ挙げなさない、と言われたらどの概念／原則を挙げるでしょうか？
私なら
を挙げます。
極論すると、この2つ知って実践するだけでセキュアなソフトウェアを作れるようになるからです。この2つだけでは十分ではないですが、これを知って、実践しているだけでも開発者は今のコードより段違いにセキュアなコードが自分で書けるようになります。
もう一つ追加するなら
を加えます。これはゼロトラストとフェイルファーストから導き出せる概念です。ゼロトラストとフェイルファーストで検証を行うと自然と多層防御になります。多層防御はセキュリティ対策の基本ですが、特にソフトウェアでは実践されている、とは言えない状況です。
これら3つはとても有用な概念で単純明解な概念ですが、知られていなかったり、誤解されていたりすることが多い概念／原則と言えるかも知れません。
(さらに…)コード”だけ”に着目すると脆弱性が量産されます。それはコードだけでは片手落ちであることが理由です。
言い換えると
プログラムの目的は「特定の機能」をコードによって実装することが目的ですが、動作する為には「データ」が欠かせません。
「データ」にも着目するとソフトウェアセキュリティは向上します。今実装されているソフトウェアセキュリティ対策は「コード（機能）」に偏重しているために脆弱になっています。
例えば、JSONPが危険な理由は「本来データであるJSONをプログラムとして実行している」ことにあります。
https://blog.ohgaki.net/stop-using-jsonp
X-Content-Type-Options: nosniff を指定するのは「本来データであるJSONをJavaScriptとして実行させない」ようにすることを目的です。X-Content-Type-Options: nosniff の導入は「データ」に着目したセキュリティ対策と言えます。「データ」として完全に分離し、「コード」として実行できないようにします。
開発者の多くはソフトウェアセキュリティを考える際、「どのようなコードで攻撃を防止するのか？」を考えていると思います。これだけでは何時まで経っても信頼性が高い（＝セキュアなソフトウェア）物は”原理的”に作れないです。
※ 「コードだけに着目するセキュリティ対策」とは「攻撃が発生する箇所（コード）だけに着目するセキュリティ対策」を指しています。
入力の種類には3種類以上の種類、名前、電話番号、住所など沢山の種類があります。しかし、見方によってはたった3種類しかありません。この区別ができる／できない、で大きな違いができてしまいます。
入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか？を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか？
ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。
厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。
重要：セキュア／防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。どちらかをすれば良い、ではなく入力と出力の両方で対策を行います。よく誤解されるので注意してください。
重要 その2：ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。ホワイトリストによる入力バリデーションは”無害化”ではありません。”妥当性の検証”です。
重要 その3：あまり広く理解されていませんが、セキュアコーディングの第1原則は「全ての入力をバリデーションする」、第7原則が「全ての出力を（エスケープ／API／バリデーションで）無害化する」です。セキュアコーディングはISMS／PCI DSSなどの認証規格の要求事項です。
なぜこのようなブログを書いたか？というと入力バリデーションしていても、”ほぼ全てのインジェクション攻撃を無効化／防止できる入力バリデーション”でない場合、入力時のセキュリティ処理だけでは”残存リスク”としてインジェクション攻撃が可能になる、という事を理解して欲しいからです。
参考：
「攻撃者がどうやって脆弱性を見つけ攻撃するのか」これは比較的よくセキュリティ対策で解説されていることだと思います。本質を理解し、対策を考えます。
