強い鍵の、
その先も守ろう。
パスキーの次は、ログイン状態にも注目！
Cookie・期限・止め方を、やさしくチェック。
マキ・ロゼ・ツナ・安全ねこと、やさしく確認！
Cookie乗っ取りと金融機関の対策を、公式資料といっしょに整理します。公式情報の確認日：2026年10月3日
パスキーにしたら、もう乗っ取りは心配しなくていいと思っていたよ。「Cookieを盗まれる」って、どういうこと？
パスキーは、ログインの入口を守る強い鍵。そのあとサービスが渡す「ログイン済みの通行証」は別の守りが必要なんだ。鍵を弱めるのではなく、端末とログイン後も一緒に守ろう。
今、知りたいのは？
カードを選ぶと、先に読む場所を案内します。記事は、そのまま全部読めます。
パスキーは「鍵」。
セッションは「通行証」。
ログインを認証
状態を維持
追加認証など
毎ページでログインし直さなくていいのは、通行証があるからか。それをコピーされると、本人みたいに扱われる場合があるんだね。
ブラウザはCookieという小さなデータを保存します。表示の好みを覚えるものもあれば、ログイン状態に関わるものもあります。すべてのCookieが通行証というわけではありません。 セッションは「ログイン済みとして扱う状態」、Cookieはそれを維持する手段の一つです。アプリでは別のトークンを使うこともあります。
情報を盗むマルウェア（インフォスティーラー）が認証用データを持ち出すと、攻撃者がそのデータでアクセスできる場合があります。その場で再ログインを求められなければ、入口の多要素認証をやり直さずに済むことがあるのです。ただし、期限・端末への結び付け・追加認証などで防げる場合もあり、盗めば必ず送金できるわけではありません。
ログインのあとに効く、
7つの守りを見てみよう。
元記事が着目した観点を、日常の言葉に置き換えました。名前が載っているだけで、すべての操作が守られるとは限りません。
放置したら、ログアウト。
最後の操作から一定時間たつと切れる仕組み。操作を続けると期限が延びる設計もあり、「30分たてば必ず終了」とは違います。
操作中でも、いったん終了。
ログインからの経過時間で切れる「絶対期限」。無操作の期限とは別です。Cookieに表示される保存期限だけで、サーバー側の期限は判断できません。
同じ番号を、使い続けない。
セッションの識別情報を更新する仕組み。古い情報をいつ無効にするかも重要です。番号が変わるだけで、乗っ取りが必ず終わるとは限りません。
送る前に、もう一度確認。
送金や認証設定の変更で追加認証を行う設計。必要な操作や省略条件を確認します。ログインの認証と、取引時の認証を分けて見ましょう。
通行証を、サービス側で無効に。
ログアウト時にサーバー側でも失効させることが大切。ブラウザを閉じる・Cookieを消す操作だけでは、盗まれたコピーの無効化まで確認できません。
別の端末も、止められる？
全端末ログアウト、利用停止、パスワード変更で、どのセッションやトークンが失効するかを確認。変更が既存のログインに効くかはサービスの設計次第です。
運ぶとき・読むときの制限。
SecureはHTTPSで送る制限、HttpOnlyはJavaScriptから読むことへの制限、SameSiteは別サイトからのリクエストへの送信を制限します。端末のマルウェア対策を置き換えるものではありません。
追加で調べた、
3つのポイント。
① 通行証を端末に結び付ける「DBSC」
Googleは2026年4月、Windows版Chrome 146でDBSCの一般提供開始を公表しました。端末から取り出せない鍵を使って、短い有効期間のCookieの更新を認める仕組みです。持ち出されたCookieが期限切れになると、別端末では更新しにくくする狙いがあります。
Chromeを更新するだけで、全銀行のCookieがこの方式になるわけではありません。 サイト側にも導入が必要です。今回の資料調査では、紹介する14社の導入状況は確認していません。新しい守りが広がっても、端末の保護と緊急時の連絡は続けましょう。
参考：Google：2026年4月9日のDBSC発表（英語・月別一覧）
参考：Chrome for Developers：サイト側の実装が必要なDBSC（英語）
② 「人間ですか？」から、感染させる誘いも
Microsoftは、偽のCAPTCHAやエラー表示で利用者にコマンド実行をさせる「ClickFix」を報告しています。ふつうの確認に見せかけて、情報を盗むソフトなどを動かす誘導です。
「認証のため」「問題を直すため」と、コマンドのコピー・貼り付けや実行を求められたら、操作を止めます。銀行の利用に必要だと言われても、相手の指示のまま端末設定を変えません。
参考：Microsoft：ClickFixによる偽認証・修復の誘導（英語）
③ 共通基盤でも、使う銀行への確認が大切
地方銀行などが共同利用するインターネットバンキングの基盤は実際にあります。NTTデータは「AnserParaSOL」を共同利用型サービスとして紹介しています。
一方、入口のURLが似ているだけでは、内部のバージョン・設定・契約・停止機能まで同じとは判断できません。利用者は自分の銀行の公式窓口へ確認します。今回、元記事が対象とした74行の通信や内部設定を再測定したわけではありません。
参考：NTTデータ：共同利用型AnserParaSOLの紹介
新しい守りは頼もしいにゃ。でも「自分の銀行で使える？」「困ったらどこへ？」は、公式案内でチェック！
14社の公開情報を、
同じ物差しで読み直す。
対象は銀行9行＋証券5社です。金融機関の種類・ブラウザ・アプリ・対象画面を分けます。2026年10月3日に公開資料で確認した例を、開いて読めます。
「確認できた機能」と「この資料からは判断できない点」をセットで表示。 内部のセッション制御を実測した比較ではありません。
🏦 三菱UFJ銀行
公式案内で確認：アプリのワンタイムパスワードによる取引認証を案内。
読み取りの範囲：ブラウザのログイン済み状態の一括失効範囲は、この資料では判断できません。
出典：三菱UFJ銀行の公式案内
🏦 三井住友銀行
公式案内で確認：SMBCセーフティパスは登録端末での生体認証を使用。別端末からのログインにも登録端末が必要と説明。
読み取りの範囲：この説明だけでは、盗まれた既存セッションの失効条件までは判断できません。
出典：三井住友銀行の公式案内
🏦 みずほ銀行
公式案内で確認：みずほダイレクトの現行案内は、取引モニタリングとワンタイムパスワードの提供を説明。
読み取りの範囲：旧ページの情報をそのまま使わず現行案内を参照。セッションの絶対期限や一括失効条件は、このページからは未確認です。
出典：みずほ銀行の公式案内
🏦 りそな銀行
公式案内で確認：安全対策の案内に、一定時間操作がない場合の自動ログアウトを記載。
読み取りの範囲：無操作時の説明です。操作中でも切れる期限や全端末の失効と同じ意味ではありません。
出典：りそな銀行の公式案内
🏦 楽天銀行
公式案内で確認：ログイン制限は、パソコンからログインする際のワンタイム認証を設定できる機能として案内。
読み取りの範囲：新たなログインへの制限を、すでに発行された全セッションの無効化と同一視しません。
出典：楽天銀行の公式案内
🏦 ドコモSMTBネット銀行（旧 住信SBIネット銀行）
公式案内で確認：スマート認証NEOは、別端末・ブラウザの取引を登録端末で承認。登録済みアプリではログイン時認証により取引時承認を省略する説明あり。
読み取りの範囲：全取引で毎回、生体認証をやり直すという意味ではありません。承認が必要な場面を確認します。
🏦 PayPay銀行
公式案内で確認：法人・個人事業主向けFAQでは、ログイン後10分以上操作がない場合の自動ログアウトを案内。
読み取りの範囲：この時間は当該サービスの例です。個人向けの全アプリや絶対期限に一般化しません。
🏦 ソニー銀行
公式案内で確認：セキュリティ対策の案内に、一定時間の無操作で通信を切断する自動タイムアウトを記載。
読み取りの範囲：この説明から、全端末の一括失効や操作中の絶対期限までは確認できません。
出典：ソニー銀行の公式案内
🏦 auじぶん銀行
公式案内で確認：インターネットバンキングロックはブラウザのログインを制限する機能。ロック中もアプリのログインは可能と案内。
読み取りの範囲：入口の制限範囲と、既存の全セッションを無効にする範囲を区別します。
出典：auじぶん銀行の公式案内
📈 SBI証券
公式案内で確認：ログインの一時利用停止など、不正アクセス時の操作制限を公式FAQで案内。
読み取りの範囲：利用停止を設定できることだけで、進行中の全セッションも即失効すると判断しません。被害時は公式窓口へ確認します。
出典：SBI証券の公式案内
📈 楽天証券
公式案内で確認：セキュリティ案内にパスキー認証と、取引・サービスの一時利用停止を掲載。
読み取りの範囲：停止の対象・手順を確認。Cookieの全失効が同時に行われるかは、この説明だけでは未確認です。
出典：楽天証券の公式案内
📈 マネックス証券
公式案内で確認：最後の操作から30分での自動ログアウトを案内。パソコン版には自動ログアウトを停止する設定も記載。
読み取りの範囲：対象画面と設定の条件に注意。すべての関連商品に共通する絶対期限としては扱いません。
出典：マネックス証券の公式案内
📈 松井証券
公式案内で確認：お客様サイト（クラシック）のFAQは、約30分の無操作で自動ログアウト。自動ログアウト停止の設定も案内。
読み取りの範囲：クラシックの案内です。現行の全画面・アプリ・関連サービスへ一般化しません。
出典：松井証券の公式案内
安心のために、
4つの勘違いをほどこう。
「盗まれたコピー」も消える？
自分のブラウザから削除しても、別の場所へ持ち出されたコピーは消えません。サービス側の失効・利用停止が必要か、公式窓口へ相談します。
操作していても切れる？
無操作タイムアウトと絶対期限は別です。書かれた時間だけで、活動中の不正利用も必ず止まるとは判断できません。
感染した端末でも安全？
専用のブラウザやプロファイルは整理には役立ちますが、同じ端末上のマルウェアから保存データを必ず隔離するものではありません。
それだけで、危険な銀行？
件数は脆弱性の数ではありません。実行権限・更新の管理・隔離・CSPの内容などが重要。CSPの表示だけでも、サイト全体の安全性は採点できません。
参考：Google：端末侵害とCookie持ち出しの問題（英語）
参考：OWASP：外部JavaScriptの管理と隔離（英語）
「不審なソフトを動かした。銀行のCookieを消せば大丈夫？」
これは架空の場面です。次の対応で、いちばん大切なのは？
答えと理由を見る
銀行へ連絡します。感染が疑われる端末はネットワークから切り離し、信頼できる端末や電話を使います。 Cookie削除だけで解決とせず、利用停止やセッションの失効、認証の再設定を相談。設定を探して連絡を遅らせません。
今日できるのは、
通行証の守りと端末の見直し。
- パスキーや、金融機関が推奨する認証を使う。
入口の守りを弱めません。取引時の認証・限度額・通知も確認し、知らない操作の承認は止めます。
- OS・ブラウザ・アプリを更新する。
不要な拡張機能は整理。出所不明のソフトやファイルを動かさず、偽の認証・修復によるコマンド実行にも応じません。
- 使い終わったら、サービスのログアウトを使う。
画面を閉じるだけで済ませません。他の端末の管理・利用停止の機能があれば、その対象範囲を公式案内で確認します。
- 連絡先の場所と、明細・通知を確認する。
緊急停止の公式窓口がどこにあるかを確認。SMSやメールのリンクを使わず、普段の公式アプリや確認済みのブックマークから見ます。
不正利用・感染が心配なら、
公式窓口への連絡を急ごう。
- 疑わしい操作を止める。 感染が疑われる端末はネットワークから切り離し、その端末で銀行へログインし直しません。
- 信頼できる端末・電話から、金融機関へすぐ連絡。 利用停止・送金停止と、既存のセッションやトークンの失効を相談します。届いたメッセージの連絡先は使いません。
- 認証と端末を、案内に沿って復旧。 パスワード、登録端末、認証方法、復旧先や連携設定の見直しを相談。パスワード変更で何が失効するかも確認します。感染端末の対応は専門のサポートへ相談し、復旧前の再利用を避けます。
- 記録・被害申告・補償の手順を確認。 日時・取引・操作内容を整理し、金融機関と警察へ。緊急でない警察相談は #9110。申告期限は金融機関の案内で確認します。
参考：金融被害の公式窓口の一例
参考：警察庁：通報・相談の案内
一括ログアウトやパスワード変更をしても、すでに持ち出された情報や実行済みの取引が元に戻るわけではありません。補償は各社の条件と調査で判断されます。
通行証を止める相談も必要なんだね。「全部調べてから」じゃなくて、まず公式窓口へ伝えよう。
確認する場所を、
紙でも見返せるように。
画面でチェックし、シートだけ印刷できます。入力・送信はありません。チェック状態は保存されず、ページを開き直すと戻ります。
ログイン後の安心チェックシート
口座番号・パスワード・暗証番号・認証コードは、このシートに書きません。
確認した金融機関・サービスの名称：
緊急停止・ログアウトの案内がある場所：
まだ確認したい設定・次に見直す日：
🍪 強い鍵を使おう。ログイン後も、守っていこう。
確認した項目：0 / 6。この数だけで、安全性を判断するものではありません。
ここも、気になる。
ブラウザを閉じたら、ログアウトになる？
そうとは限りません。閉じたあともログイン状態を復元する設計があります。サービスのログアウトを使いましょう。ログアウト後に戻る操作で古い画面が見えても、セッションがまだ有効な証拠とは限りません。
パスワードを変えれば、盗まれたCookieは止まる？
サービスの設計によります。既存セッションを失効させるものもありますが、すべてがそうとは限りません。被害時は、変更だけで完了とせず、停止・失効の対象を公式窓口に確認します。
スマホの銀行アプリなら、この問題はない？
アプリでもログイン状態を維持する仕組みがあります。ブラウザと同じCookieを使うとは限らず、認証や端末管理も異なります。ブラウザの時間や設定を、そのままアプリの評価に使いません。
公式ページにCookie対策がない。危険？
公開説明にないことは、未実装の証明ではありません。必要なときは「不正利用時、今あるログイン状態も停止できますか」と公式窓口へ質問します。自分でCookieをコピーして試す必要はありません。
出典と、この調査の範囲
確認日：2026年10月3日。元記事のセッション管理の観点を参考に、公式の技術資料と金融機関の公開案内を追加確認しました。会話・図解・クイズは説明用に作成した架空の場面です。
今回の調査は公開資料を読む方法です。14社や74行の通信の再測定、ログイン済みCookieのコピー・再利用検証、各社内部の設定確認は行っていません。元記事の開示点数・外部スクリプト件数・CSPの有無を、現在の安全性ランキングとして転載していません。未確認と未実装は区別します。
技術資料と元記事を見る
14社の出典は、各社の説明欄に掲載しています。名称・対象画面・機能・条件は変更されるため、設定時は最新の公式案内を確認してください。
コメント