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

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

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

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

ソフトウェアのセキュリティを向上させよう！と日々奮闘している方も多いと思います。しかし現在、ソフトウェアセキュリティは十分、と言える情報からは程遠い状態です。 なにが足りないのか？なぜ不十分になるのか？基本的な部分の見落としに原因があります。 (さらに…)

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

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

SQL文やコマンド実行には命令と引数を分離するAPIがあります。便利なAPIなのですが、安全性について根本的な勘違いが多いです。 プリペアードクエリ系のAPIさえ使っていれば安全 execv系のAPIさえ使っていれば安全 これらは大きな勘違いです。 データ処理の安全性は”出力先”の処理に依存する SQLのデータもコマンド実行のデータも、そのデータ出力の安全性…

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

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