手っ取り早くリモートのLinuxマシン（私の場合はVMwareの仮想マシン）からDockerイメージを作りたくなったのでその手順です。 最低限の手順なのでサービス（nginxやhttpd）を動かしたい場合はカスタマイズが必要です。不必要なファイルもコンテナに入るので、サイズを小さくする場合は適当にファイルを削除してください。 きっちり作るにはベースOSに必要…

入力バリデーションでほぼ全てのインジェクションリスクを回避／防止できるケースは以前書いたブログで紹介しています。 今回は趣向を変えて、入力バリデーションで許可してしまった文字で発生するリスクをざっと紹介します。 ※ ここで紹介する考え方は脆弱なブラックリスト型です。より安全な方法はホワイトリスト型の考え方です。参考： ほぼ全てのインジェクション攻撃を無効化／…

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

先日、ソフトウェアセキュリティ対策が”雑”である、という話題になり「どのようなソフトウェアセキュリティ対策が”雑”なのか？」を説明しておかないとならないと感じました。 雑 ［名］いろいろなものが入りまじっていること。区別しにくい事柄を集めたもの。「雑の部」「雑収入」 ［形動］大まかで、いいかげんなさま。ていねいでないさま。粗雑。粗末。「雑な仕事」「雑に扱う」…

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

RDBMSはデータセキュリティを学ぶには良い題材です。RDBMSはできる限り正しいデータを保存する仕組みがあるからです。RDBMSからどのようにデータのセキュリティを保証するのか紹介します。 プログラムが正しく動作する為には 正しいコードであること 正しい（妥当な）データであること が絶対条件です。どちらが欠けてもプログラムは正しく動作しません。 SQLit…

脆弱性を呼ばれた側の責任にする、は常に通用する考え方ではありません。 ライブラリに脆弱性があるなら、ライブラリの脆弱性を直す（呼ばれた側の責任にする） 外部アプリケーションに脆弱性があるなら、外部アプリケーションの脆弱性を直す（呼ばれた側の責任する） は一見正しく見えます。しかし、通用しません。 理由は簡単で、セキュリティ上困った動作をするライブラリやプログ…

ビルドを繰り返して時間があったので、ついついとても長いデータの話を書いてしまいました。今さら聞けない「コード（機能）」と「データ」の話として、もっと単純化してみます。 当然の話なのですが、現実には当たり前ではなかったりします。 「データ」のセキュリティを考慮しないセキュリティ対策はあり得ないのですが、多くのプログラムは「コード（機能）」のセキュリティに偏重し…

コード”だけ”に着目すると脆弱性が量産されます。それはコードだけでは片手落ちであることが理由です。 コンピュータープログラムは「コード」と「データ」によって動作する 言い換えると コンピュータープログラムは「機能」と「データ」によって動作する プログラムの目的は「特定の機能」をコードによって実装することが目的ですが、動作する為には「データ」が欠かせません。 …

プログラムを作っているとOSコマンドを実行したくなる時があります。OSコマンドの実行に問題があり、不正なコマンドをインジェクションされると大変な事になります。 どのようなセキュリティガイドラインでも「OSコマンドの実行に注意する」と大抵書かれています。 多くの場合、「コマンド実行時、コマンドと引数を分離すれば安全に実行できるAPIを利用すれば安全に実行できる…