Fickle PDFs：ブラウザごとの描画差を突くPDF攻撃とは何か

本記事は、PortSwigger Researchの「Fickle PDFs: exploiting browser rendering discrepancies」（元ソース）をもとに、同一PDFでも閲覧環境により見え方が変わる“描画差”が業務リスクになる点を解説する。

概要

PortSwigger Researchの提示するシナリオは、経営者（例：CEO）がメールで受け取ったPDF請求書をSafariやmacOSのPreviewで確認すると合計金額が「£399」と表示され、承認してしまう、というものだ。ところが、その後に会計担当など別の環境で扱われたとき、同じファイルにもかかわらず表示（特に金額のような重要情報）が別の形で見えてしまう可能性がある。

ここで本質的なのは「PDFは不変で、誰が見ても同じに見える」という前提が崩れる点にある。承認・支払い・監査といった業務は、最終的に“人が目で見て判断する”工程を含みやすい。表示が環境依存で揺らぐなら、攻撃者はその揺らぎを利用して、承認者には無害に見えるが、後工程では別内容として解釈されるような状況を作りうる。

詳細

この問題は、単なる「PDFの脆弱性」ではなく、「レンダラ（表示エンジン）の実装差」や「表示と抽出の差」が業務プロセスに入り込むことで成立する。たとえば、同じPDFをブラウザ内蔵ビューアで開く場合とOS標準ビューアで開く場合、あるいは別ブラウザで開く場合で、文字やレイアウトの解釈が一致しないことがあり得る。導入例のように、承認者が見る金額と、会計処理の担当者が別環境で見る金額が食い違えば、承認という統制が形式化してしまう。

実務面で厄介なのは、PDFが「添付ファイル」として日常的に流通し、しかも請求書・見積書・契約書など“数字と文言の正確さ”が価値の中心になる用途に多用されることだ。だからこそ、表示の整合性が保証できないPDFは、ソーシャルエンジニアリングの素材として魅力的になる。実際、関連する反応として、デジタル保存界隈の投稿で「次元の違う #wtfPDF だ」といった驚きを示す言及が見られ、現場感としても「PDFは時に想像以上に挙動が読めない」という認識が共有されている。

また、PDFを“Webアプリでレンダリングする”文脈では別種の論点（XSSなど）もあり、閲覧・配信の仕組み次第でリスクの顔つきが変わる。JavaScriptベースのPDFビューアとWebセキュリティの交点を扱った記事では、PDF表示サービスを題材に、PDFの扱い方がセキュリティ問題につながり得ることが語られている。ここから得られる教訓は、PDFを「文書」ではなく「複雑な解釈対象（しかも実装依存）」として取り扱い、表示・抽出・承認の各段階で“何を正とするか”を設計し直す必要がある、という点だ。

対策の方向性は、大きく分けてプロセス面と技術面に整理できる。プロセス面では、重要な数値（合計、振込先、口座、支払期日）について“PDFの見た目”だけに依存しない照合手段を用意することが要点になる。たとえば、発注書や請求管理システム側のデータと突合する、承認対象をPDF添付ではなくシステム画面のレコードに寄せる、二者以上の独立した確認（別レンダラでの確認を含む）を要件化する、といった設計が考えられる。

技術面では、組織内で「承認に使う標準ビューア／標準手順」を統一し、可能なら“同じレンダリング結果”を再現できる環境に寄せることが現実的な第一歩になる。加えて、PDFからのテキスト抽出や金額検出を行う場合は、「抽出結果が表示と一致する」こと自体が前提崩れし得るため、例外検知（不自然な差、レイアウト依存の疑い）を設け、疑わしいケースは人手で追加確認する運用が望ましい。

最終的に「Fickle PDFs」が突きつける問いは、PDFそのものよりも、承認という行為を“表示結果に依存した信頼”として運用していないか、という点にある。PDFは便利な一方で、閲覧環境の差という“静かな不一致”が起き得る。日常業務の当たり前に潜むこのギャップを前提に、承認フローとツール選定を見直すことが、被害を未然に防ぐ近道になる。