nPOP 非公式改良版 セキュリティ確認結果

確認日：2026年11月1日 修正版：1.2.8-2026.11.01-5（32bit／64bit）

確認範囲

今回追加・変更したHTML表示、IMAP受信／本文プレビュー／監視、添付保存、Google OAuth補助機能を中心に、関連する既存処理もソースで確認しました。人工データによる回帰テストと、実際のWebView2エンジンによるHTMLの動作確認を実施しました。

独立した専門機関による監査や、すべてのコードを網羅する検証ではありません。未知の脆弱性がないことを保証するものではありません。実アカウントでの攻撃テスト、実メールサーバーへの診断、第三者部品・Windows・ブラウザーの全CVE照合は実施していません。

修正した問題

1. 外部ブラウザー用HTMLの能動的な内容

修正前は、メールから復号したHTML本文をそのまま一時HTMLファイルに保存してブラウザーへ渡していました。利用者がHTML表示を実行した場合、送信者が埋め込んだJavaScript、フォーム、自動転送や外部資源がブラウザー側で処理される余地がありました。内部HTML表示に設定していた制限は、この経路には適用されていませんでした。

修正後は、本文をトップレベルのファイル文書に直接埋め込まず、権限を許可しないsandbox付きの隔離フレームで表示します。外側の文書にはCSPを設定し、スクリプト、オブジェクト、フォーム送信、ネットワーク宛てのフレーム遷移を制限します。外部画像は既存の「外部画像を許可」設定に従い、許可しない場合は読み込みません。外部表示用HTMLには入力サイズ上限も設けました。

ブラウザーエンジンのスクリプト設定を有効にした状態でも、人工メール中のスクリプトやイベント処理で表示内容が書き換わらないこと、フォーム送信・追跡画像・CSSによる外部参照・外部フレーム・オブジェクト・自動転送が抑止されることを確認しました。明示的に画像を許可した場合だけ、画像リクエストが許可されることも確認しています。テストでは通信を捕捉・遮断し、実サービスへ送信しません。

表示上の変更：外部ブラウザー内のメール本文のリンク遷移も制限します。リンクを開く場合は、nPOPのテキスト表示、または内部HTML表示で操作してください。 古いブラウザーでは隔離表示が利用できない場合があります。更新されたブラウザーを使用してください。元メールや添付ファイルそのものを無害化する機能ではありません。

2. IMAPの継続応答によるメモリ消費

IMAPの1行の長さと本文データには上限がありましたが、複数行のFETCH応答をまとめる文字列には合計サイズの制限がありませんでした。異常な応答を繰り返すサーバーにより、応答完了前にメモリを消費し続ける可能性がありました。

FETCH応答の継続文字列にも4MiBの上限を設け、追加で確保する前にエラーにします。上限超過を拒否し、通常の継続応答は引き続き処理できることをテストしました。確認した影響は可用性（メモリ消費・応答停止）であり、これだけで任意コード実行が可能と確認したものではありません。

追加の防御改善

内部WebView2の資源要求フィルターは、対応するRuntimeではフレーム内の要求にも適用される新しいAPIを使用するようにしました。旧Runtimeでは従来のフィルターに戻し、CSPとスクリプト禁止など既存の制限を併用します。

その他の確認事項

• 添付保存：パス区切り・危険な名前の処理、既存ファイルを上書きしない一括保存、不正なBase64／quoted-printableや途切れた添付の拒否、Mark of the Webの付与処理を確認しました。添付の内容自体をウイルス検査する機能ではありません。
• OAuth：ランダムなstateとPKCE、コールバックのパス／重複パラメーターの検査、ログインアカウントとの照合、Windowsユーザー単位のDPAPI保存、Gmailの指定ホストと検証付きTLSの強制を確認しました。コード・トークン・シークレットは実行引数で渡しません。
• IMAP：アカウント／UID／UIDVALIDITY／キャッシュの照合、部分受信の長さ制限、認証文字列の制御文字拒否、明示操作による削除のUIDPLUS制約を確認しました。
• 内部HTML：スクリプト・ホストオブジェクト・Webメッセージの禁止、権限要求の拒否、利用者操作のあるHTTP／HTTPS／mailtoリンク以外を外部起動しない処理を確認しました。
• 32bit／64bitの実行ファイルは、ASLR・DEPに対応するPEフラグを確認しました。

残る課題と運用条件

1. 通常の保存パスワードは強い保管方式ではありません。 従来互換のINIでは、ユーザー名由来の値を使った可逆の難読化を利用しており、INIを読める第三者に対して秘密を保護する方式ではありません。今回、この保存形式は変更していません。INI・メールデータ・バックアップを第三者に公開しないでください。Google OAuthトークンのDPAPI保存とは別の仕組みです。
2. 通常のパスワード認証では、非暗号化通信や証明書検証を無効にする設定も残っています。TLS／STARTTLSと証明書検証を有効にしてください。旧TLSを明示的に選ぶ設定や、OSのTLSポリシーにも注意が必要です。
3. 外部画像の許可を有効にすると、送信者のサーバーへ画像の取得要求が届くため、開封の推測やIPアドレスの記録が可能になります。
4. WebView2 Runtimeと外部ブラウザーの更新は、利用環境側で必要です。同梱Loader DLLの版番号は、利用中のRuntimeの版番号とは異なります。

検証

• 32bit・64bitのReleaseビルド。
• 両アーキテクチャの既存回帰テスト一式（MIME、添付、POP、IMAP、アカウント分離、OAuth、画面操作、保存先など）。
• 新規のIMAP FETCH応答合計サイズ上限の回帰テスト。
• 両アーキテクチャの実WebView2による外部HTML文書の制限テストと、内部HTML表示テスト。
• 配布ZIPの整合性、実行ファイルの版番号・アーキテクチャ・一致確認、個人設定／メールデータを同梱していないことの確認。

公開用一式には実行ファイル版のみを含めます。ソースコード版は公開用一式に含めません。

参照した公式資料

• Microsoft：Develop secure WebView2 apps

https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/security

• Microsoft：ICoreWebView2_22（フレームを含む要求フィルター）

https://learn.microsoft.com/en-us/microsoft-edge/webview2/reference/win32/icorewebview2_22

• MDN：CSP sandbox（meta要素内のCSP sandboxは非対応。そのため隔離にはiframeのsandbox属性を使用）

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Security-Policy/sandbox

2026-11-02 改訂20の追加確認

上記は従来版を対象とした記録です。改訂20では受信・SMTPパスワードに従来互換／DPAPI／マスター方式の選択を追加しました。合成データだけを使い、32bit・64bitのローカル試験でPBKDF2の独立した参照値、GCM／DPAPIの往復、値の改変・アカウント欄・項目・ユーザーの不一致、Unicode、マスターの変更と誤入力、実際の設定ダイアログでの3方式移行、再起動時解除とキャンセル、保護を弱める変更の拒否、旧欄の削除、INI置き換え失敗時の元ファイル保持を確認しました。回帰試験も実行しています。実際の認証情報やメールは使っていません。独立した第三者監査ではありません。詳しくはメールパスワードの保護方式をご覧ください。