Secure input handling

Secure Input Handling

ユーザー入力・外部データを扱うコードを書いている最中に適用するチェックリスト。監査・レポート作成が目的ではなく、実装中に自動的に安全な形にすることが目的（明示的なセキュリティ監査・レポートを求められた場合はsecurity-best-practicesを使う）。

適用手順

1. 入力検証（すべての入力受付点で最初に行う）

1. 「許可される値」をホワイトリストとして明確に定義する。デニリスト（禁止パターンの列挙）は補助防御に留め、主防御にしない。
2. 固定選択肢（enum、ドロップダウン由来の値）は提示された値との完全一致で検証する。
3. 正規表現を使う場合は文字列全体を^...$でカバーし、無制限の.*や入れ子の量指定子を避ける（ReDoS対策）。
4. 長さ制限・数値範囲・型変換を必ず行い、変換失敗時は例外を握りつぶさず明示的に拒否する。
5. クライアント側検証はUX目的のみとし、サーバー側で必ず同じ検証をやり直す（クライアント側は迂回可能）。

2. SQL・クエリ実行（DBアクセスコードを書くたびに確認）

優先順位に従って選ぶ：

1. 第一選択：パラメータ化クエリ（プレースホルダ）でSQL文とデータを分離する。文字列結合・テンプレートリテラルでSQLを組み立てない。
2. 第二選択：ストアドプロシージャ（ただし内部で動的SQL文字列結合をしていないことを確認する）。
3. 第三選択（テーブル名・カラム名など動的に変える必要がありバインド変数が使えない場合のみ）：許可された識別子のホワイトリストにマッピングしてから組み込む（switch文等で明示的に対応）。
4. ソート順（ASC/DESC）等の構文要素はenum/真偽値に変換してから組み込み、ユーザー入力文字列を直接埋め込まない。
5. 追加の多層防御：アプリ用DBアカウントは機能ごとに分離し最小権限のみ付与する。DBA権限を絶対に付与しない。

3. 認証・セッション管理（ログイン・認可機能を書くとき）

1. パスワードは専用のハッシュ関数（bcrypt/argon2/scrypt）で保存する。平文保存・自前の暗号化・弱いハッシュ（MD5/SHA1単体）は使わない。
2. ログイン成功時にセッションIDを再生成する（セッション固定攻撃対策）。
3. ステート変更を伴うリクエスト（POST/PUT/DELETE）にはCSRF対策トークンを付与し検証する。
4. 多要素認証（MFA）を後付けしやすい設計にしておく（認証ロジックを1箇所に集約する）。
5. 認可チェックはUI層だけでなく必ずサーバー側（API層）でも行う。

4. 出力エンコーディング（XSS対策）

1. テンプレートエンジンの自動エスケープを無効化しない。無効化が必要な場合は理由をコメントで明記し、その箇所だけサニタイズ処理を追加する。
2. ユーザー入力をHTML/JS/URL/CSSのいずれのコンテキストに出力するかで、適切なエンコーディング関数を使い分ける。
3. innerHTML等のDOM直接操作でユーザー入力を扱わない（テキストノードとして挿入する、またはサニタイズライブラリを通す）。

5. ファイルアップロード

1. 拡張子・MIMEタイプをホワイトリストで検証する（クライアントが送るMIMEタイプは偽装可能なので、内容ベースの検証も検討する）。
2. 最大サイズ制限を設定する。
3. 保存時はユーザー入力のファイル名をそのまま使わず、ランダムなファイル名を生成する（パストラバーサル対策）。
4. 可能であればマルウェアスキャン等の内容検査を行い、アップロード先を実行権限のないディレクトリ・別ドメインにする。

6. 秘密情報の取り扱い

1. APIキー・パスワード・トークンをコード・ログ・エラーメッセージに直接書かない。環境変数または秘密管理サービス経由で読み込む。
2. .envは.gitignoreに登録し、.env.exampleにはキー名のみを記載する。

チェックリスト（実装完了前に確認）

• すべての入力受付点でホワイトリスト方式の検証を行っている
• クライアント側検証だけに頼っている箇所がない
• SQL/クエリはすべてパラメータ化されている（文字列結合によるSQL組み立てがない）
• パスワードは専用ハッシュ関数で保存している
• ログイン成功時にセッションIDを再生成している
• 状態変更リクエストにCSRF対策がある
• テンプレートエンジンの自動エスケープを無効化していない
• ファイルアップロードは拡張子・サイズ・保存名（ランダム化）を検証している
• 秘密情報がコード・ログ・エラーメッセージに直書きされていない

アンチパターン集

アンチパターン	なぜ問題か	代わりにすること
文字列結合でSQL文を組み立てる	SQLインジェクションの直接原因になる	パラメータ化クエリ／プレースホルダを使う
デニリスト（禁止文字の除去）だけで入力検証を済ませる	想定していないパターンで迂回される	ホワイトリスト（許可される値の定義）を主防御にする
クライアント側バリデーションのみで満足する	devtoolsやAPI直叩きで容易に迂回される	サーバー側でも同じ検証をやり直す
パスワードを自前ロジックで暗号化・可逆化して保存	漏洩時に即座に平文復元されるリスク	bcrypt/argon2等の専用ハッシュ関数を使う
アップロードファイル名をそのままサーバーに保存	パストラバーサルや上書き攻撃を許す	ランダムなファイル名を生成して保存する
テンプレートの自動エスケープを「表示が崩れるから」無効化する	XSSの直接原因になる	無効化せず、必要な箇所だけ個別にサニタイズする
エラーメッセージにSQL文やスタックトレースをそのまま含める	攻撃者に内部構造のヒントを与える	ユーザー向けメッセージと内部ログを分離する
APIキーをコードやログに直接出力する	リポジトリ・ログ経由での漏洩リスク	環境変数・秘密管理サービスを使い、ログにマスクする

出典

• OWASP Cheat Sheet Series（CC BY-SA 4.0）— Input Validation, SQL Injection Prevention, Authentication, Session Management各Cheat Sheetの要約
• 上記は要約・手順化したものであり、原文の丸写しはしていない。ライセンス表示義務（CC BY-SA 4.0）に留意すること。