RDBMSから学ぶデータセキュリティ

RDBMSはデータセキュリティを学ぶには良い題材です。RDBMSはできる限り正しいデータを保存する仕組みがあるからです。RDBMSからどのようにデータのセキュリティを保証するのか紹介します。

プログラムが正しく動作する為には

  • 正しいコードであること
  • 正しい(妥当な)データであること

が絶対条件です。どちらが欠けてもプログラムは正しく動作しません。

SQLiteは手軽で良いのですが、組み込み型であるためデータセキュリティを学ぶには機能的に問題があります。SQLiteにはデータ型を保証する機能もデータの内容を検証する機能もありません。1

利用するRDBMSはPostgreSQLを用い、データセキュリティに関連性の強い機能のみを対象とします。

“RDBMSから学ぶデータセキュリティ” の続きを読む

コマンド実行時、コマンドと引数を分離すれば完璧?

プログラムを作っているとOSコマンドを実行したくなる時があります。OSコマンドの実行に問題があり、不正なコマンドをインジェクションされると大変な事になります。

どのようなセキュリティガイドラインでも「OSコマンドの実行に注意する」と大抵書かれています。

多くの場合、「コマンド実行時、コマンドと引数を分離すれば安全に実行できるAPIを利用すれば安全に実行できる」としています。

この記述は間違ってはいないです。しかし、正しくは

  • コマンド実行時、コマンドと引数を分離すれば”比較的”安全に実行できる”場合が多い

です。

コマンドと引数を分離するAPI利用だけでは完璧とは言えないセキュリティ対策です。

“コマンド実行時、コマンドと引数を分離すれば完璧?” の続きを読む

PHPの危い関数リスト

一応、PHPの危い関数リスト、は存在します。例えば、以下のような物があります。

後者は主にホスティング環境(?)でリスクがある関数の一覧を作るプログラムのようです。

ファイルを操作する関数、コマンドやスクリプトを実行する関数などのリスクは自明だと思います。少し趣向を変え、間違えて使うと危い関数の一覧を独断と偏見で作ってみました。

【重要】こういった「危険な物」を定義するのはブラックリストです。ブラックリストは仕組的に危険です。ブラックリストに頼るのは脆弱性を作るような物です。ブラックリスト”だけ”で安心しないでください。最後にどうすれば良いのか?を書きます。

“PHPの危い関数リスト” の続きを読む

構造化設計とセキュアコーディング設計の世界観は二者択一なのか?

プログラミングの「世界観」

で構造化プログラミング/オブジェクト指向プログラミングの世界観(パラダイム)では、抽象化を行い問題を関数やオブジェクトの中に閉じ込める。つまり、プログラムの内部奥深くに”問題”を閉じ込めようとする。

セキュアコーディングの世界観では、”正しくないデータはどう処理しても正しく処理不可能である”プログラム原理と”失敗する物はできる限り早く失敗させる”Fail Fast原則に従い、できる限り問題となる”データ”を早い段階で廃除する、つまり問題を中に入れずに入り口で対策する、と紹介しました。1

一見すると相反するように見えますが、これら2つの世界観を持つ概念は二者択一ではありません。

“構造化設計とセキュアコーディング設計の世界観は二者択一なのか?” の続きを読む

JavaScriptでインジェクションリスクがある関数/機能など

Webブラウザに対するJavaScriptコードのインジェクションは

  • サーバー側のコードが原因(サーバー側のPHP、Ruby、Python、JavaScriptが原因)
  • クライアント側のコードが原因(クライアント側のJavaScriptが原因)
  • サーバーとクライアント(上記の両方)

で起きる可能性があります。ここでは主にクライアント側が関係するケースで注意しなければならない箇所を紹介します。

“JavaScriptでインジェクションリスクがある関数/機能など” の続きを読む

プログラミングの「世界観」

rustcを通らないコードは間違っているに以下のような記述があります。

「そのコードがRust wayではない」という点で「間違っている」。microなスタイルからmacroな設計まで、ありとあらゆる点でRust的なコードであることを暗黙的ではあるが極めて強く要求する。それがRustというプログラミング言語だ。

Rustはコンパイル時点で可能な限りの正しく実行できないコードが生成されないような言語になっていることは比較的良く知られていると思います。このブログはこの違いを「世界観」が異なるという視点でまとめています。

