搭乗券の投稿でアカウントが乗っ取られる：QRコードの隠し方を実測した
チケット1枚から、どこまで引き出せるか
まず仮定の話ではなく、記録された実例から始めます。
セキュリティ記者のBrian Krebsが2015年に分析記事を書いています。Coryという読者が、友人がFacebookに投稿した搭乗券の写真を見つけ、スクリーンショットを撮ってバーコード部分を拡大し、ネット上の無料バーコードデコーダに通した。数秒後、その友人のマイレージ会員情報が手元にありました。
問題はその後です。Coryはそのアカウントに紐づくすべての将来のフライトを閲覧でき、発券済み乗客の座席を変更でき、今後のフライトをキャンセルすることまでできた。さらにこの情報は、航空会社の「PINを忘れた場合」の再設定フローの前半を通過するのに十分でした。
友人はただ、搭乗券を嬉しそうに投稿しただけです。
多くの人が見落としているのはここです。バーコードやQRコードは装飾ではなく、機械可読のデータ容器です。 あなたが見ているのは白黒の四角の集合ですが、スキャナが見ているのは予約番号、氏名、便名、日付、座席。この落差がリスクの本体です。
半分隠しても無意味：どこまで隠せば読めなくなるか実測した
いちばん書きたかったのがこの節です。間違った隠し方は、何もしないより危険だから——安全になったと信じて投稿してしまう。
QRコードは仕様として強力な誤り訂正機能を持っています。符号の一定割合が破損・汚損・遮蔽されても、スキャナが完全なデータを復元できるよう設計されている。現実世界では便利な性質です（折れたチケットや印刷のかすれでも読める）。しかし「半分隠せば大丈夫だろう」という場面では、これがそのまま脆弱性になります。
そこで自分で測ってみました。
どのくらいの面積を隠せば、本当に読めなくなるのか
手順は再現可能です。Pythonのqrcodeライブラリで、予約番号と認証コードを含むURLを内容とする模擬バウチャーQRコードを生成し、誤り訂正レベルM（15%）、Q（25%）、H（30%）の3種類を用意。それぞれに4種類の隠し方と7段階の面積比を適用し、OpenCVのQRCodeDetectorで復号を試みました。元のURLを完全に復元できた場合のみ「読み取れた」と判定しています。
結果は予想より悪いものでした。
| 隠し方 | M（15%）で失効する面積 | Q（25%）で失効する面積 | H（30%）で失効する面積 |
|---|---|---|---|
| 中央を黒塗り | 15% | 20% | 25% |
| 右下隅を黒塗り | 20% | 25% | 25% |
| 横線で消す | 10% | 20% | 20% |
| 中央にモザイク | 15% | 20% | 25% |
表の読み方：その割合が「読めなくなり始める」境界で、それ未満はすべて読み取れています。
記録しておく価値のある発見が3つあります。
第一に、誤り訂正レベルの高いチケットは、面積の5分の1を隠しても読み取れる。Hレベルで20%を隠した場合、中央の四角・隅の四角・モザイクの3方式すべてが復元に成功しました。スクリーンショット上でそれなりの大きさの四角を塗ったつもりでも、実際には何も遮蔽できていません。
第二に、モザイクと黒塗りの結果がほぼ完全に一致した。3つのレベルすべてで失効する面積が同一でした。「モザイクなら少なくとも何もしないよりまし」という直感は成立しません。安全性は上がらず、処理したように見えるだけです。
第三に、4方式のうち横線がもっとも有効だった。Mレベルでは高さ10%分の横線1本で読めなくなります。横線は符号の幅全体を横断するため、破壊されるデータブロックが複数の符号化区画に分散するのに対し、一箇所に集中した四角は誤り訂正がもっとも強い範囲にちょうど収まってしまうからです。
正直に言うと、3番目は当初書こうとしていた結論と逆でした。「チケットに線を引いても無効化されない」という注意喚起は正しい——それはチケットの有効性とデータの可読性についての指摘です。しかし「どの塗り方がスキャナを止めやすいか」という問いなら、このデータは横線が四角に勝ると答えます。実際に測らないと分からない差です。
どこを隠すかが、どれだけ隠すかより重要
もっとも実用的な発見は最後の検証で出ました。
QRコードの3つの角にある大きな四角は位置検出パターン（ファインダパターン）で、スキャナはこれを頼りに向きと境界を判定します。左上のひとつを覆ったところ、3つの誤り訂正レベルすべてで復号に失敗しました——この部分は画像全体のわずか2.0〜3.6%の面積しかありません。
言い換えると、正しい位置の2%を隠すほうが、間違った位置の20%を隠すより効果的です。
この検証の限界も明示します。使用したのはOpenCVのデコーダ、単一のペイロード、単一バージョンのQRコードです。商用スキャナやスマートフォンのカメラは実装が異なり、復元能力がより高い可能性があります。上記の閾値は保証値ではなく下限として扱ってください。現実の攻撃者が使うデコーダは、私の検証環境より寛容である可能性が高い。
実務上の基準は1行です。符号全体を不透明な塗りで、縁をはみ出すまで覆う。 角だけでも、線数本でも、モザイクでもない。手元のツールで完全な塗りつぶしができない場合は、せめて3つの位置検出パターンのうち1つを完全に覆ってください。
きれいに隠せていないなら、隠していないのと同じです。
旅行のスクリーンショットに潜む3層
旅行で撮るスクリーンショットは、リスクの性質も対処法も異なる3層に分けられます。
| 層 | 主な発生源 | 漏れる内容 | 最悪の場合 |
|---|---|---|---|
| 第1層：スキャン可能な引換証 | Klook・KKdayの電子バウチャー、電子チケット、搭乗券 | 引換証本体、予約番号、マイレージ会員情報の手がかり | 先に使用される、アカウント乗っ取り |
| 第2層：文字による識別情報 | Trip.com・Agodaの予約確認、予約番号、部屋番号 | 氏名、宿泊日、宿泊先住所 | なりすまし電話、ソーシャルエンジニアリング |
| 第3層：画像に埋め込まれたデータ | 画面を別の端末で撮影した写真 | EXIFのGPS座標、撮影時刻、機種 | 現在地や自宅の推定 |
第1層が最も急を要します。電子バウチャーの価値は符号そのものにあり、先にスキャンされると現地で初めて失効に気づく。ネット上の公演チケット画像を盗み、改変して購入希望者を騙す事件も実際に起きています。被害者は投稿した本人だけではありません。
第2層は一見無害で、実際にはソーシャルエンジニアリングの燃料です。氏名と宿泊日と施設名が揃えば、本人を装ってフロントに電話して予約を変更させることも、逆に施設を装って本人に電話し「カード情報の再確認」を求めることもできる。この種の詐欺は旅行の繁忙期に増えます。
第3層はもっとも見落とされます。スマホのスクリーンショットに通常GPSは含まれませんが、画面をもう1台の端末で撮影した場合、その写真には撮影時の座標が付きます。パソコンの画面を誰かに送るときに起きがちです。
同行者に行程を見せたいときの手順
これが現実的にいちばん困る部分です。行程情報は本来共有が必要で、同行者は集合時刻もチケット内容も宿の住所も知る必要があります。
優先順位はこうです。
第一選択はプラットフォーム純正の共有機能。 Klook、KKday、Trip.comなどの多くは、予約を同行者に共有・譲渡する機能を持っています。公式の経路なら引換証の有効性はプラットフォーム側で管理され、出回るスクリーンショットが生まれません。
第二選択は画像ではなくテキストを送ること。 「9/26 朝9時、正門集合、チケットは私が持っています」——必要な情報はすべて含まれていて、リスクはゼロです。
第三選択が、保護をかけた画像の共有。 複雑な行程表や地図など、どうしても画面が必要な場合はアクセス制御のある方法を使い、公開投稿に貼らないでください。
lpic.ccならアップロード時に閲覧パスワードを設定でき、短縮リンクが転送されてもパスワードがなければ開けません。パスワードはbcryptでハッシュ化して保存されており、平文比較ではありません。「この5人にだけ見せたい」行程画像には、グループに投げて自由に流通させるより制御が効きます。
制限も先に書きます。画像1枚8MBまで、ファイルは最後に閲覧されてから30日で削除、アップロード時に自動で最適化されるため元ファイルは保持されません。そして——パスワードは見るべきでない人を止められますが、閲覧権限のある人がスクリーンショットを撮って転送するのは止められません。どの共有手段にもこの天井があります。万能だと思わないでください。
最後の防衛線は結局これです。本当に機微な引換証は、最初から画像ファイルにしないこと。
よくある質問
Q1：搭乗券をだいぶ前に投稿してしまいました。今から削除しても意味はありますか。
削除で今後の露出は減りますが、誰も取得していないと仮定はできません。それより重要なのは2つ。当該航空会社アカウントのパスワードと秘密の質問の答えをすぐに変更すること、そして今後の予約に不正な変更がないか確認することです。Krebsの事例で攻撃者が最初にできたのが、座席変更と便のキャンセルでした。
Q2：Klookのバウチャーを他人にスキャンされた場合、現地で入場できますか。
チケット種別によります。1回限りの引換証が先に使用されていれば、現地では使用済みと表示されます。すぐにプラットフォームのサポートに連絡すべきですが、結果は保証されず、繁忙期は対応も遅い。予防のほうが圧倒的に確実な領域です。
Q3：QRコードにモザイクをかければ十分ですか。
不十分で、実測しました。3つの誤り訂正レベルすべてで、モザイクと黒塗りの失効閾値が同一でした——高レベルのチケットでは面積の25%を隠すまで読み取れます。符号領域全体を不透明な塗りで覆うか、より確実には撮影時点で物理的に遮蔽してください。
Q4：予約確認に予約番号と氏名しかない場合もリスクはありますか。
あります。氏名と予約番号の組み合わせは、一部のプラットフォームで予約状況の照会に足ります。そこに宿泊日が加われば、ソーシャルエンジニアリングの材料としては十分です。実際の事例で繰り返し現れるパターンは、攻撃者がパスワードを必要とせず、サポート担当を説得できるだけの断片情報を集めるというものです。
Q5：旅行写真そのものはどうですか。
リスクの性質が違います。写真側の主な問題はEXIFのGPS座標です。多くのSNSはアップロード時にEXIFを除去しますが、クラウドドライブや「オリジナルファイルを送信」経由では完全に保持されるのが普通です。各サービスの扱いは8つの画像サービスのEXIF保持を項目別に検査した記事にまとめてあります。