コンピュータは数値さえ正確に扱えない
コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない？！何を言ってるんだ？！」と思った方は是非読んでみてください。
Struts 2の脆弱性でHTTPのContent-Typeヘッダーからリモートコード実行ができる理由
Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)は
- HTTPプロトコルのContent-Typeヘッダーでリモートからコード実行ができる
という問題です。どうして「Content-Typeヘッダー」でコード実行ができたのか？気になったので調べたメモです。
コード実行ができた理由は「国際化（翻訳）用のメッセージ処理メソッドが、プログラミング言語のようにパースして実行する仕様」であったことでした。気にしていないとこのパターンでリモートコード実行ができてしまうコードも在ると思います。
HMACを利用した安全なAPIキーの送受信
Webアプリケーションの機能をサービスとして提供する場合、ランダムな値の秘密のAPIキーを鍵とすることが多いです。
// 何らかのAPIを呼び出す http://example.com/api/v2/get_something?api_key=qwertyuiop
シンプルな方法で使いやすいですが、鍵となるAPIキーをそのまま使っているので鍵が漏洩する可能性があります。HMACやHKDFを使うと鍵となるAPIキーを直接使わないでAPIへのアクセスを認証できます。
hash_hmac()の使い方
HMACの応用的な使い方をここ数本のブログで書いてきましたが、HMACの基本的な使い方を紹介していませんでした。リクエストパラメーターを安全に検証／バリデーションする方法を例に紹介します。unserialize()を安全に利用する利用例にもなります。
参考：
ハッシュ（HMAC）を使って弱い鍵を強い鍵に変える方法
既存の鍵から別の鍵を導出する方式としてはHKDF（RFC 5869）があります。AES用に弱い鍵から強い鍵を作るにはHKDFでなくてもHMACで十分です。実際、HKDFはHMACを組み合わせて鍵を導出しているだけなので、ここで紹介するHMACのみの鍵導出と同等です。
※ PHP 7.2からHKDFを実装したhash_hkdf()を使えます。hash_hkdf()が利用できる場合はシンプルにhash_hkdf()を使うと良いです。
ハッシュ（HMAC）を使ってパスワード付きURL/URIを作る方法
より高度なCSRF対策 – URL/URI個別にバリデーションする方法でハッシュ（HMAC）を使えばデータベースを使わずに有効期限付きのURLを作れる、と紹介しました。今回はパスワード付きURL（URI）の作り方を紹介します。
より高度なCSRF対策 – URL/URI個別にバリデーションする方法
ハッシュ関数は色々な場面で利用できます。このエントリではハッシュ関数の使い方、特にリクエストにサインする方法として、データベースを使わずURI個別のCSRFトークンを生成しバリデーションする方法を紹介します。
ISO 27000の入力データ妥当性確認
セキュリティ標準では入力データの妥当性確認（入力バリデーション）が要求されています。具体的な方法はBS 7799（英国のJIS規格のような物、2000年に国際標準化）が作られた時（90年代後半）から記載されており、前の版までのISO 270001にも記載されています。2013年版のISO 27000ではセキュアプログラミングが普及したので具体的な方法などは省略しています。（日本では普及していないような。。）
セキュアプログラミングの基本中の基本がセキュリティ対策ではない、というような意味が全く解らない議論もあるのが現状です。
かなり昔に似たようなことを書いたようにも思いますが、記憶が定かではありません。今でも有効なので改めて（？）ブログにします。
ホワイトリストの作り方
ホワイトリストの考え方／作り方は難しくありません。しかし、間違えていることが少なくないようです。
GoogleがCSP（Content Security Policy – ホワイトリスト型のJavaScriptインジェクション対策）の利用状況を調べたところ以下のような結果が得られました。
we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies.
なんと、約95%のCSP利用サイトがCSPの保護が無効になるような設定になっていた、としています。
完全なSQLインジェクション対策
不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。
- プリペアードクエリ／プレイスホルダを使ったSQLインジェクション対策でOK
は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。
簡単な証明：プリペアードクエリ”だけ”では、識別子（カラム／テーブル等）を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ／バリデーションが必須。(問題はコレだけはありません）
似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。
アンチプラクティスであっても正しく動作するならまだ良い方です。しかし、論理的・原理的に出力対策”だけ”では正しく動作するアプリケーションは作れません。
参考：
ソーシャルメディアフィンガープリントとその対策
ソーシャルメディアフィンガープリントがまた話題になっているようです。ソーシャルメディアフィンガープリントとは何か？およびその対策です。
ソーシャルメディアに限らず、ログインをサポートしているサイトであれば、全て対象です。
PHPスクリプトの分析ツール
PHPスクリプトを分析するツールをまとめたページの紹介です。
根本的なセキュリティ対策とは何か？
セキュリティ対策において対策が「根本的」な対策であるかどうか？はあまり重要ではないです。セキュリティ対策において重要なのは対策が「効果的」であるかどうか、が重要だからです。
この基本を押さえた上で、ソフトウェアの「根本的な対策」とは何かを考えてみます。
WordPressをできるだけ安全に使うプラグイン
このブログで利用しているセキュリティ関係のプラグインを紹介します。こういう情報はあまり公開しない方が良いのですが、本気の攻撃者の場合はプラグインファイルの存在を総当たりで検出すれば判ってしまいます。
ソフトウェア開発環境のセキュリティ対策
ソフトウェアの開発環境は通常の環境と違う対策が必要です。その理由は開発環境には
- 他人が書いた未検証のモノ
- 自分が書いた実験用のモノ
- 他人または自分が書いた作りかけのモノ
- 制御された環境での利用を前提としたモノ
- 意図的に利用している新しいモノ（リリース前のソフトウェアなど）
- 意図的に利用している古いモノ（古いシステムサポートためなど）
※モノにはコード／ライブラリ／ツール／アプリ／システム などがあります。
などがある為です。開発環境はその他の環境に比べ「とにかく危険なモノがいっぱい」です。
更に最近ではソーシャルコーディングが当たり前になり、他人が書いた未検証のコードがどんどん実行される状態も当たり前です。それも1つ2つのライブラリではなく、依存性から何百、場合によっては何千というライブラリなどが自動的にダウンロードされ実行されています。
これがどういう状況かというと「PCがやっと使えるくらいのユーザーが、インターネットからプログラムをダウンロードしまくって実行している状況」とあまり変わりません。