Rustの場合、マルチスレッドプログラミングでデータ競合が起きないような書き方をしなければならない制約があり、従来のプログラミング言語とは異なる考え方(=世界観)が要求されている。自分のコードは正しくても「Rustの世界観では間違っている」としています。

「世界観」の違いで言語やプログラミング方式を捉える考え方は面白いと思います。

“プログラミングの「世界観」” の続きを読む

覚えるパスワードの作り方

覚えなくて構わないパスワード(ブラウザなどのパスワードマネージャーに記憶されるランダムパスワード)の作り方は、

覚えないパスワードは生成する物 〜 余計な文字数制限などは有害 〜

で紹介しました。ランダムパスワードを自分で作るのが面倒な方はこのページのランダム文字列から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)も形式的検証の1つの方法です。

形式検証の仕組みを知ると、厳格な入力バリデーションが無いと”組み合わせ爆発”により、誤作動(≒ セキュリティ問題)の確率も爆発的に増えることが解ります。

“”形式的検証”と”組み合わせ爆発”から学ぶ入力バリデーション” の続きを読む

X-Content-Type-Options: nosniff はIE以外にも必要

往年のWeb開発者であれば X-Content-Type-Options: nosniff はIE専用のオプションHTTPヘッダーだと理解している方が多いと思います。

この理解は正しかったのですが、現在は正しくありません。nosniffはChromeやFirefoxの動作にも影響与えます。このため、IEをサポートしないサイトであっても X-Content-Type-Options: nosniff は必要なHTTPヘッダーです。

“X-Content-Type-Options: nosniff はIE以外にも必要” の続きを読む

覚えないパスワードは生成する物 〜 余計な文字数制限などは有害 〜

Webサイトにはパスワードの登録に余計な制限をかけているサイトが少なからずあります。特に最悪なのはたった20文字程度のパスワードしか許可しないサイトです。

Webサイトのパスワードは基本的には覚える必要がありません。安全性を第一に考えると十分過ぎるくらいの長さのランダムパスワードを設定する/設定できるようにすると良いです。

参考:覚える場合のパスワードの作り方

TL;DR;

パスワード用のランダム文字列が必要でアクセスした方は以下のURLを参照してください。生成されたランダム文字列の一部、90文字くらい、をパスワードとして使うと安全です。

パスワード用のランダム文字列生成スクリプト

“覚えないパスワードは生成する物 〜 余計な文字数制限などは有害 〜” の続きを読む

hash_hkdf()でわざわざバイナリキー/バイナリSaltを使うことに意味はない

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の関数呼び出しのオーバーヘッドが比較的大きいことに起因します。

“hash_hkdf()でわざわざバイナリキー/バイナリSaltを使うことに意味はない” の続きを読む

Computer Programming Fundamentals and Principles – Input Validation


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.

TL;DR;

“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” の続きを読む

「脆弱性を局所的に潰す」はアンチプラクティス

本物の「セキュアコーディング」(セキュアプログラミング)を知ればもう議論など必要ない、と思っています。本物の「セキュアコーディング」を「知ろうとしない」と幾らでもアンチプラクティスを作ってしまいます。

議論は終り、と思っていたのですがそうも行かないようなので紹介します。セキュアコーディングの概念を全く知ろうとしないで、セキュリティを作るのは「ただの無駄」です。多数のアンチプラクティス/間違いが含まれるスライドの中から(一々指摘するとキリがない)

  • 「脆弱性を局所的に潰す」

これ”だけ”だとアンチプラクティスです。

※ 契約プログラミングが流行らない理由はこいうアンチプラクティスも原因でしょう。特定の良いこと”だけ”を積み重ねても良い結果にならない、ことは合成の誤謬として知られています。

“「脆弱性を局所的に潰す」はアンチプラクティス” の続きを読む

バリデーションですべきこと

このブログは、IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき、の「追加の情報」として書いた物を別エントリとしてまとめた物です。

CERTセキュアコーディング

  • 入力バリデーション(原則1)
  • ”セキュアコーディング標準”による安全なロジック処理(+具体的な入力/出力処理)※ 原則10 「セキュアコーディング標準を採用する」=自ら作るモノ
  • 出力の無害化(原則7)※ IPA版は原則2

