IPA「安全なウェブサイトの作り方」の対応について

この記事は2025年5月13日時点のチェックとなります。

本資料は IPA（独立行政法人情報処理推進機構）が策定した「安全なウェブサイトの作り方 改訂第7版」に基づき、「ボイテキ！」のセキュリティ対策について記載しています。

https://www.ipa.go.jp/security/vuln/websecurity/about.html

SQLインジェクション

SQL文の組み立てはすべてプレースホルダで実装していますか？
はい、すべてのSQLクエリでプレースホルダを使用しており、パラメータ化クエリによる安全な実装を徹底しています。
SQL文の構成を文字列連結で行う場合、アプリケーションの変数をSQL文のリテラルとして正しく構成していますか？
はい、やむを得ずSQL文を文字列連結で構築する場合でも、入力値のエスケープや型検証を適切に行い、SQLインジェクションのリスクが生じないよう厳重に管理しています。
ウェブアプリケーションに渡されるパラメータにSQL文を直接指定していませんか？
はい、ウェブアプリケーションに渡されるパラメータがSQL文に直接影響しないよう、以下のような多層的なセキュリティ対策を講じています：

  • パラメータの型チェック
  • パラメータ化クエリの使用
  • 入力値のバリデーション（長さ・形式・禁止文字など）
  • 認証および認可の確認

これらの対策により、危険な実装や脆弱性の発生を未然に防止しています。

エラーメッセージをそのままブラウザに表示していませんか？
はい、システム内部の詳細情報（スタックトレースやSQLエラーなど）は表示せず、ユーザーにとってわかりやすく簡潔なエラーメッセージを表示する実装となっています。これにより、攻撃者に情報を与えないよう配慮しています。
データベースアカウントに適切な権限を与えていますか？
はい、アプリケーションが利用するデータベースアカウントには必要最小限の権限（SELECT、INSERT、UPDATE、DELETE）のみを付与しています。
他の操作や不要なデータベースへのアクセス権限は付与しておらず、「最小権限の原則」に基づいた安全な運用を実現しています。

OSコマンド・インジェクション

シェルを起動できる言語機能の利用を避けていますか？
はい、コード内では subprocess モジュールを使用していますが、実行するコマンドの引数はすべて固定値または信頼されたデータベース由来の値を用いています。
特に、ffprobe などのOSコマンドを呼び出す箇所では、引数リスト形式（subprocess.run(["ffprobe", ...]) など）で実行し、シェルを介さない安全な方法を採用しています。これにより、ユーザー入力が直接コマンドに渡されることを確実に防止しています。
シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可した処理のみを実行するようにしていますか？
はい、やむを得ずシェルを起動する必要がある場合でも、引数に含まれるすべての変数に対して厳格な検証・制限を行っています。
ホワイトリストによるコマンド制御や、入力値のサニタイズ処理を適切に実施し、許可された操作のみが実行されるように設計されています。

パス名パラメータの未チェック／ディレクトリ・トラバーサル

外部からのパラメータでウェブサーバ内のファイル名を直接指定する実装を避けていますか？
はい、以下の対策により、外部パラメータによってウェブサーバ内のファイル名が直接指定されることはありません：

  • すべてのファイル操作は、事前に定めた固定ディレクトリ内でのみ実行
  • ファイルパスは環境変数などから取得した固定値を使用
  • アップロードされたファイルは安全な方法で処理され、指定ディレクトリに保存
  • データベースから取得するファイルパスも許可されたディレクトリ内に限定
