【要約】レシートメールを読む道具に脆弱性が3件。2件はメールを送るだけで成立する [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が作成したレシート集計ツールにおいて、外部からの入力値に対する検証が不足していた。メールという制御不能な入力ソースを扱う際、以下の3つの脆弱性が露呈した。
- ・通信経路の脆弱性：imaplibの既定設定により、中間者攻撃でアプリパスワードが漏洩する恐れがある。
- ・CSVインジェクション：メール本文の値をそのままCSVへ出力するため、Excelで開いた際に数式が実行される。
- ・ReDoS：金額抽出用の正規表現が、特定の長い数字列に対して指数関数的な計算量を要する。
// Approach
入力の出所（メール）と出力の解釈（Excel等）を意識した防御策を講じた。単なる機能修正ではなく、データの境界線を意識した実装への変更を行った。
- ・通信の安全確保：ssl.create_default_context()を導入し、ホスト名と証明書の検証を強制した。
- ・CSV出力の無害化：=, +, -, @ 等で始まるセルの先頭に ' を付与し、文字列として扱うよう修正した。
- ・正規表現の最適化：金額の桁数に実用的な上限（{0,19}）を設け、バックトラックの爆発を防いだ。
// Result
脆弱性の修正により、攻撃による認証情報の窃取や、計算リソースの枯渇、意図しないコード実行のリスクを低減した。
- ・ReDoS対策の効果：入力長40,000文字に対し、処理時間を38.694秒から0.0404秒へと劇的に短縮した。
- ・セキュリティ強度の向上：通信経路の信頼性と、出力データの整合性を確保した。
Senior Engineer Insight
> 標準ライブラリへの過信が、致命的な脆弱性を招く。本件は、入力（メール）と出力（Excel）の境界における責任を明確にしている。大規模システムでは、入力の検証だけでなく、出力先がデータをどう解釈するかまでを設計に含めるべきだ。防御的設計こそが、実戦における信頼性を担保する。