の3つが1つのセットとして成り立ちます。これ以外はセキュアコーディングではありません。

入力、ロジック、出力、これら全てにバリデーションが必要です。

参考: コンピュータは数値さえ正確に扱えない

“バリデーションですべきこと” の続きを読む

IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき

セキュアコーディングの第1原則は「入力をバリデーションする」です。セキュアコーディングの第1原則はソフトウェアセキュリティの一丁目一番地と言えるセキュリティ対策です。

入力バリデーションを第一のセキュリティ対策としているガイドライン:

セキュアプログラミング/セキュアコーディングを要求するセキュリティ認証:

  • ISMS – 国際情報セキュリティ標準 ISO 27000 の認証規格
  • PCI DSS – クレジットカード情報を取り扱う場合の認証規格

90年代初めからコンピューターサイエンティストのセキュリティ専門家は「入力バリデーション」が重要であるとしてきました。「入力バリデーション」は論理的にセキュアな構造のソフトウェアを作る為に欠かせない必須の要素だからです。防御的プログラミングから数えると四半世紀を越える月日が経っています。

しかし、残念ながらセキュアコーディングの第1原則の「入力バリデーション」は普及しているとは全く言えません。この状況には理由があります。

この状況に責任があるIPAは、IPAのセキュアプログラミング講座 1に基礎的な誤りがあったことを明示し、開発者に与えた誤解が正されるよう、最大限の努力をすべきでしょう。

IPAのあり得ないような基礎的誤りがどのような物だったか、ご覧ください。

“IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき” の続きを読む

プログラムから「想定外」を無くす方法

ほとんどセキュリティ問題は「想定外の動作」が原因です。例えば、インジェクション攻撃は開発者にとって「想定外の動作」でしょう。ソフトウェア開発者が意図しない想定外の動作のほとんどは「想定外のデータ」が原因です。

この事実をから簡単に分かる「想定外」を無くす方法があります。たった2つの方法を”両方”行うだけで、現在あるアプリの9割程度の脆弱性が無くなります。

今まで出来る限り正確に「どうすれば想定外をなくせるか?」を紹介してきましたが、今回は出来る限り簡潔にどうすると良いのか、ダメなのか紹介したいと思います。 “プログラムから「想定外」を無くす方法” の続きを読む

セキュリティを論理的に構築する方法

セキュリティの原理、原則、ベストプラクティスに自分でコメントを追加しました。以前、論理的にセキュリティ対策を検証する方法論理的なセキュリティ対策の評価方法は書いたのですが、論理的にセキュリティを構築する方法は書いていないことを思い出しました。追加したコメント欠陥だらけのソフトウェアセキュリティ構造を紹介したブログをベースにセキュリティを論理的に構築する方法を紹介します。

このエントリの解説はCERT、つまり米カーネギーメロン大学、の資料をベースにしています。

“セキュリティを論理的に構築する方法” の続きを読む

セキュリティの原理、原則、ベストプラクティス

「セキュリティの」と付けていますが、どの分野でも共通することだと思います。

何事でも論理的に何かのガイドライン/ルールを作る場合、まず変えることのできない

  • 原理 – 事物・事象が依拠する根本法則

を見つけ、その原理から導き出される

  • 原則 – 多くの場合に共通に適用される基本的なきまり・法則

を作り、さらに特定の条件下の具体的な事例として

を作ります。原理、原則、ベストプラクティスを理解していないと様々な問題がおきます。これらの基本的関係は

原理 > 原則 > ベストプラクティス

です。しかし、適用範囲の広さは

原理 < 原則 < ベストプラクティス

です。例えば、ベストプラクティスは”例外的”に原則に反した方法が”最善の方法”となる場合も少なくないからです。よく混乱や誤解の元になりますが、条件を絞った場合(例外的なケース)のベストプラクティスも在ります。

例外的なケース(一般的で無いモノ=例外的な物)をベストプラクティスにすることには異論もありますが、結構狭い条件でしかベストプラクティスにならないモノが”ベストプラクティス”と呼ばれていることは多いです。1

“セキュリティの原理、原則、ベストプラクティス” の続きを読む