プログラムのコードを書く場合1文字でも間違えると致命的な問題になる事がよくあります。=< であるべき所を < で条件分岐すると困った事になります。何を当たり前の事を言っているのだ？と思うでしょう。プログラマには常識です。プログラマーは1文字も間違いがないコードを書くために懸命にコードを書いています。
しかし、プログラムでデータを処理する場合1文字でも正しく取り扱うことができないモノが含まれると正しく動作できない、これは常識でしょうか？それとも非常識でしょうか？プログラマは自分が書いたコードに正しく処理可能なデータであることを保証するコードに（データを検証するコードを記述）しているでしょうか？入力データの検証はアプリケーションでは必須ですが検証できているでしょうか？
もっと読むコンピューターサイエンス・システムエンジニアリングに基づくソフトウェアセキュリティ対策は論理的に構築されており問題ないです。しかし、一般に広まっているソフトウェアセキュリティ対策には出鱈目が普通にまかり通っています。
その最たる例は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の冒頭の改定の経緯解説に書かれています）
もっと読む以前から気になっては居たのですがJVNのCWE-20の解説ページが出鱈目です。用語の定義が間違っています。もう何年も前から修正されていません。Draftとは言え「セキュアコーディングの第一原則」（IPAは2017年からプログラミング原則としている）入力データバリデーション・入力妥当性チェックの用語定義が間違っているのは致命的な間違いです。
もっと読むPharファイルは複数のPHPスクリプトをアーカイブ＆パッケージ化して一つのファイルでアプリケーションとして実行する仕組みです。
PharファイルはPHPプログラムその物なのでこれを実行してしまうとPHPで実行できることは何でもできてしまいます。そもそもPharファイルはプログラムなので信頼できないPharファイルを実行したらやりたい放題なのに、なぜPharのデシリアライズがセキュリティ問題になるのか？解説します。
もっと読むFedora34になりGnome40になった事により、今まで縦スライドで仮想画面がスライドしていたの横スライドする仕様（WindowsやMacOSと同じ）になりました。
これがどうにも使いづらい。今の横長モニターなら「これでしょ？！」と思います。
Fedora 33にアップグレードした時にも直したのですが、Fedora 34でも同じように今まで使えていたネットワークプリンタがアップグレード後使えなくなりました。
デフォルトのnsswitch.conf設定だとmDNSを参照しないで名前解決する事が原因。
もっと読むVMwareゲストのFedora 33が起動しなくってしまい直す事にしました。原因は今一つ判っていないのですが、ホストのFeodra 33のカーネルに外れがありシステムが連続してフリーズしたりことがあります。恐らくこれが原因でしょう。
どうせテスト用なので再インストールでも良かったのですが、直せる物は直すということで直しました。
もっと読む訳あってCentOS7にPostgreSQL 8.2をインストールしようとするとコンパイルは出来ても動作しませんでした。8.2はかなり古いPostgreSQLなので仕方ないですが、動作させることは可能でした。
CentOS6ならPostgreSQL 8.2を普通にコンパイルできると思います。
もっと読むプログラムからCSSファイルにデータを書き込む場合、エスケープしないと不正なCSSになってしまう場合があります。現在のブラウザはCSSでプログラムを実行する仕様が削除されているのでコード実行脆弱性の問題になりませんが、不正なCSSはセキュリティ問題（クリックジャック等）になる場合もあります。
HTML内のCSSの場合、エスケープしないとJavaScriptの実行を許してしまいます。HTMLエスケープでJavaScript実行は防げますが、不正なCSSのインジェクションを防ぐにはCSSエスケープが必要です。適切に処理しないとCSSキーロガーを仕込まれて情報を盗まれたりします。
もっと読むJSONPathはCSSのセレクタやXPathのクエリのような形でJSON形式のデータを選択／クエリする仕様です。最近のRDBMSはJSONPathクエリをサポートしているので、SQLインジェクション対策の一種として必要となる場合もあります。
JSONPathの説明はしないので仕様などはオンラインの評価環境で確認してください。
JSONPathクエリは上記のような”意味を持つ文字”を使ってクエリを実行します。インジェクション攻撃は一文字でも意味がある文字があると攻撃される、と思って構わないです。JSONPathクエリもインジェクション攻撃が可能です。
もっと読むWebアプリケーションを作っているとデータの完全性と機密性を保ちつつ「特定の処理を行うデータを渡すURL」を作りたくなる場合があります。
例えば、特定のURLをクリックすると特定ユーザーの連絡先にユーザーを登録する、などです。
もっと読むgmailの仕様が変更され自己署名証明書が使えなくなりgmail設定の「アカウントとインポート」で設定したメールアドレスからの送信が使えなくなったようです。結構困っている人が多いようですが判ってしまえば直す方法はそれ程難しくありません。
エラーメッセージで検索するとどうもこの4月くらいから仕様変更されているようです。qmailを使っているのでqmailでの修正方法です。postfixなどでもやる事はあまり変わりません。
もっと読むFedoraでGnomeを使っているのですが、幾つか前のFedoraメジャーバージョンアップ後からスクリーンロック後にGnome Shellがクラッシュするようになってしまいました。放っておけばそのうち直るだろう、と放置していたのですが直る気配がないので調べてみました。
もっと読む標準的な入力バリデーションに「エスケープやフィルタリングが含まれる」とする驚くべき解説があります。そのような入力バリデーションを定義した標準的なセキュリティガイドライン／規格は見た事がありません。標準的な入力バリデーションでは何をすべし、とされているのか紹介します。
もっと読む