設計
このタグの記事 4 件
よくあるセキュリティの失敗4つ：初期設定・閉じ忘れ・監視不足・入力検証の思い込み
事故は珍しい攻撃ではなく、決まった型から起きる。技術分類ではなく『誤った前提』で整理すると4つになる——既定値は安全なはず（設定を触っていない）、使っていないものは危なくないはず（閉じ忘れ）、何かあれば気づくはず（見えていない）、入力は検証すれば安全なはず（外部に決めさせすぎ）。どれも個々の技術知識ではなく、確認の習慣で防げる。自分の環境で何を見ればよいかを型ごとにまとめた。
安全でないデシリアライズとは：外部データにオブジェクトの型を決めさせる危険と対策
デシリアライズの危険は『変なデータが入ること』ではなく、形式によっては『どの型のオブジェクトを組み立てるか』を外部データが決められることにある。だから被害はデータの破損では終わらず、OWASPはサービス停止・アクセス制御の迂回・リモートコード実行を挙げる。対策の軸は2つ。JSONやXMLのような純粋なデータ形式に切り替えて型を選ばせない、そしてシリアライズ時に署名し、署名の無いものは復元しない。一部の仕組みは設定では安全にできず、使うのをやめる以外にない。
パスワードリセットの設計欠陥：ログインを強くしても乗っ取られる5つの型と対策
リセット機能は『パスワードを知らない人に、パスワードを作らせる仕組み』＝それ自体が認証経路。だから認証本体をいくら固めても、リセットが弱ければそこが実際の認証強度になる。壊れる型は5つ：推測できるトークン／失効しないトークン／メールに残り続けるリンク／リンクの宛先を外から差し替えられる（Hostヘッダ）／応答の差でアカウントの存在が分かる。OWASPが明示している要件と、仕様が数字を決めていない部分（長さ・期限）を分けて扱うのが実装のポイント。
レート制限と濫用対策：総当たり攻撃と過剰な課金を防ぐ設計
レート制限の失敗は『緩すぎ』より、考えるべき点を取り違えたことで起きる。設計に必要な問いは3つ。誰を数えるか（IPは偽装され得るので、何を識別子にするかが先）、何を数えるか（回数だけでなくコスト・サイズ・件数）、上限に達したらどうするか（拒否は正規利用者へのDoSにもなる）。NISTは連続失敗100回までを上限としつつ、遅延やCAPTCHAで正規利用者を締め出すなと明記。OWASPはAPIの上限に『支出上限』を含めており、これが金銭被害を止める最後の対策になる。