リモートLinuxマシンのDockerイメージを作る方法

手っ取り早くリモートのLinuxマシン(私の場合はVMwareの仮想マシン)からDockerイメージを作りたくなったのでその手順です。

最低限の手順なのでサービス(nginxやhttpd)を動かしたい場合はカスタマイズが必要です。不必要なファイルもコンテナに入るので、サイズを小さくする場合は適当にファイルを削除してください。

きっちり作るにはベースOSに必要最低限のパッケージだけ入れたコンテナを作り、そのコンテナに必要なパッケージを入れて作ります。しかし、コンテナが大きくても構わない、アップデートをベースのコンテナとDockerfileのビルドで行わなくても構わない、といった際にサクっと作るには便利です。

“リモートLinuxマシンのDockerイメージを作る方法” の続きを読む

入力バリデーションで許可した文字で発生するリスク

入力バリデーションでほぼ全てのインジェクションリスクを回避/防止できるケースは以前書いたブログで紹介しています。

今回は趣向を変えて、入力バリデーションで許可してしまった文字で発生するリスクをざっと紹介します。

“入力バリデーションで許可した文字で発生するリスク” の続きを読む

データのセキュリティ対策が無いセキュリティ対策?!

ソフトウェアのセキュリティ問題の多くは「ソフトウェアの誤作動」です。つまり、正しく動作するソフトウェアならセキュリティ問題の大半は発生しません。1

コンピュータープログラムが正しく動作するには「正しいコード」と「正しいデータ」の両方揃う事が必須条件です。これはプログラムの動作原理に基づく条件なので、誰にも変えることは出来ません。

“データのセキュリティ対策が無いセキュリティ対策?!” の続きを読む

正しく動作するソフトウェアの作り方

ソフトウェアを開発している時に困るのは、ソフトウェアが正しく動作しないケース、に対応する事です。

実用的なソフトウェア作るよりもプロトタイプを作る方が簡単であるのは、ソフトウェアが正しく動作しないケース、に対応する必要がないことが大きな理由です。ソフトウェアが正しく動作しないケースに対応するには、様々な例外的な状態(入力データとソフトウェアの内部状態)全てに対応する必要があります。

例外的な状態を定義するには”ダメな状態”を定義する必要があります。”ダメな状態”を漏れ無く定義するのは結構大変です。ソフトウェアバグの多くは”ダメな状態”を漏れ無く定義することに失敗した為に生まれています。

参考:データセキュリティの概念がないと「正しく動作するプログラム」は作れない。

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

”雑”なソフトウェアセキュリティ対策とは?

“正しく動作するソフトウェアの作り方” の続きを読む

”雑”なソフトウェアセキュリティ対策とは?

先日、ソフトウェアセキュリティ対策が”雑”である、という話題になり「どのようなソフトウェアセキュリティ対策が”雑”なのか?」を説明しておかないとならないと感じました。

[名]いろいろなものが入りまじっていること。区別しにくい事柄を集めたもの。「雑の部」「雑収入」
[形動]大まかで、いいかげんなさま。ていねいでないさま。粗雑。粗末。「雑な仕事」「雑に扱う」

プログラムが正しく(=脆弱性がなく)動作するには

  • 正しいコード
  • 正しいデータ

の両方が”必ず”必要です。このため、丁寧なソフトウェアセキュリティ対策には「コード」と「データ」の両方を丁寧に扱う必要があります。

今あるWebアプリの多くは「データ」の取り扱いが”雑”です。 “”雑”なソフトウェアセキュリティ対策とは?” の続きを読む

インジェクション攻撃は3種類ある

インジェクション攻撃、とは言ってもそのインジェクション対象によって影響が異なります。インジェクション攻撃の対象によって2種類、コードとデータ、に分類できます。Webシステムの場合、リクエストのインジェクションを別のインジェクション攻撃と考えた方が解りやすいので、大まかに分類して3種類に分類できます。

インジェクション脆弱性は絶対に避けなければならない脆弱性である、と認識されていると思います。しかし、3種類あるインジェクション攻撃のうちデータのインジェクションに対するリスク認識が極端に甘いように感じています。

※1 Webシステムを前提としていますが、大抵のシステムは「コード」と「データ」のインジェクションを考慮すれば十分である場合が多いです。

※2 そもそもコードを実行する機能そのものに”コード”を実行させるのは”正当な機能”です。eval( $_GET[‘code’] ) など、これらの機能の基礎的使い方間違いは考慮しません。ここでは本来コードではないデータを介するコードインジェクション、例えば eval( ’var = ‘. $myvar. ‘;’) など、及び、データその物で攻撃するデータインジェクションを取り上げています。

“インジェクション攻撃は3種類ある” の続きを読む

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

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

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

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

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

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

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

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

今のソフトウェアセキュリティが不十分である原因とは?

ソフトウェアのセキュリティを向上させよう!と日々奮闘している方も多いと思います。しかし現在、ソフトウェアセキュリティは十分、と言える情報からは程遠い状態です。

