はじめに
本書の目的
本書は、Webアプリケーションを安全に作るための基礎知識と実践的な対策をわかりやすくまとめたガイドです。脆弱性の仕組みを理解し、具体的な実装で防ぐ方法を学べます。例として、ログインフォームや検索欄に対する攻撃とその対策を扱います。
対象読者
Web開発者、運用担当者、セキュリティ初学者を想定しています。高度な理論は最小限にし、具体例と手順を中心に説明します。基本的なHTMLやサーバーの動作を知っていると読みやすいです。
本書の構成と使い方
章ごとに脆弱性の仕組み・危険性・対策を順に示します。実装例やチェックリストを用意しているので、開発中に参照して組み込んでください。テスト手順も含め、まずは身近な機能（ログイン、検索、ファイルアップロード）から確認すると良いです。
注意点
本書は実務で使える実践的なガイドを目指します。学んだ対策をそのまま運用環境へ適用する前に、テスト環境で動作確認を行ってください。
OWASP Top 10と代表的な脆弱性への理解
OWASP Top 10とは
OWASPはWebアプリに多く見られる重大な脆弱性をまとめています。Top 10は業界の指針であり、開発の初期から対策を組み込むためのチェックリストとして役立ちます。
代表的な脆弱性（抜粋）
- インジェクション（例：SQLインジェクション）
- 攻撃者が入力欄に悪意ある命令を入れると、データベースを書き換えられます。対策はパラメータ化されたクエリや入力検証です。
- クロスサイトスクリプティング（XSS）
- ユーザー入力がそのまま表示され、他人のブラウザで悪いスクリプトが動きます。対策は出力時のエスケープやコンテンツセキュリティポリシーです。
- 認証とセッション管理の不備
- パスワード管理やセッションIDの扱いが甘いとなりすましを許します。対策は強いパスワード、HTTPS、適切なセッション期限です。
- セキュリティ設定のミス
- デフォルトのまま運用したり、不要な機能を有効にしたりすると攻撃面が増えます。不要な情報を隠し、最小権限で運用します。
- 既知の脆弱コンポーネント利用
- 古いライブラリに問題があると攻撃されます。対策は定期的な更新と脆弱性スキャンです。
対策を始めるポイント
まずは入力の検証、出力のエスケープ、ライブラリの更新を日常の開発工程に組み込みます。小さな対策を積み重ねることで多くの攻撃を防げます。
SQLインジェクション対策
概要
SQLインジェクションは、入力欄に悪意ある文字列を入れてデータベース命令を変え、情報を盗んだり改ざんしたりする攻撃です。ここでは実務で使える具体的な対策を分かりやすく説明します。
1. プリペアドステートメント（パラメタ化クエリ）の利用
常にプレースホルダーを使い、入力値をSQL文と分離します。例：
– PHP（PDO）やPython（psycopg2）、Java（PreparedStatement）では、値を埋め込まずにパラメータを渡します。これにより特殊文字が命令になりません。
2. 入力検証とエスケープ
受け取る値はホワイトリストで検証します。数値なら数字のみ、日付なら決まった形式だけ許可します。長さ制限も設けます。必要に応じてDB用のエスケープ関数で特殊文字を変換します。
3. 動的SQLの最小化
文字列連結でSQLを組み立てないでください。どうしても動的に組む場合はパラメータ化と厳格な検証を組み合わせます。ストアドプロシージャは使えますが、安全設計が必要です。
4. 権限とエラーハンドリング
アプリ用DBユーザーに最小権限を与えます。詳細なエラー情報は公開しないでください。ログは保管し、異常なクエリを監視します。
5. テストと運用
静的解析やペネトレーションテスト、定期スキャンで脆弱性を見つけます。必要に応じてWAFを補助的に導入します。これらを組み合わせて実運用で守ります。
実装はフレームワークや言語の推奨方法に従ってください。小さな対策の積み重ねが攻撃を防ぎます。
XSS（クロスサイトスクリプティング）攻撃への対策
XSSとは
XSSは、ユーザー入力に悪意のあるスクリプトを混入させ、他の利用者のブラウザで実行させる攻撃です。結果としてセッション情報の窃取や、ページ表示の改ざん、なりすましなどが起きます。
主な攻撃パターン
- 反射型: フォームやURLに入れたスクリプトが即座に返される例です（検索結果にそのまま表示される場合など）。
- 格納型: 投稿やコメント欄に保存され、他ユーザーが閲覧したときに実行されます。
- DOM型: クライアント側の処理で危険な操作を行う場合に発生します。
基本対策：入力検証と出力エスケープ
- 入力ではホワイトリスト（許可する文字や形式）を使います。たとえばメールや日付は正規表現で検証します。
- 出力時は用途に応じてエスケープします。HTMLに出すならHTMLエスケープ、URLに使うならURLエンコードを行います。
- 例: innerHTMLではなく textContent を使うと、ブラウザが自動で安全に扱います。
テンプレートエンジンとライブラリの活用
- 多くのテンプレートエンジンは自動エスケープ機能を持ちます。まずそれを有効にしてください。
- リッチテキストを扱う場合は、DOMPurifyのような専用ライブラリでサニタイズします。
Content Security Policy（CSP）の導入
- CSPは実行できるスクリプトやリソースの制限をブラウザに指示します。例: “Content-Security-Policy: default-src ‘self’; script-src ‘self’ ‘nonce-…’;”
- unsafe-inline を避け、可能なら nonce（ワンタイム値）やハッシュ方式を使うと安全性が上がります。
クッキー設定とブラウザ側の対策
- セッション情報が盗まれないように、クッキーに HttpOnly と Secure を付与します。SameSite 属性も設定しておくと安全性が高まります。
開発上の注意点とテスト方法
- DOM操作では innerHTML や eval を避け、textContent や適切なAPIを使います。
- 自動スキャンツールと手動の検査を組み合わせて脆弱性を発見します。簡単なテスト例として、入力欄に alert(1) を入力して挙動を確認します。
多層の対策を組み合わせることでXSSリスクを大きく下げられます。普段からエスケープとCSP、クッキー設定を意識して開発してください。
CSRF（クロスサイトリクエストフォージェリ）対策
CSRFとは
CSRFは、ユーザーが意図しない操作を第三者のサイトから実行させられる攻撃です。たとえば、ログイン中の銀行サイトで送金ボタンを押す代わりに、攻撃者のページが同じ送金リクエストを勝手に送ると資金が移動します。ブラウザーが自動で送るクッキーが悪用されます。
基本的な対策
-
CSRFトークン：サーバーがランダムな秘密トークンを作り、フォームのhiddenやAJAXのヘッダーに入れます。受信側で一致を確認すれば正当な操作と判断します。トークンはセッションに紐づけ、使い回しを避けるとより安全です。
-
SameSite Cookie属性：クッキーにSameSite=LaxまたはStrictを設定すると、別サイトからのリクエストでクッキーが送られにくくなります。フォーム送信やリンクによる攻撃を抑止できます。
-
Referer/Originチェック：受信リクエストのRefererやOriginヘッダーが自サイトか確認します。HTTPSを利用している場合に有効で、ヘッダー欠落時のフォールバック設計が必要です。
-
ダブルサブミット（double submit）：トークンをクッキーとリクエストボディ両方に置き、照合します。セッションストアを使えないAPIで選択肢になります。
実運用の注意点
- 状態を変える操作（POST/PUT/DELETE）に対策を必須化してください。GETは原則安全な操作に限定します。
- トークンは十分にランダムで長めにし、定期的に更新してください。APIではCookieに依存せずBearerトークンなどを使うと安全性が上がります。
クッキーとセッション管理のセキュリティ
クッキーの役割と注意点
クッキーはユーザーを識別するために使いますが、内容をそのまま保存すると危険です。重要な情報はクッキーに直接入れず、サーバー側で管理したセッションIDだけを保存してください。通信は常にHTTPSにし、平文送信を防ぎます。
セキュアなクッキー設定
- Secure属性：HTTPS通信のときのみ送信します。これで盗聴リスクを下げます。
- HttpOnly属性：JavaScriptから読めないようにします。XSSでの盗難を防ぎます。
- SameSite属性：外部サイトからの不正リクエストを制限します。値はStrictまたはLaxを推奨します。
例（レスポンスヘッダ）:
Set-Cookie: sessionid=abc123; Secure; HttpOnly; SameSite=Strict; Path=/; Max-Age=1800
セッション管理の追加対策
- 有効期限：短めのアイドルタイム（例：15〜30分）と絶対有効期間（例：8時間）を設定します。
- ログアウト処理：ログアウト時にサーバー側でセッションを無効化し、クッキーを削除します。
- セッションIDの再生成：ログインや権限昇格時に新しいIDを発行し、固定セッション攻撃を防ぎます。定期的な再生成も有効です。
- 最小権限と監査：セッションに紐づく権限を必要最低限にし、不審なアクセスはログに残して監視します。
これらを組み合わせることで、セッションハイジャックや固定攻撃のリスクを大きく減らせます。
