以前から気になっては居たのですがJVNのCWE-20の解説ページが出鱈目です。用語の定義が間違っています。もう何年も前から修正されていません。Draftとは言え「セキュアコーディングの第一原則」（IPAは2017年からプログラミング原則としている）入力データバリデーション・入力妥当性チェックの用語定義が間違っているのは致命的な間違いです。
このブログ最後に記載の通り、メールにて誤りを指摘していました。最初のJVNへのメールから3週間かかりましたが指摘した通りに修正されました。
標準的な入力バリデーション（入力の妥当性チェック）にはエスケープやフィルタリング、脆弱性を隠すという意味はありません。入力データが形式的に妥当であることを検証するのが入力データバリデーションです。これは70年代のFormal Verificationの頃からの定義です。
近年になって乱用／誤解／拡大解釈により間違った意味で使われている場合があるので注意が必要です。
もっと読むGigagineで比較的珍しいバグが見つかったことを記事にしています。
「％p％s％s％s％s％n」というSSIDのネットワークに接続すると、iPhoneのすべてのWi-Fi関連機能が無効になってしまう
https://gigazine.net/news/20210620-specific-network-name-disable-wi-fi-iphone/
「セキュリティって難しいんだな」と感じるニュースではなく「大手でも基本が出来てないんだな」と思えれば、似たような問題で困ることが無くなります。
もっと読むJSONPathはCSSのセレクタやXPathのクエリのような形でJSON形式のデータを選択／クエリする仕様です。最近のRDBMSはJSONPathクエリをサポートしているので、SQLインジェクション対策の一種として必要となる場合もあります。
JSONPathの説明はしないので仕様などはオンラインの評価環境で確認してください。
JSONPathクエリは上記のような”意味を持つ文字”を使ってクエリを実行します。インジェクション攻撃は一文字でも意味がある文字があると攻撃される、と思って構わないです。JSONPathクエリもインジェクション攻撃が可能です。
もっと読むCWE-20とは何か？と聞かれて即答できる開発者は多くないと思います。そもそもCWEとは何か？もあまり知られていないかも知れません。
実はCWE-20 不適切な入力バリデーション はソフトウェアセキュリティで最も重要な脆弱性とされています、CWEのみでなく情報セキュリティ標準的に情報セキュリティ関連法的にも。
※ CWE: Common Weakness Enumeration (共通脆弱性タイプ)
CWEは脆弱性識別子のCVEで有名なMITRE（米国でのIPAの様な組織）が管理するソフトウエア脆弱性パターンを列挙したドキュメント／データベースです。日本語名の通り、よくある共通のソフトウェア脆弱性を集めた物がCWEです。
もっと読むプログラムのコードを書く場合1文字でも間違えると致命的な問題になる事がよくあります。=< であるべき所を < で条件分岐すると困った事になります。何を当たり前の事を言っているのだ？と思うでしょう。プログラマには常識です。プログラマーは1文字も間違いがないコードを書くために懸命にコードを書いています。
しかし、プログラムでデータを処理する場合1文字でも正しく取り扱うことができないモノが含まれると正しく動作できない、これは常識でしょうか？それとも非常識でしょうか？プログラマは自分が書いたコードに正しく処理可能なデータであることを保証するコードに（データを検証するコードを記述）しているでしょうか？入力データの検証はアプリケーションでは必須ですが検証できているでしょうか？
もっと読むバリデーション、と一言で言っても一種類／一箇所だけではありません。バリデーションには3種類のバリデーションがあります。
バリデーションは重要であるにも関わらず誤解が多い機能の筆頭だと思います。日本に限らず世界中でよくある議論に
があります。どこかで見た事があるような議論ですが、世界的にこのような考えの開発者が多いことは、この入力バリデーション用のPHP拡張モジュールを書いた時の議論で分かりました。1PHP開発者MLで議論したのですが、紹介したような議論をした方が少なからず居ました。少し続くとすかさず「そもそもActiveRecordパターンでないモデルも多数あるし、ActiveRecordパターンのモデルだけのバリデーションだと遅すぎ、その間に実行させる機能が悪用されるケースは山程あって、しかもそれが奥深いライブラリのどこで起きるか分らんだろ」的なツッコミがあるところは日本での議論とは異なった点です。
実際、多くのWebアプリケーションフレームワークは入力バリデーション機能をデフォルトでは持たず、アプリケーションレベルでの入力バリデーションを必須化していません。開発者が上記のような考えになっても当然と言えるかも知れません。しかし、必要な物は必要です。何故？と思った方はぜひ読み進めてください。
流石にこの時の議論ではありませんでしたが、以下の様な議論も見かけます（ました）
全てセキュアなソフトウェア構造を作るには問題がある考え方です。最後の「入力バリデーションはソフトウェアの仕様でセキュリティ対策ではない！」とする考え方の問題点は”セキュリティ対策の定義” 2セキュリティ対策＝リスク管理、にはリスクを増加させる施策も含め、定期的にレビューしなければならないです。（ISO 27000／ISMSの要求事項）リスクを増加させる施策、例えば認証にパスワードを利用など、は定期的にレビューしその時々の状況に合ったリスク廃除／軽減策をタイムリーに導入しなければならない。リスク増加要因を管理しないセキュリティ対策＝リスク管理は”欠陥のある管理方法”です。 を理解していないと問題点は見えないかも知れません。
このセキュリティ対策の定義はISO 27000／ISMSの定義をまとめたモノです。
何事も原理と基本が大切です。基礎的な事ですがプログラムの基本構造と動作原理を正しく理解しておく必要があります。
入力対策と出力対策は両方必要でバリデーションはセキュアなソフトウェア構築には欠かせません。
アプリケーションの入り口で入力バリデーション（入力検証）をしていないアプリはセキュアでない構造です。
入り口以外に入力検証がないアプリもセキュアではない構造です。セキュアなアプリには最低限、入り口でのデータ検証と出口でのデータ無害化（エスケープ／無害化API／バリデーション）が必須です。
多層防御 3ソフトウェアに限らずセキュリティは多層で防御します。必ず必要な対策と無くても大丈夫なハズの対策（フェイルセーフ対策）の2種類がある。フェイルセーフ対策は万が一の対策であり、本来フェイルセーフ対策は動作してはならない。動作した場合はプログラムに問題がある。「動作してはならない」は「必要ない」ではない。実用的なプログラムは複雑であり失敗してしまうケースは十分にある。入力バリデーションが甘い／無いプログラムだとフェイルセーフ対策が機能してしまうことは当たり前に起きる。 は重要なのに勘違いされているソフトウェアセキュリティ要素の１つです。
バリデーションには3つの種類があります。
※ 出力時のエスケープ／エスケープが不必要なAPIの利用によるデータの無害化は、必須の対策が半分、フェイルセーフ対策が半分です。
※ “入力ミスの確認”を”バリデーション”と考えたり、言ったりすると混乱の元です。”入力ミス／論理的整合性の確認エラー”は処理の継続、”あり得ないデータによるバリデーションエラー”では処理の中止、が必要なので区別する方が良いです。
※ ソフトウェア基本構造の入力処理では”あり得ないデータによるバリデーションエラー”、ロジック処理では”入力ミス／論理的整合性の確認エラー”、になります。
※ リスク分析の経験があれば自然にセキュアな構造を思い付くことも可能だと思います。
イメージ図：
参考：データもコードも一文字でも間違い／不正があるのはNG
コンピューターサイエンス・システムエンジニアリングに基づくソフトウェアセキュリティ対策は論理的に構築されており問題ないです。しかし、一般に広まっているソフトウェアセキュリティ対策には出鱈目が普通にまかり通っています。
その最たる例はCWE-20の出鱈目な紹介や解釈です。
Terminology
The “input validation” term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships.
Some people use “input validation” as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean “checking if an input conforms to expectations without changing it.” CWE uses this more narrow interpretation.
太字部分の訳
他の人々はより狭いコンテクストで”変更しなくても入力が期待に沿うモノかチェックすること”の意味で使用する。CWEはこの狭い意味の解釈を採用している。
このように現在の本家CWE-20の用語補足では「”変更しなくても入力が期待に沿うモノかチェックすること”の意味で使用」と明記されていますが、CWE-20にエスケープやフィルタリングが含まれる、とする驚くべき解説をする”セキュリティ専門家”が居たりします。（普通は「CWEはこの狭い意味の解釈を採用している」と注釈なくてもそれ以前に解説の文意で判る）
もっと読む非エンジニアのユーザーに現在のほぼ全てのWebサーバーは送信されてくるデータが妥当かどうか確認していない、と説明すると驚きます、「そんな仕組みでマトモに動くソフトウェアが作れるのか？」と。当然の疑問でしょう。
実際、コンピュータサイエンス・システムエンジニアリングの世界では一貫して入力データの妥当性検証を重要なセキュリティ対策として実装するように求めています。
現在のISO 27000ではセキュアプログラミング技術の採用を要求しています。セキュアプログラミングで最も重要な事は入力データバリデーションです。2013年にISO 27000が改定されるまで、入力データバリデーションだけは具体的な仕様が解説されていました。2013年の改定で普及したので「セキュアプログラミングを採用する」と簡易にされました。（ハンドブックではないJIS Q 27000:2014の冒頭の改定の経緯解説に書かれています）
もっと読むPharファイルは複数のPHPスクリプトをアーカイブ＆パッケージ化して一つのファイルでアプリケーションとして実行する仕組みです。
PharファイルはPHPプログラムその物なのでこれを実行してしまうとPHPで実行できることは何でもできてしまいます。そもそもPharファイルはプログラムなので信頼できないPharファイルを実行したらやりたい放題なのに、なぜPharのデシリアライズがセキュリティ問題になるのか？解説します。
もっと読むインジェクション攻撃、とは言ってもそのインジェクション対象によって影響が異なります。インジェクション攻撃の対象によって2種類、コードとデータ、に分類できます。Webシステムの場合、リクエストのインジェクションを別のインジェクション攻撃と考えた方が解りやすいので、大まかに分類して3種類に分類できます。
インジェクション脆弱性は絶対に避けなければならない脆弱性である、と認識されていると思います。しかし、3種類あるインジェクション攻撃のうちデータのインジェクションに対するリスク認識が極端に甘いように感じています。
※1 Webシステムを前提としていますが、大抵のシステムは「コード」と「データ」のインジェクションを考慮すれば十分である場合が多いです。
※2 そもそもコードを実行する機能そのものに”コード”を実行させるのは”正当な機能”です。eval( $_GET[‘code’] ) など、これらの機能の基礎的使い方間違いは考慮しません。ここでは本来コードではないデータを介するコードインジェクション、例えば eval( ’var = ‘. $myvar. ‘;’) など、及び、データその物で攻撃するデータインジェクションを取り上げています。
前のエントリで
本当かどうか知らないのですが「マウスでぐるぐるポインタを回しているとPCが速く動作する」と言うバカバカしいと思われる知識
と書いたのですが、divineさんから「Word の「印刷」を劇的に速くする方法を発見。ホイールを上下するだけ!」と言うブログへのリンクを教えていただきました。（divineさん、ありがとうございます）「マウスをぐるぐるして高速化」はバカバカしいように思えるのですがマウスホイールを回すと実際に速くなる場合もあるようです。以下が速くスプールできる理由の推測です。
ご存知の様にWindows95より前（Windowsは3.1まで）はコーポレイティブ（非プリエンプティブ）なマルチタスク（アプリが自分で処理をOSに返す）でした。MS Officeの開発は少なくともWindows 3.xの頃（Windows 3.1上でOffice 4.xを実際に使っていました。実際の開発ルーツはもっと前でしょう）までさかのぼれますが、Wordの印刷処理をバックグラウンドで行うには現在のようにスレッドを作ってOSに任せる事が出来ませんでした。昔のアプリケーションではバックグラウンド処理を行うには擬似的にスレッドを実行するような感じのコードを書く必要がありました。この擬似スレッドの様に動作するコードのためにイベントが発生するたびに、より速いタイミングでバックグランド処理が行われる仕様となってしまったアプリケーションができたのだと思います。Wordのスプールの場合、再描画のスレッドとスプール処理が関連している（リンク先（Word の「印刷」を劇的に速くする方法）を参照）ためマウスのホイールを動かしてスクロールさせると速くスプール出来てしまう動作（仕様）になってしまったようです。
# 今のOfficeならこんなコードを捨てて普通にスプール用の
# スレッド作るだけで劇的にスプールが速くなると思います。
# 推測ですが。
とにかく「マウスでぐるぐる回しているとPCが速く動作する」というノウハウは100%嘘ではなく、一部では本当に処理が高速化できる！という事は書いておなければと思いここに書いています。（注：とは言っても単純に「マウスポインタだけ」をぐるぐるしているだけでは処理は速くなりません）
さて、マウスやキーボードを使っていると処理が速くなるケースはUNIXでもありえます。/dev/randomはマウスやキーボードなどからの入力を乱数生成に利用しているので一部のアプリケーション（特に強度が強い暗号処理）で乱数のシード待ち状態が発生する事があります。このような場合にはマウスポインタをぐるぐる回すと結果として処理が早く完了します。
Windowsだけでなく昔のMac OSもWindowsと同様にコーポレイティブマルチタスクでした。探してみればWindows、Mac OSがコーポレイティブマルチタスクだった頃の名残りで「マウスを動かしている（イベントを発生させている）と処理が速くなる」ケースは結構沢山あるのかも知れませんね。
マウスぐるぐるでアプリケーションの動作が高速化する場合が他にもあるでしょうか? もしご存知の方、是非教えてください。
PHP文字列をテキストとして出力したい場合もあります。PHPの文字列型はバイナリセーフなのでどのようなデータでも保存可能ですが、プログラム中でPHP変数をPHPのテキスト（リテラル）として出力するにはaddslashes()によるエスケープ処理が必要です。
【重要】エスケープ／API／バリデーション1は出力先に合った方法でないと意味がないです。一口にHTMLと言っても複数の”コンテクスト”があります。
があります。
SQLクエリと言っても
などがあります。全てのテキストインターフェースにコンテクスト2があります。
それぞれの”コンテクスト”に適切なエスケープ／API／バリデーションを利用しなければ意味がありません。
Fedora 33にアップグレードした時にも直したのですが、Fedora 34でも同じように今まで使えていたネットワークプリンタがアップグレード後使えなくなりました。
デフォルトのnsswitch.conf設定だとmDNSを参照しないで名前解決する事が原因。
もっと読むFedora34になりGnome40になった事により、今まで縦スライドで仮想画面がスライドしていたの横スライドする仕様（WindowsやMacOSと同じ）になりました。
これがどうにも使いづらい。今の横長モニターなら「これでしょ？！」と思います。
VMwareゲストのFedora 33が起動しなくってしまい直す事にしました。原因は今一つ判っていないのですが、ホストのFeodra 33のカーネルに外れがありシステムが連続してフリーズしたりことがあります。恐らくこれが原因でしょう。
どうせテスト用なので再インストールでも良かったのですが、直せる物は直すということで直しました。
もっと読む