なにが足りないのか?なぜ不十分になるのか?基本的な部分の見落としに原因があります。

“今のソフトウェアセキュリティが不十分である原因とは?” の続きを読む

脆弱性を呼ばれた側の責任にする、は通用しない

脆弱性を呼ばれた側の責任にする、は常に通用する考え方ではありません。

  • ライブラリに脆弱性があるなら、ライブラリの脆弱性を直す(呼ばれた側の責任にする)
  • 外部アプリケーションに脆弱性があるなら、外部アプリケーションの脆弱性を直す(呼ばれた側の責任する)

は一見正しく見えます。しかし、通用しません。

理由は簡単で、セキュリティ上困った動作をするライブラリやプログラムであっても、それが仕様で脆弱性ではないことがあります。

そもそもライブラリやユーティリティプログラムは幅広い用途に利用できるよう、用途を限定しないよう汎用的に作ってある場合が多いです。こういった仕様の場合、脆弱性を呼ばれた側の責任にする、ではセキュリティ問題を作ってしまいます。

“脆弱性を呼ばれた側の責任にする、は通用しない” の続きを読む

今さら聞けない「コード」と「データ」の話

ビルドを繰り返して時間があったので、ついついとても長いデータの話を書いてしまいました。今さら聞けない「コード(機能)」と「データ」の話として、もっと単純化してみます。

当然の話なのですが、現実には当たり前ではなかったりします。

「データ」のセキュリティを考慮しないセキュリティ対策はあり得ないのですが、多くのプログラムは「コード(機能)」のセキュリティに偏重した構造と対策になっています。

安全なプログラムの作成には「コード(機能)」と「データ」のセキュリティを分けて考える必要があります。

“今さら聞けない「コード」と「データ」の話” の続きを読む

命令と引数を分離すれば安全、と考えてしまう”とんでもない誤解”はどこから生まれるのか?

SQL文やコマンド実行には命令と引数を分離するAPIがあります。便利なAPIなのですが、安全性について根本的な勘違いが多いです。

  • プリペアードクエリ系のAPIさえ使っていれば安全
  • execv系のAPIさえ使っていれば安全

これらは大きな勘違いです。

  • データ処理の安全性は”出力先”の処理に依存する

SQLのデータもコマンド実行のデータも、そのデータ出力の安全性は出力先(コンテクスト)でどのように処理されるかに依存します。

SQLインジェクションもコマンドインジェクションも1つでも間違いがあると大問題となる脆弱性ですが、大きな勘違いはかなり広く浸透しています。どこからこんな”とんでもない誤解”が生まれて、広まるのでしょうか?

“命令と引数を分離すれば安全、と考えてしまう”とんでもない誤解”はどこから生まれるのか?” の続きを読む

コード”だけ”に着目すると脆弱性が量産される

コード”だけ”に着目すると脆弱性が量産されます。それはコードだけでは片手落ちであることが理由です。

  • コンピュータープログラムは「コード」と「データ」によって動作する

言い換えると

  • コンピュータープログラムは「機能」と「データ」によって動作する

プログラムの目的は「特定の機能」をコードによって実装することが目的ですが、動作する為には「データ」が欠かせません。

「データ」にも着目するとソフトウェアセキュリティは向上します。今実装されているソフトウェアセキュリティ対策は「コード(機能)」に偏重しているために脆弱になっています

例えば、JSONPが危険な理由は「本来データであるJSONをプログラムとして実行している」ことにあります。X-Content-Type-Options: nosniff を指定するのは「本来データであるJSONをJavaScriptとして実行させない」ようにすることを目的です。

X-Content-Type-Options: nosniff の導入は「データ」に着目したセキュリティ対策と言えます。「データ」として完全に分離し、「コード」として実行できないようにします。

JSONPは危険なので禁止

開発者の多くはソフトウェアセキュリティを考える際、「どのようなコードで攻撃を防止するのか?」を考えていると思います。これだけでは何時まで経っても信頼性が高い(=セキュアなソフトウェア)物は”原理的”に作れないです。

※ 「コードだけに着目するセキュリティ対策」とは「攻撃が発生する箇所(コード)だけに着目するセキュリティ対策」を指しています。

“コード”だけ”に着目すると脆弱性が量産される” の続きを読む

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

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

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

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

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

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

です。

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

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

JSONPは危険なので禁止

CORS問題でAJAXリクエストが失敗する場合の対策として、CORSを設定を紹介しているところまでは良いのですが、他のオプションとしてJSONPを挙げているページを見つけました。記事作成が2018年4月になっていたのでつい最近のことです。あまり知られていないようです。

誤解の無いよう正確に書いておきます。誰かに見られて困るデータが含まれる場合、JSONPは禁止です。

“JSONPは危険なので禁止” の続きを読む

PHPの危い関数リスト

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

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

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

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

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

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

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

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

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

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

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