ファイルを開く際は、固定のディレクトリを指定し、ファイル名にディレクトリ名が含まれないようにしていますか？
はい、以下の対策により、安全なファイル操作を実現しています：

  • 固定ディレクトリの指定：
    – 環境変数で固定ディレクトリを指定し、それ以外の場所へのアクセスを防止
    – ベースディレクトリ内にパスが収まっているかを厳密に検証
  • ファイル名の正規化と検証：
    – ディレクトリ区切り文字（/、\）や .. などを含まないことを確認
    – 危険な文字を除去し、安全な文字列に変換
    – ディレクトリ部分を除外し、ファイル名のみを抽出
  • 安全なファイル操作の実装：
    – 一時ファイルの使用や検証を通じ、安全な書き込み処理を実装
    – ファイルパスの正規化と安全性の確認を徹底
ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理していますか？
はい、以下のようにファイルやディレクトリのアクセス制御を適切に管理しています：

  • ディレクトリ構造の設計：
    – 公開不要なファイルはルートディレクトリ外に配置
    – 公開が必要なファイルのみ、ウェブサーバのルートディレクトリに配置
    – 機密性の高いファイルは、外部アクセス不能な場所に保存
  • アクセス権限の設定：
    – 実行ユーザーには必要最小限の権限のみを付与（最小権限の原則）
    – ファイルの所有者・グループ・パーミッション（例：755、644）を適切に設定
  • セキュリティ対策：
    – ディレクトリリスティングの無効化
    – 不要なファイルへのアクセス制限
    – アクセス権限の定期監査
ファイル名のチェックを行っていますか？
はい、ファイル名に関しても以下のような多段階のチェックを行い、セキュリティを確保しています：

  • ファイル名の検証：
    – 危険な文字（/、\、..など）が含まれていないことを確認
    – ファイル名の長さを制限し、許可された文字のみが使用されているか検証
  • ファイル名の正規化：
    – ディレクトリ名や相対パスを除去し、ファイル名のみを抽出
    – 特殊文字や連続ドットを適切に処理し、安全な名前に変換
  • 拡張子の検証：
    – 許可された拡張子のみを使用許可
    – 拡張子とファイル内容の整合性を確認
    – 不正な拡張子のアップロードを防止

これらの対策により、ファイル名を起点としたセキュリティリスクを効果的に防止しています。

セッション管理の不備

セッションIDを推測が困難なものにしていますか？
はい、以下の対策により、セッションIDの安全性を確保しています：

  • セッションIDの生成：
    – 暗号学的に安全な乱数生成器を使用
    – 128ビット以上の十分な長さを持つ
    – 予測不可能な値を採用
  • セッションIDの管理：
    – セッションIDの定期的な更新と再利用の禁止
    – 安全な保存方法による漏洩防止
  • セキュリティ対策：
    – Cookieには Secure および HttpOnly 属性を設定
    – 有効期限の設定と、推測・総当たり攻撃への対策を実施
セッションIDをURLパラメータに格納していないですか？
はい、セッションIDの漏洩リスクを最小限に抑えるため、以下の対策を講じています：

  • 保存方法：
    – セッションIDはURLパラメータに含めず、Cookieに保存
    – Cookieには Secure、HttpOnly を設定し、JavaScriptからのアクセスを防止
  • セキュリティ設計：
    – URLでのセッションID伝播は禁止
    – 適切なルーティング設計とHTTPS通信により漏洩を防止
  • 監査とテスト：
    – セッション管理に関するコードレビューとセキュリティテストを定期的に実施
HTTPS通信で利用するCookieにはSecure属性を加えていますか？
はい、HTTPS通信の安全性を確保するため、以下の設定を行っています：

  • Cookieの設定：
    – Secure 属性を必ず設定し、HTTPS通信でのみ送信
    – HttpOnly 属性を設定し、JavaScriptからの不正アクセスを防止
    – SameSite 属性を Strict に設定し、CSRF攻撃を防止
  • セキュリティ対策：
    – すべての通信をHTTPSで暗号化
    – Cookieの有効期限と安全な削除処理の実装
  • 監査と確認：
    – Cookie設定の監査と、変更管理・セキュリティテストを実施
