書かない日記
覚えなくて構わないパスワード（ブラウザなどのパスワードマネージャーに記憶されるランダムパスワード）の作り方は、
で紹介しました。ランダムパスワードを自分で作るのが面倒な方はこのページのランダム文字列から90文字くらいをコピー＆ペーストして使ってください。
今度は覚えるパスワードの作り方です。
備考：あるニュース記事で”ブラウザのパスワード機能は使わない”とする記事がありました。その理由は、離席した場合などにパスワードが表示できる物もあるから、でした。しかし、PCをログインしたままロックもせずに離席すると、ログイン済みならアクセス仕放題、サードパーティー製のパスワードマネージャーを使っていても利用するサービスにはログイン仕放題、です。デバイスの物理セキュリティは何をしていてもある程度は使い方で保証しなければセキュリティは維持できません。
形式的検証とは
形式的検証（けいしきてきけんしょう）とは、ハードウェアおよびソフトウェアのシステムにおいて形式手法や数学を利用し、何らかの形式仕様記述やプロパティに照らしてシステムが正しいことを証明したり、逆に正しくないことを証明することである
英語ではFormal Verificationとされ
formal verification is the act of proving or disproving the correctness of intended algorithms underlying a system with respect to a certain formal specification or property, using formal methods of mathematics.
と説明されています。形式手法として紹介されることも多いです。
参考： 形式検証入門 （PDF）
形式的検証は、記述として検証する方法から数学的にプログラムが正しく実行されることを検証する仕組みまで含みます。数学的な形式的検証では、可能な限り、全ての状態を検証できるようにしてプログラムが正しく実行できることの証明を試みます。
参考：ソフトウエアは硬い （日経XTECHの記事）
契約プログラミング（契約による設計 – Design by Contract, DbC）も形式的検証の１つの方法です。
形式検証の仕組みを知ると、厳格な入力バリデーションが無いと”組み合わせ爆発”により、誤作動（≒ セキュリティ問題）の確率も爆発的に増えることが解ります。
往年のWeb開発者であれば X-Content-Type-Options: nosniff はIE専用のオプションHTTPヘッダーだと理解している方が多いと思います。
この理解は正しかったのですが、現在は正しくありません。nosniffはChromeやFirefoxの動作にも影響与えます。このため、IEをサポートしないサイトであっても X-Content-Type-Options: nosniff は必要なHTTPヘッダーです。
Webサイトにはパスワードの登録に余計な制限をかけているサイトが少なからずあります。特に最悪なのはたった20文字程度のパスワードしか許可しないサイトです。
Webサイトのパスワードは基本的には覚える必要がありません。安全性を第一に考えると十分過ぎるくらいの長さのランダムパスワードを設定する／設定できるようにすると良いです。
パスワード用のランダム文字列が必要でアクセスした方は以下のURLを参照してください。生成されたランダム文字列の一部、90文字くらい、をパスワードとして使うと安全です。
Facebookでこんなやり取りをしました。元々公開設定で投稿した物で、議論させて頂いた浅川さんにも「ブログOK」と許可も頂いたので、そのやり取りの部分だけを紹介します。
テーマは「SQLクエリと識別子エスケープ」です。
とあるブログの結論として
“「安全な静的SQLの発行方法」を開発者に啓蒙すればいいだけだ。つまり
- プリペアドクエリでSQL発行は行うこと
この場合変数のバインドは必ずプレースホルダを用いること。SQL文の文字列操作は禁止であり、これほどシンプルなことも無いだろう”
と書かれていました。しかし、私はこの意見に対して
実践的なSQLクエリを書いたことが全くない開発者なのでしょう？？
ソートカラム、抽出カラムを指定するSQLクエリでは「識別子（カラム名）が変数」になります。
初歩的なSQLクエリですが”自分が書いたことないから”といって一般的ではないと勘違いしています。行のソート順、抽出カラムを指定するSQLクエリは業務アプリでは”一般的”です。当たり前ですが。こうやってベストプラクティスもどきのアンチプラクティスが使われて、喜ぶのはサイバー犯罪者とセキュリティ業者だけですよ。
とコメントしました。SQLのテーブルやジョイン結果を「表」として表示した際に、任意のカラムのソート順を指定するUIは、自分で作ったことが無かったとしても、ごく一般的だと分かると思うのですが・・・
PHP 7.1で追加された hash_hkdf() は出鱈目なシグニチャを持っています。バイナリキーを使うことを想定して、わざわざ既存のハッシュ関数とは異なり、バイナリハッシュ値だけを返せるようになっています。
暗号化がプログラム内で完結する、といった極一部の例外を除きhash_hkdf()でわざわざバイナリキーを使う意味はありません。
CSRFキーを守る、URLを守る、APIキーを守る、といったWebアプリケーションで最も頻繁に使われる鍵導出ではバイナリキー／バイナリSaltは、遅いのでむしろ有害と言えます。わざわざバイナリを使う必要はありません。
参考： HMACハッシュの使い方のまとめ – HAMCですが、HKDFはHMAC based Key Derivation Functionです。多くがHKDFで置き換えられます。HKDFが使える場合、hash_hkdf()を使った方が速くなるでしょう。これはPHPの関数呼び出しのオーバーヘッドが比較的大きいことに起因します。
I had discussion on PHP dev mailing list. It appeared that not few developers misunderstand “What is Input Validations“. Therefore, I summarize computer programming fundamentals and basics to help understanding validations.
Without fundamentals and basics understanding, discussion is meaningless. “Input Validation” is one of the most important countermeasure for cyber attacks. The idea is strongly supported by notable computer scientists (e.g. CMU’s CERT) and security specialists, yet it is misunderstood by majority of developers. Therefore, almost all web applications are missed to have proper “Input Validation” currently.
I came across this discussion too often, so I summarize why, “Input Validation”, “Input Data Validation” or “Application Input Data Validation” especially, is fundamental and mandatory requirement for applications.
“Application Input Data Validation” and “Business Logic Validation” are 2 different validations by fundamentals and principles. Except few exceptions, ALL web application input data can be validated by “Application Input Data Validation” without user interactions. This achieves more secure state and cleaner/manageable code structure. Thus, applications should implement “Application Input Data Validation” always.
Note: “Application Input Data Validation” is NOT a replacement of “Business Logic Validation”.
“Computer Programming Fundamentals and Principles – Input Validation” の続きを読む
入力バリデーションCモジュール、Validate PHPモジュールの待望(?)のスクリプト版です。
週末に半日くらいで書いて、サンプルスクリプトだけしか作っていないので「超開発版」です。（まだ未実装機能もあります）
特定のエントリポイント（つまりMVCのコントローラー）のGET/POST/COOKIE/FILES/HTTP Headerをまとめて、一気に、効率良くバリデーションできるように設計してあります。
個別に「入力値の形式」を定義さえすれば、「データ型を指定する感覚」で理想的な入力バリデーションを実装できます。
https://github.com/yohgaki/validate-php-scr/blob/master/src/examples/00-validate.php
スクリプト版のAPIが安定したら、Cモジュール版が同じように動作するように更新します。（その為に、C言語で実装しやすいような感じのPHPスクリプトを書いています）
https://github.com/yohgaki/validate-php-scr
ドキュメントはほとんど意味がないので、サンプルスクリプトとコードを読んでください。
一気に書いて、後で多少手直しした程度です。バグがあると思うので見つけたら教えてください。こうしたら良い、こうして欲しい、といったご意見も歓迎です。
本物の「セキュアコーディング」（セキュアプログラミング）を知ればもう議論など必要ない、と思っています。本物の「セキュアコーディング」を「知ろうとしない」と幾らでもアンチプラクティスを作ってしまいます。
議論は終り、と思っていたのですがそうも行かないようなので紹介します。セキュアコーディングの概念を全く知ろうとしないで、セキュリティを作るのは「ただの無駄」です。多数のアンチプラクティス／間違いが含まれるスライドの中から（一々指摘するとキリがない）
これ”だけ”だとアンチプラクティスです。
※ 契約プログラミングが流行らない理由はこいうアンチプラクティスも原因でしょう。
入力バリデーションで文字列の妥当性を検証（保証）しないと、不正文字問題の解決はできません。
よく「文字エンコーディングバリデーションは入力バリデーションしなければならない」と紹介はするのですが、その理由を詳しく解説していませんでした。これは文字エンコーディング攻撃の仕組みを理解してれば分かる事なのでしていませんでした。
しかし、文字エンコーディング攻撃の仕組みを理解していても必要なし、とする意見があるので理解り易く説明します。（理解りづらかったら教えてください）UTF-8のみですが、他の文字エンコーディングでも基本は同じです。
このブログは、IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき、の「追加の情報」として書いた物を別エントリとしてまとめた物です。
の3つが１つのセットとして成り立ちます。これ以外はセキュアコーディングではありません。
入力、ロジック、出力、これら全てにバリデーションが必要です。
セキュアコーディングの第1原則は「入力をバリデーションする」です。セキュアコーディングの第1原則はソフトウェアセキュリティの一丁目一番地と言えるセキュリティ対策です。
入力バリデーションを第一のセキュリティ対策としているガイドライン：
セキュアプログラミング／セキュアコーディングを要求するセキュリティ認証：
90年代初めからコンピューターサイエンティストのセキュリティ専門家は「入力バリデーション」が重要であるとしてきました。「入力バリデーション」は論理的にセキュアな構造のソフトウェアを作る為に欠かせない必須の要素だからです。防御的プログラミングから数えると四半世紀を越える月日が経っています。
しかし、残念ながらセキュアコーディングの第1原則の「入力バリデーション」は普及しているとは全く言えません。この状況には理由があります。
この状況に責任があるIPAは、IPAのセキュアプログラミング講座 1に基礎的な誤りがあったことを明示し、開発者に与えた誤解が正されるよう、最大限の努力をすべきでしょう。
IPAのあり得ないような基礎的誤りがどのような物だったか、ご覧ください。
ここ十数年で見聞きした、脆弱なアプリを作ってきたベストプラクティスもどきのアンチプラクティス、をリストアップしてみます。
限定された条件ではベストプラクティスと言える物でも、一般化するとアンチプラクティスになる物は多いです。
コード検査をしていると良く分るのですが、アンチプラクティスは強力な破壊力を持っています。ここに書いているアンチプラクティスを無くすだけでも、致命的な問題／脆弱なコードを多数無くすことができるでしょう。
TOP 10と題しましたが、アンチプラクティスの順序と重要性（悪影響）にはあまり関連性はありません。
ほとんどセキュリティ問題は「想定外の動作」が原因です。例えば、インジェクション攻撃は開発者にとって「想定外の動作」でしょう。ソフトウェア開発者が意図しない想定外の動作のほとんどは「想定外のデータ」が原因です。
この事実をから簡単に分かる「想定外」を無くす方法があります。たった2つの方法を”両方”行うだけで、現在あるアプリの9割程度の脆弱性が無くなります。
今まで出来る限り正確に「どうすれば想定外をなくせるか？」を紹介してきましたが、今回は出来る限り簡潔にどうすると良いのか、ダメなのか紹介したいと思います。 “プログラムから「想定外」を無くす方法” の続きを読む
セキュリティの原理、原則、ベストプラクティスに自分でコメントを追加しました。以前、論理的にセキュリティ対策を検証する方法や論理的なセキュリティ対策の評価方法は書いたのですが、論理的にセキュリティを構築する方法は書いていないことを思い出しました。追加したコメントと欠陥だらけのソフトウェアセキュリティ構造を紹介したブログをベースにセキュリティを論理的に構築する方法を紹介します。
このエントリの解説はCERT、つまり米カーネギーメロン大学、の資料をベースにしています。
「セキュリティの」と付けていますが、どの分野でも共通することだと思います。
何事でも論理的に何かのガイドライン／ルールを作る場合、まず変えることのできない
を見つけ、その原理から導き出される
を作り、さらに特定の条件下の具体的な事例として
を作ります。原理、原則、ベストプラクティスを理解していないと様々な問題がおきます。これらの基本的関係は
原理 ＞ 原則 ＞ ベストプラクティス
です。しかし、適用範囲の広さは
原理 ＜ 原則 ＜ ベストプラクティス
です。例えば、ベストプラクティスは”例外的”に原則に反した方法が”最善の方法”となる場合も少なくないからです。よく混乱や誤解の元になりますが、条件を絞った場合（例外的なケース）のベストプラクティスも在ります。
例外的なケース（一般的で無いモノ=例外的な物）をベストプラクティスにすることには異論もありますが、結構狭い条件でしかベストプラクティスにならないモノが”ベストプラクティス”と呼ばれていることは多いです。1
現在のWebアプリケーションのほとんどは「入り口対策」がない「入り口ノーガード設計」です。
※ アプリケーションの入力処理、つまりMVCアーキテクチャーならコントローラーレベルで「入り口対策」がない設計が「入り口ノーガード設計」です。
このような設計になっているので、本来は自然数だけのハズのHTTPヘッダーのContent-Length（やContent-Type／Content-Disposition）にプログラムが書けてしまったStruts2 Webアプリにより国内ではクレジットカード情報が何十万件も盗まれる、米国では1億4千万件以上の信用情報が漏洩する、といった事件が発生しています。
幸い、「入り口対策」がない「入り口ノーガード設計」でもこういった大規模インシデントになるような脆弱性の攻撃は多くありません。しかし、話題にならないだけで多数のインシデントが世界中で発生していると考えられます。
先の事例はStruts2／フレームワークのセキュリティ問題、と捉えられていることが多いと思います。しかし、これは本質的にセキュリティ原則を無視した「入り口ノーガード設計」の問題です。
コード検査していると「入り口対策」をしていて、本当に良かったですね！というケースに出会うことが少なくありません。
2018年5月からEUでGDPRが施行されます。GDPR違反となると2000万ユーロまたは全世界売上の4％のどちらか高い方が罰金（組織によっては1000万ユーロまたは全世界売上の2％）となります。GDPRには様々な要件が要求されていますが、国際情報セキュリティ標準であるISO 27000で”普及している”とされた”セキュアプログラミング技術”の原則さえ採用しないシステムで個人情報漏洩が起きた場合の被害は、簡単に会社を潰すレベルの損害になる可能性があります。
ソフトウェアの不具合／脆弱性を無くすためには、出力先に対して無害であることを保障する出力対策が重要です。どんな出力でも3つの方法で無害化できます。
このブログでは基本として、セキュアコーディングの概念に基き説明しています。先ずはよくある入力対策と出力対策の区別がついていない誤りから紹介します。
バリデーション、と一言で言っても一種類／一箇所だけではありません。バリデーションには3種類のバリデーションがあります。
バリデーションは重要であるにも関わらず誤解が多い機能の筆頭だと思います。日本に限らず世界中でよくある議論に
があります。どこかで見た事があるような議論ですが、世界的にこのような考えの開発者が多いことは、この入力バリデーション用のPHP拡張モジュールを書いた時の議論で分かりました。1
実際、多くのWebアプリケーションフレームワークは入力バリデーション機能をデフォルトでは持たず、アプリケーションレベルでの入力バリデーションを必須化していません。開発者が上記のような考えになっても当然と言えるかも知れません。しかし、必要な物は必要です。何故？と思った方はぜひ読み進めてください。
流石にこの時の議論ではありませんでしたが、以下の様な議論も見かけます（ました）
全てセキュアなソフトウェア構造を作るには問題がある考え方です。最後の「入力バリデーションはソフトウェアの仕様でセキュリティ対策ではない！」とする考え方の問題点は”セキュリティ対策の定義”2を理解していないと問題点は見えないかも知れません。
このセキュリティ対策の定義はISO 27000／ISMSの定義をまとめたモノです。
入力対策と出力対策は両方必要でエスケープの知識はセキュアなソフトウェア構築には欠かせません。アプリケーションの入り口で入力検証をしていないアプリはセキュアでない構造です。入り口以外に入力検証がないアプリもセキュアではない構造です。セキュアなアプリには最低限、入り口でのデータ検証と出口でのデータ無害化（エスケープ／API／バリデーション）が必須です。
数値の入力にはバリデーションは要らない、と考えているケースが少なからずあるようです。本当に数値に対するバリデーションは無意味なのでしょうか？