例外メッセージの露出

説明

err.message や err.toString() などの例外の詳細を HTTP 応答の本文やヘッダーにそのまま含めると、内部パス、SQL エラー、設定値、ライブラリの動作に関する情報が漏れる可能性があります。攻撃者はこれらを調査に利用し、後続のインジェクションや実行環境を狙う攻撃を調整できます。

想定される影響

• 内部パス、クエリ構造、ライブラリのバージョン、設定値が外部に漏れる可能性があります。
• エラーメッセージを使って、攻撃者が後続のペイロードを調整する可能性があります。
• 本番環境の例外処理から、サービスの構造を把握されやすくなります。

対処方法

• クライアントには一般的なエラーメッセージを返し、詳細はサーバーログだけに記録してください。
• Express または Node のエラー処理を集約して応答形式を統一し、err.message を直接公開しないでください。
• 応答本文、JSON、ヘッダーのいずれにも例外の詳細を含めないでください。
• 本番環境では開発用のデバッグエラー応答を無効にしてください。

例

変更前

app.get("/profile", async (req, res) => {
  try {
    const profile = await loadProfile(req.user.id);
    res.json(profile);
  } catch (err) {
    res.status(500).send(err.message);
  }
});

変更後

app.get("/profile", async (req, res) => {
  try {
    const profile = await loadProfile(req.user.id);
    res.json(profile);
  } catch (err) {
    logger.error({ err }, "profile load failed");
    res.status(500).json({ error: "Internal server error" });
  }
});

説明:

• 変更前: 例外メッセージを応答に直接含めるため、内部エラーの詳細が外部に漏れます。
• 変更後: 詳細はサーバーログだけに残し、クライアントには一般的なメッセージを返します。

参考資料

• CWE-209