説明
例外オブジェクトを文字列に変換した結果やargsの値をHTTPレスポンスにそのまま含めると、ファイルパス、SQLエラー、内部ホスト名、設定値などの実装情報が外部に露出する可能性があります。攻撃者はこの情報を使い、入力検証の回避、インジェクションの調整、環境の調査を行いやすくなります。
想定される影響
- 内部パス、データベース構造、サービス名が明らかになる可能性があります。
- 攻撃者が悪意ある入力を調整しやすくなります。
- 認証や認可の失敗理由が過度に詳しく開示される可能性があります。
対処方法
- 例外の詳細はアクセスを制限したサーバーログに記録し、パスワードやトークンなどのシークレットは除外してください。
- クライアントには一般化したエラーメッセージと適切なステータスコードを返してください。
- Flask、FastAPI、Djangoの共通の例外処理層を使い、エラーレスポンスを統一してください。
- 本番環境ではフレームワークのデバッグ用エラーページを無効にしてください。
例
変更前
python
@app.route("/bad")
def server_bad():
try:
do_computation()
except Exception as e:
return str(e)
変更後
python
@app.route("/safe")
def server_safe():
try:
do_computation()
except Exception:
current_app.logger.exception("request failed")
return "Internal error", 500
説明:
- 変更前: 例外の詳細なメッセージをレスポンス本文にそのまま返します。
- 変更後: 詳細はログだけに残し、ユーザーには一般化したメッセージを返します。