ログイン成功後に、新しくセッションを開始していますか？
はい、以下のセキュリティ対策により、ログイン後のセッション管理の安全性を確保しています：

  • ログイン時の処理：
    – 既存のセッションを無効化し、新たにセッションIDを発行
    – セッション情報の初期化と再利用の防止
  • セキュリティ対策：
    – セッション固定攻撃（Session Fixation）を防止
    – 古いセッションからの情報漏洩を防止
  • 監査と確認：
    – セッション処理のコードレビューと定期監査を実施
ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移ごとにその値を確認していますか？
はい、以下の対策により、CSRF等の攻撃を防止しています：

  • CSRFトークンの導入：
    – ログイン後、セッションIDとは別に秘密情報（CSRFトークン）を発行
    – 各ページ遷移時にトークンを検証し、不一致があればセッションを無効化
  • セキュリティ対策：
    – CSRF、セッション乗っ取り、不正遷移の防止を実施
  • 監査と確認：
    – 認証関連処理のコードレビューおよびセキュリティテストを定期的に実施
セッションIDを固定値にしていませんか？
はい、現在の実装では、セッションIDは固定値ではなく、動的に生成されています：

  • JWTトークンを使用し、毎回ログイン時に新しいトークンを発行
  • トークンには有効期限（exp）を含め、安全なセッション管理を実現
  • 必要に応じてリフレッシュトークンを使用し、セッション継続を安全に制御
セッションIDをCookieにセットする場合、有効期限の設定に注意していますか？
はい、セッションの有効期限についても以下の通り適切に設定されています：

  • アクセストークンの有効期限は 8 時間に設定
  • Cookieには Secure 属性と SameSite=Strict 属性を設定
  • ログアウト時にはCookieを確実に削除し、セッションの残留を防止

クロスサイト・スクリプティング

ウェブページに出力するすべての要素に対して、エスケープ処理を施していますか？
はい、以下の対応を実施しています：

  • DOMPurifyを使用した包括的なサニタイズ処理
  • 許可タグ・属性の厳格な制限
  • HTMLエスケープ処理の基本実装
出力するURLは「http://」または「https://」で始まるものに限定していますか？
はい、以下の制御により信頼できるURLのみを許可しています：

  • プロトコルの厳格な検証
  • 許可されたホスト名のみを使用
  • CSPヘッダーによる接続制限
<script> 要素の内容を動的に生成していませんか？
はい、以下の対策によりスクリプトの不正実行を防止しています：

  • スクリプトタグの自動除去
  • Content Security Policy（CSP）による実行制限
  • 動的コンテンツのサニタイズ処理
任意のスタイルシートを外部サイトから取り込むことを防いでいますか？
はい、スタイルに関しても以下の制限を設けています：

  • 許可ドメインのみに限定
  • CSPによる外部スタイルシートの制限
  • 外部リソースへの接続検証
入力値の内容チェックを実施していますか？
はい、以下のような検証を行っています：

  • 必須項目チェック
  • 文字数の制限
  • 正規表現によるパターンマッチ検証
  • 許可文字のみの制限
HTMLテキストの構文解析を行い、必要な要素のみを抽出していますか？
はい、以下のように安全な要素のみを抽出しています：

  • DOMPurifyによる構文解析
  • 許可タグの厳格制限（例：b, i, em, strong, a）
  • 許可属性の限定（例：href, target, rel）
  • 危険な要素の自動除去
スクリプトに該当する文字列をHTMLから排除していますか？
はい、以下の通りスクリプト関連のコードを無効化しています：

  • スクリプトタグの自動除去
  • イベントハンドラ属性（on*）の禁止
  • インラインスクリプトの検出・除去
  • 禁止タグの明示的な指定
Content-Typeヘッダーに文字コードを指定していますか？
はい、文字化けや不正解釈を防ぐため以下を設定しています：

  • Content-Type ヘッダーに UTF-8 を明示
  • 文字コードの適切な統一設定
  • レスポンスヘッダーの一貫性を保持
Cookie情報の漏えいを防ぐため、HttpOnly属性やTRACEメソッドの制限を行っていますか？
はい、以下の対策によりCookieの保護を行っています：

  • HttpOnly 属性の設定
  • Secure 属性によるHTTPS限定通信
  • SameSite=Strict によるCSRF対策
  • TRACE メソッドの無効化
