カテゴリー
Computer PHP Security Programming Secure Coding

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

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

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

カテゴリー
Computer Development PHP Security Programming Secure Coding

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

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

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

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

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

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

カテゴリー
Computer Development PHP Security Programming Secure Coding

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

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

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

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

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

カテゴリー
Computer PHP Security Programming Secure Coding

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

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

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

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

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

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

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

カテゴリー
Computer Development PHP Security Programming Secure Coding

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

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

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

言い換えると

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

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

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

例えば、JSONPが危険な理由は「本来データであるJSONをプログラムとして実行している」ことにあります。

JSONPは危険なので禁止

X-Content-Type-Options: nosniff を指定するのは「本来データであるJSONをJavaScriptとして実行させない」ようにすることを目的です。X-Content-Type-Options: nosniff の導入は「データ」に着目したセキュリティ対策と言えます。「データ」として完全に分離し、「コード」として実行できないようにします。

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

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

カテゴリー
Computer Development PHP Security Programming Secure Coding Security

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

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

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

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

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

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

です。

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

カテゴリー
Computer Development PHP Security Programming Secure Coding

JSONPは危険なので禁止

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

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