はじめに
目的
本ドキュメントはWebアプリケーションのセキュリティ対策を分かりやすくまとめた実践ガイドです。ログインフォームやファイルアップロードなど、開発現場でよくある機能を例に、脆弱性と対策を具体的に説明します。
対象読者
開発者、運用担当、セキュリティ担当者、学習者向けです。基本的なプログラミングやWebの仕組み（HTTPやHTMLの基本）が分かれば読み進められます。
本書の構成
第2章で重要性と脅威を説明し、第3章でOWASP Top10を扱います。第4〜6章では代表的な脆弱性、認証・認可、セッション管理とCookie設定の実践的な対策を紹介します。
読み方と期待する効果
まず概念を理解し、後でコード例やチェックリストで実装と確認を行ってください。読み終えると、リスクを見つけて基本的な対策を自分で実装できる力が身につきます。
範囲と注意点
暗号技術の詳細やクラウド運用の専門的事項は扱いません。必要に応じて専門家と連携してください。
Webアプリケーションセキュリティの重要性と脅威
なぜ重要か
Webアプリは多くの人が日常的に利用します。オンラインショップの注文情報や会員の個人情報は、サービス運営者にとって重要な資産です。これらが漏れると利用者の信頼を失い、事業に大きな損害が出ます。だからこそ、セキュリティを軽視できません。
主な脅威とわかりやすい例
- SQLインジェクション：検索欄に細工した文字列を入れると、データベースの情報を盗まれます。例として顧客リストが外部に流出する恐れがあります。
- クロスサイトスクリプティング（XSS）：掲示板や入力欄に悪意あるスクリプトを入れると、訪問者のクッキーや画面が乗っ取られます。
- リモートコード実行：脆弱な機能を突かれると、遠隔でサーバー上のプログラムを勝手に動かされます。結果としてサイト改ざんやデータ消失が起きます。
被害の広がり
攻撃は単独で終わらず連鎖します。例えば、情報漏えいが起点となり不正ログインや金銭被害につながります。影響は利用者だけでなく運営側にも及びます。
多層的対策の必要性
一つの対策だけでは不十分です。入力値の検証、適切な認証、権限管理、通信の暗号化などを組み合わせて守ります。定期的な点検と更新も欠かせません。
OWASP Top 10への理解
OWASP Top 10とは
OWASP Top 10は、Webアプリケーションでよく見られる重大な脆弱性をまとめたリストです。開発者や運用担当者が注意すべき代表的な問題を優先順位付きで示します。初心者でも実務でも使いやすいガイドラインです。
順位の意味と見方
順位は発生頻度や影響の大きさで決まります。上位ほど修正の優先度が高いと考えてください。各項目は「どう悪用されるか」「どんな影響が出るか」「どのように対策するか」が説明されています。
代表的な項目（具体例）
- SQLインジェクション: ユーザー入力をそのままSQLに渡すと、データを盗まれたり改ざんされたりします。対策はプレースホルダやパラメータ化クエリの利用です。
- クロスサイトスクリプティング（XSS）: 悪意のあるスクリプトがページに混入すると、利用者の情報が盗まれます。対策は出力時のエスケープやコンテンツセキュリティポリシーの設定です。
- 認証・アクセス制御の欠陥: 認証を簡単に突破されたり、他人の機能にアクセスされたりします。強いパスワード、二段階認証、適切な権限チェックを実装してください。
実務での使い方
- リスク評価: 自分のアプリでどの項目が当てはまるか確認します。2. テスト: ペネトレーションテストや自動スキャンで脆弱性を検出します。3. 優先対応: 上位のリスクから修正します。4. 再検証: 修正後に必ず動作を確認します。
学習と習慣化
各項目を短い時間で学べるように分けて勉強してください。具体的な攻撃例を手元で確認し、防御策を実装してみると理解が深まります。継続してチェックリストを使うと効果的です。
代表的な脆弱性と対策
クロスサイトスクリプティング（XSS）
XSSは攻撃者が悪意あるスクリプトをページに挿入する攻撃です。例：掲示板にalert(1)と書き込まれると、他の利用者のブラウザで実行されます。
対策：
– HTMLエスケープ：< は <、> は > に変換します。出力時に必ずエスケープしてください。
– テンプレートエンジンの自動エスケープ：JinjaやTwigなどは既定で安全化します。
– 入力値検証：必要な文字だけを許可するホワイトリスト方式を使います。
– Content-Security-Policy（CSP）：外部スクリプトやインライン実行を制限します（例：script-src ‘self’）。
SQLインジェクション
SQLインジェクションは不正なSQLを注入してデータを操作する攻撃です。例：’ OR ‘1’=’1’のような入力でログイン回避します。
対策：
– プリペアドステートメント（パラメータ化クエリ）：値と構文を分離します。プレースホルダを必ず使ってください。
– ORMの活用：手書きのクエリを減らせます。
– 入力検証とサニタイズ：許可する形式を確認します。
– 最小権限のDBユーザ：万が一侵害されても被害を抑えます。
CSRF（Cross-Site Request Forgery）
CSRFは利用者の認証情報を悪用して意図しない操作を実行させる攻撃です。例：送金フォームが勝手に送信される。
対策：
– CSRFトークン：フォームごとにランダムなトークンを生成・検証します。
– SameSite Cookie属性：LaxやStrictで外部サイトからの送信を制限します。
– Refererチェック：送信元を確認して許可されているドメインのみ受け付けます。
– AJAXではカスタムヘッダやトークンを送る設計にします。
それぞれの対策は重ねて実施することで効果が高まります。実装時は既存のフレームワークやライブラリの機能を優先して使うと安全です。
認証と認可の実装
概要
強い認証と適切な認可は、Webアプリの安全性の基盤です。ここでは実装の考え方と具体的な対策例を分かりやすく説明します。
認証（Authentication）の実装
- パスワードポリシー
- 最低長を設け（例：12文字以上）、記号や数字の複雑性より長さを重視します。使い回し防止のために履歴を保存します。
- パスワードの保管
- 平文で保存せず、bcryptやargon2などの慢速ハッシュで保護します。ソルトを必ず用います。
- 多要素認証（MFA）
- ワンタイムパスワード（アプリ生成）やハードウェアトークンを推奨します。SMSは便利ですが乗っ取りリスクがあることに注意します。
- アカウントロックアウトとレート制限
- 短時間に繰り返し失敗したら一時ロックや遅延を入れます。IPごとのレート制限も有効です。
- 不審なログイン監視
- 異常なIPや新しいデバイス、地域外ログインを検出して通知や追加認証を行います。ログは追跡とフォレンジックに役立ちます。
認可（Authorization）の実装
- ロールベースアクセス制御（RBAC）
- 役割ごとに権限を定めます。例：管理者、編集者、一般ユーザー。
- 属性ベースアクセス制御（ABAC）
- ユーザー属性やリソース属性、環境（時間帯など）で細かく制御します。柔軟性が高いです。
- 強制アクセス制御（MAC）
- ラベルやポリシーでアクセスを強制的に制限する用途に向きます。軍事系や機密データで使われます。
最小特権の原則と検証
- サーバー側で必ず権限チェックを行い、クライアント側の検証に頼らないでください。これにより不正な操作を防げます。
- デフォルトは拒否（deny-by-default）にし、必要最小限の権限だけを付与します。
- 自動テストやコードレビューで権限ロジックを検証し、ログで不正アクセスの兆候を監視します。
実装チェックリスト（簡易）
- パスワードはハッシュ化しているか
- MFAを主要な操作に導入しているか
- ロールやポリシーが明文化されているか
- サーバー側での権限チェックが徹底されているか
- ログとアラートで不審な挙動を監視しているか
実装は単発の対策で終わらせず、運用での監視と定期的な見直しを続けることが重要です。
セッション管理とCookie設定
セッション管理の基本
Webアプリでは利用者ごとにセッションを管理します。常にHTTPSを使い、通信の盗聴を防いでください。ログインや権限変更の際はセッションIDを再生成し、古いIDを無効化します。セッションの有効期限は短めに設定し、非アクティブ時間で自動ログアウトさせると安全です。サーバー側でセッション情報を管理し、ログアウト時に必ず破棄してください。
セッションIDの扱い方（具体例）
- 例：ログイン成功時に新しいセッションIDを発行する。
- 例：重要操作後はIDを再生成する。
- URLにセッションIDを載せない（GETパラメータやリンクに含めない）。
Cookie設定のベストプラクティス
- Secure属性：HTTPSでのみ送信する。
- HttpOnly属性：JavaScriptから読めないようにする。
- SameSite属性：CSRF対策に有効。Laxは一般的、Strictはより厳格。必要に応じてNoneを使う場合はSecure必須。
- Domain/Pathを狭くし、露出を減らす。
- 有効期限：セッションCookieは短時間、永続Cookieは慎重に。
チェックリスト
- HTTPS化、ID再生成、短いタイムアウト、URLにIDを含めない、Secure/HttpOnly/SameSiteを設定する。これらを実装すればセッション周りのリスクを大幅に下げられます。