ブラウザのセキュリティ機能を有効化するためのヘッダーを返していますか？
はい、以下のセキュリティヘッダーを設定しています：

  • X-XSS-Protection ヘッダーの有効化
  • X-Content-Type-Options ヘッダーの設定
  • X-Frame-Options によるクリックジャッキング防止
  • その他ブラウザセキュリティ機能の有効化

CSRF（クロスサイト・リクエスト・フォージェリ）対策

処理を実行するページはPOSTメソッドでアクセスし、hiddenパラメータに秘密情報を含めていますか？
はい、以下の対策を実装しています：

  • CSRFトークンの自動生成と検証
  • フォーム送信時にトークンをhiddenパラメータとして付与
  • サーバーサイドでのトークン検証
  • セッションごとに一意なトークンを管理し、使い回しを防止
重要な処理の前に再度パスワードの入力を求めていますか？
はい、重要操作の実行前にはユーザーの正当性確認のため、以下の対策を実施しています：

  • 再認証要求の導入（例：再度パスワードの入力）
  • パスワード再入力の強制
  • セッションタイムアウトによる自動ログアウト設定
  • 必要に応じた二段階認証（2FA）の実装
Refererヘッダーを検証して、正しいリンク元からのみ処理を実行していますか？
はい、リクエスト元の正当性を確認するため、以下の対策を実施しています：

  • Refererヘッダーの正確な検証
  • 許可されたドメインからのリクエストのみに限定
  • 不正なリンク元からのリクエストは拒否
  • 不正アクセスの試行はセキュリティログに記録
重要な操作を行った際に、その内容をユーザーにメールで通知していますか？
はい、操作の追跡と不正検知のため、以下の仕組みを実装しています：

  • 重要操作時の即時メール通知
  • リアルタイムのアラートシステム
  • 操作履歴のログ記録と監査対応
  • 不正アクセス・操作検知時の即時通知

HTTPヘッダ・インジェクション対策

ヘッダの出力を直接行わず、適切なAPIを使用していますか？
はい、HTTPレスポンスヘッダの安全な出力のため、以下の対策を実施しています：

  • Next.jsに組み込まれたヘッダー出力APIの使用
  • セキュアなレスポンスヘッダーの定義と管理
  • X-Content-Type-OptionsやStrict-Transport-Securityなどのセキュリティヘッダーの自動付加
  • アプリケーション層でのヘッダー操作を禁止し、安全なAPIに限定
ヘッダー出力用APIが使用できない場合、改行を許可しない実装を行っていますか？
はい、APIの制約がある場合にもインジェクション対策を講じています：

  • 改行コード（CR、LF、CRLF）の検出と削除
  • ヘッダー値のサニタイズ処理（不正文字の除去）
  • ヘッダー出力前のフィルタリングルールの適用
  • ヘッダー値の形式制限（ASCII制御文字の排除など）
外部からの入力に改行コードが含まれていないかチェックし、除去していますか？
はい、すべての外部入力に対して以下のセキュリティ対策を実施しています：

  • 入力値に対する自動サニタイズ処理の実装
  • 改行コード（\r、\n）の一括除去
  • 不正な制御文字の検出と遮断
  • 入力時・保存時・出力時のセキュリティチェックを実施

メールヘッダ・インジェクション対策

メールヘッダを固定値とし、外部からの入力はすべて本文に出力していますか？
はい、メールヘッダの安全性を確保するため、以下の対策を実施しています：

  • Amazon SESの標準メール送信機能を使用
  • メールヘッダはSES側で安全に管理
  • テンプレートベースでの送信処理を採用
  • 外部入力値は本文のみに使用し、ヘッダーには一切反映しない構成
Webアプリケーションに用意された安全なメール送信用APIを使用していますか？
はい、標準の安全なAPIを使用して以下のように実装しています：

  • Amazon SESの標準APIを使用
  • AWS SDK経由でメール送信を実行
  • 認証済みアカウントからの送信のみ許可
  • HTTPS経由のセキュアな通信を利用
HTMLで宛先メールアドレスを直接指定していませんか？
はい、宛先管理の安全性を保つため、以下の制限を設けています：

  • SESのテンプレート機能を使用し、宛先はサーバー側で制御
  • Cognitoなどと連携した認証ユーザーのみに送信許可
  • セキュアな管理により、HTML側での自由入力は不可
外部からの入力に含まれる改行コードを除去していますか？
はい、メールヘッダへのインジェクションを防止するため、以下のような入力制御を行っています：

  • SESテンプレート機能による自動サニタイズ
  • 改行（CRLF）コードの一括除去
  • 不正文字や改行の事前検出と拒否
  • テンプレートベースでの安全な本文出力処理

クリックジャッキング対策

HTTPレスポンスヘッダにX-Frame-Optionsを出力し、他ドメインからのframeやiframeによる読み込みを制限していますか？
はい、クリックジャッキング防止のため、以下の対策を実施しています：

  • X-Frame-Options: DENY ヘッダーの設定により、フレーム埋め込みを完全に拒否
  • Content-Security-Policy（CSP）の frame-ancestors 'none' 設定を併用
  • 同一オリジン外からのframe/iframe読み込みを制限
  • すべてのHTMLレスポンスに対して一貫してヘッダーを出力
重要な操作の前に、再度パスワードの入力を求めていますか？
はい、操作の正当性を確認するため、以下のような対策を導入しています：

  • 重要操作時には再認証を要求
  • パスワードの再入力を必須とする実装
  • セッションタイムアウト後の自動ログアウト機能を搭載
  • 必要に応じた二段階認証（2FA）の導入
重要な操作は、マウス操作のみで完了できないようにしていますか？
はい、クリックジャッキング防止の補完策として、以下の操作制限を実装しています：

  • ユーザー名やパスワードのキーボード入力を必須化
  • 2FAトークンの手動入力を必要とする設計
  • マウス操作のみで完了できるUI操作を制限
  • キーボード操作の検出によって認証性を強化

バッファオーバーフロー対策

直接メモリにアクセスできない言語で記述していますか？
はい、メモリ安全性を確保するために以下の言語と機能を採用しています：

  • TypeScript / JavaScript を使用し、直接メモリ操作を回避
  • ガベージコレクションによる自動メモリ管理
  • メモリ制御を抽象化する言語機能の活用
  • 安全なメモリ操作のみを許容するアーキテクチャを採用
直接メモリにアクセスできる言語を使用する場合、該当箇所を最小限にしていますか？
はい、必要な場合でも危険な領域の利用を最小限に抑える工夫を行っています：

  • フロントエンドはTypeScript/JavaScriptで構成
  • バックエンドにはPythonを主に使用（安全な動的言語）
  • ネイティブコード（C/C++など）の利用はごく一部に限定
  • 安全性の高い言語構造・型チェック機能を活用
脆弱性が修正されたバージョンのライブラリを使用していますか？
はい、サードパーティライブラリに関しても以下の対策を講じています：

  • package.json による依存関係の明示管理
  • npm audit による脆弱性の定期スキャンとレポート
  • 検出されたセキュリティパッチの速やかな適用
  • 常に安定版かつセキュアな最新版ライブラリを使用

アクセス制御・認可制御の欠落対策

機密情報へのアクセスには、パスワード入力などの認証機能を設けていますか？
はい、アクセス制御が必要なウェブサイトに対して、以下の認証機能を実装しています：

  • AWS Cognito を活用した認証機能の導入
  • パスワードベースのユーザー認証の実装
  • 二段階認証（2FA）による強固な本人確認
  • セッションの発行と管理による継続的な認証状態の保持
認証後のユーザーに対して、適切な認可制御を実装していますか？
はい、認証されたユーザーが他人の権限で操作を行うことがないよう、以下の認可制御を行っています：

  • JWT（JSON Web Token）によるユーザー認可の実装
  • ユーザーごとのロール・権限に基づくアクセス管理
  • セッションの一意性保持と整合性の確保
  • アクセストークンの検証処理による改ざん防止
TOP