azu · October 19, 2024 05:41 · Jun 17, 2022 · Jun 17, 2022 · Jun 17, 2022 · Jun 17, 2022
diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -122,9 +122,10 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
   - [#796956 Able to Takeover Merchants Accounts Even They Have Already Setup SSO, After Bypassing the Email Confirmation](https://hackerone.com/reports/796956)
 - [ ] メールアドレスの変更の確認メールは、一定の有効期限をつける
   - 1日以内に確定されないならメールアドレスの変更自体を無効にするなど
-- [ ] IdPでアカウントを作成した場合、そのアカウントでパスワードリセットはできないようにする
-  - IdPでアカウントを作成した場合、そのアカウントにはパスワードそのものがないはず
-  - パスワードリセットによって、パスワードが設定できてしまうと、パスワードレスじゃなくなるため、セキュリティの強度が下がる
+- [ ] IdP経由でアカウントを作成した場合、そのアカウントでパスワードリセットはできないようにする
+  - IdP経由でアカウントを作成した場合、そのアカウントにはパスワードそのものがないはず
+  - パスワードリセットによって、パスワードが設定できてしまうと、パスワードレスじゃなくなる
+  - あんまり万能な解決方法がない感じがする
   - IdPのみのアカウント(マージされていないアカウント)の場合は、パスワードリセットは、SSOでログインできる有無のメールをリセットメールの代わりに送信するなど
 - [ ] パスワードリセットによって、そのアカウントの存在が判定できないようにする
   - パスワードリセットの結果(レスポンス)が、アカウントの存在の有無で変わらないようにする

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -115,7 +115,8 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
       - [Google | NextAuth.js](https://next-auth.js.org/providers/google#example)
   - verifiedされていないアカウントはマージしてはいけない
 - [ ] アカウントをマージする際には、パスワードをリセットしてメールで送信 or アカウントのパスワードの再入力を求める
-  - 📝 
+  - 📝 これは検証済みのアカウントでも、マージする時点の所有者かどうかは別であるため
+  - 非同期でやっていた検証をマージする瞬間は同期的に行うことで問題を軽減するアプローチが必要となってる
     - Classic-Federated Merge Attackの場合に再入力は、被害者が知らないパスワードの入力が必要となるのでマージを止められる
     - Non-Verifying IdP Attackの場合は、攻撃者が知らないパスワードの入力が必要となるのでマージを止められる
   - [#796956 Able to Takeover Merchants Accounts Even They Have Already Setup SSO, After Bypassing the Email Confirmation](https://hackerone.com/reports/796956)

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -114,7 +114,7 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
     - Next Auth + Googleなら`profile.email_verified`をチェックする
       - [Google | NextAuth.js](https://next-auth.js.org/providers/google#example)
   - verifiedされていないアカウントはマージしてはいけない
-- [ ] アカウントをマージする際には、パスワードをリセット or アカウントのパスワードの再入力を求める
+- [ ] アカウントをマージする際には、パスワードをリセットしてメールで送信 or アカウントのパスワードの再入力を求める
   - 📝 
     - Classic-Federated Merge Attackの場合に再入力は、被害者が知らないパスワードの入力が必要となるのでマージを止められる
     - Non-Verifying IdP Attackの場合は、攻撃者が知らないパスワードの入力が必要となるのでマージを止められる

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -115,6 +115,9 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
       - [Google | NextAuth.js](https://next-auth.js.org/providers/google#example)
   - verifiedされていないアカウントはマージしてはいけない
 - [ ] アカウントをマージする際には、パスワードをリセット or アカウントのパスワードの再入力を求める
+  - 📝 
+    - Classic-Federated Merge Attackの場合に再入力は、被害者が知らないパスワードの入力が必要となるのでマージを止められる
+    - Non-Verifying IdP Attackの場合は、攻撃者が知らないパスワードの入力が必要となるのでマージを止められる
   - [#796956 Able to Takeover Merchants Accounts Even They Have Already Setup SSO, After Bypassing the Email Confirmation](https://hackerone.com/reports/796956)
 - [ ] メールアドレスの変更の確認メールは、一定の有効期限をつける
   - 1日以内に確定されないならメールアドレスの変更自体を無効にするなど

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -124,7 +124,7 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
   - IdPのみのアカウント(マージされていないアカウント)の場合は、パスワードリセットは、SSOでログインできる有無のメールをリセットメールの代わりに送信するなど
 - [ ] パスワードリセットによって、そのアカウントの存在が判定できないようにする
   - パスワードリセットの結果(レスポンス)が、アカウントの存在の有無で変わらないようにする
-  - メールの内容を変更すればいいので、レスポンスはアカウントの有無で変更しない
+  - メールの内容を変更すればいいので、レスポンスはアカウントの有無で変更しない( `{ ok: true }` だけ返すなど)
   - 攻撃者が機械的にパスワードリセットしていくことで、アカウントのスクリーニングを防ぐ目的
   - [Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog](https://blog.flatt.tech/entry/login_logic_security)
   - [セシールオンラインショップへの不正アクセス、二重登録防止機能を悪用しリストをスクリーニング（ディノス・セシール） | ScanNetSecurity](https://scan.netsecurity.ne.jp/article/2018/06/12/41039.html)

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -102,6 +102,7 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
 - [ ] パスワードをリセットすると、メールアドレスの変更を保留している状態もリセットする
 - [ ] パスワードをリセットしたときの通知メールに、紐づくIdPやメールアドレスの情報を掲載する
 - [ ] パスワードリセットのトークンには有効期限をつける
+  -  PINコードの場合は、エントロピーを大きくするか、試行回数の制限もつける
 - [ ] パスワードリセットのトークンが利用できるのは一度だけにする
   - 何度も同じトークンでリセットできないようにする
   - [#772886 Password Reset Link Works Multiple Times](https://hackerone.com/reports/772886)

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -18,7 +18,7 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
 📝 メールアドレスと書いてるけど、電話番号 + SMSも基本同じ。ログインするIDという意味合い
 
 ### 1. Classic-Federated Merge Attack: 
-- ![image](https://user-images.githubusercontent.com/19714/174110330-eadcb549-7266-474d-839b-ad3869a9be60.png)
+![image](https://user-images.githubusercontent.com/19714/174110330-eadcb549-7266-474d-839b-ad3869a9be60.png)
 - 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
 - 被害者は、GoogleログインなどのSSOでログインする
 - メールアドレスとIdPのメールアドレスが一致するのでアカウントがマージされる

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -125,6 +125,7 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
   - パスワードリセットの結果(レスポンス)が、アカウントの存在の有無で変わらないようにする
   - メールの内容を変更すればいいので、レスポンスはアカウントの有無で変更しない
   - 攻撃者が機械的にパスワードリセットしていくことで、アカウントのスクリーニングを防ぐ目的
+  - [Webサービスにおけるログイン機能の仕様とセキュリティ観点 - Flatt Security Blog](https://blog.flatt.tech/entry/login_logic_security)
   - [セシールオンラインショップへの不正アクセス、二重登録防止機能を悪用しリストをスクリーニング（ディノス・セシール） | ScanNetSecurity](https://scan.netsecurity.ne.jp/article/2018/06/12/41039.html)
 - [ ] 多要素認証を推奨する
 - [ ] 多要素認証を有効化した際に、そのアカウントのセッションを全て無効化する

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -6,7 +6,8 @@ Pre-hijacking Attacksについてのメモ書きです。
 
 Pre-hijacking Attacks はメールアドレスの確認をしないでアカウントを作れるサービスという前提があります。
 
-アカウント作成からそのまま機能を利用できるようにすることで、利用体験をよくするための施策としてメールアドレスの確認のステップを後回し(またはしない)サービスがあります。
+アカウント作成からそのまま機能を利用できるようにすることで、利用体験をよくするための施策として、メールアドレスの確認のステップを後回し
+またはしないサービスがあります。
 モバイルアプリでアカウント作成時に、メールアプリをわざわざ別で開かせるようなフローを避けたりするためにメールを確認しないでアカウント作成ができるサービスもあります。
 
 例) Dropboxはメールアドレスとパスワードを入力して新規アカウントを作成できる。

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -88,10 +88,15 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
 
 - [ ] メールアドレス未確認のアカウントを定期的に削除する
 - [ ] メールアドレス未確認状態での機能を制限する
-- [ ] アカウント作成時にreCAPTCHAなどを導入し、機械的にアカウントを作成しにくくする
+
 
 どちらのケースでも共通でやるべきもの
 
+- [ ] アカウント作成時にreCAPTCHAなどを導入し、機械的にアカウントを作成しにくくする
+  - Pre-hijacking Attacks は大量のアカウントを用意したり、待ち伏せする感じなので機械的なアカウントを作りにくくすることが対策になる
+  - 登録確認メールを使ったSpamなども防止する意味合いもある
+  - [KLab ID への不正アクセスによる迷惑メールの送信に関するお詫びとご報告 | お客さまへのお知らせ | ニュース | KLab株式会社](https://www.klab.com/jp/press/info/2021/0723/klab_id.html)
+  - [自作サービスがDDoS攻撃された話. 休日が木っ端微塵に吹き飛んだ | by Takuya Matsuyama | 週休７日で働きたい](https://blog.craftz.dog/ddos-attack-on-inkdrop-db0af5893186)
 - [ ] パスワードをリセットすると、そのアカウントのセッションを全て無効にする
 - [ ] パスワードをリセットすると、メールアドレスの変更を保留している状態もリセットする
 - [ ] パスワードをリセットしたときの通知メールに、紐づくIdPやメールアドレスの情報を掲載する

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -7,7 +7,7 @@ Pre-hijacking Attacksについてのメモ書きです。
 Pre-hijacking Attacks はメールアドレスの確認をしないでアカウントを作れるサービスという前提があります。
 
 アカウント作成からそのまま機能を利用できるようにすることで、利用体験をよくするための施策としてメールアドレスの確認のステップを後回し(またはしない)サービスがあります。
-モバイルアプリでアカウント作成時に、メールアプリをわざわざ別で開かせるようなフローを避けたりするために、メールアドレスの検証をしないでアカウント作成ができるサービスもあります。
+モバイルアプリでアカウント作成時に、メールアプリをわざわざ別で開かせるようなフローを避けたりするためにメールを確認しないでアカウント作成ができるサービスもあります。
 
 例) Dropboxはメールアドレスとパスワードを入力して新規アカウントを作成できる。
 このときに、自分が持っていないメールアドレスでもとりあえずアカウントを作成できて、そのままログインできる。
@@ -16,58 +16,63 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
 
 📝 メールアドレスと書いてるけど、電話番号 + SMSも基本同じ。ログインするIDという意味合い
 
-1. Classic-Federated Merge Attack: 
-   - ![image](https://user-images.githubusercontent.com/19714/174110330-eadcb549-7266-474d-839b-ad3869a9be60.png)
-  - 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
-  - 被害者は、GoogleログインなどのSSOでログインする
-  - メールアドレスとIdPのメールアドレスが一致するのでアカウントがマージされる
-  - 攻撃者は、メールアドレスと攻撃者が設定したパスワードでログインできるので、マージ後の被害者のアカウントを乗っ取れる
-  - 対策:
-    - アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
-2. Unexpired Session Identifier Attack:
-  - 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
-  - 攻撃者は、そのままログイン状態を維持するように定期的にアクセスし続ける
-  - 被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
-  - 被害者が、パスワードリセットしてサービスにログインして利用する
-  - パスワードリセット時に、攻撃者がログインしていたセッションが切れないため、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
-  - 対策:
-    - パスワードリセットするときに、セッションもリセットする
-3. Trojan Identifier Attack:
-  - ![image](https://user-images.githubusercontent.com/19714/174110076-11eb64ce-573d-4cc4-94ad-99ed1a600bc9.png)
-  - 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
-  - 攻撃者は、そのアカウントと攻撃者のIdPアカウントを紐づけておく
-  - 被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
-  - 被害者が、パスワードリセットしてサービスにログインして利用する
-  - 攻撃者は、攻撃者のIdPアカウントでサービスにログインできるので、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
-  - 対策:
-    - アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
-  - 📝 Classic-Federated Merge Attack は被害者がSSOでログイン、Trojan Identifier Attackは攻撃者がSSOでログイン の違い
-    - どちらもマージの挙動を利用した攻撃
-  - 📝 もと論文だと、もう一つの攻撃が含まれていて、サブメールアドレスや電話番号を最初に紐づけておいて、それでリセットする攻撃も同じくTrojan Identifier Attackと言ってる
-    - Classic-Federated Merge Attackの対義語として扱った方がいいので、SubProcess Attackみたいな別の名前に分離したい
-4. Unexpired Email Change Attack:
-  - 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
-  - 攻撃者は、そのアカウントで攻撃者のメールアドレスに変更の申請をしておく(まだ確定はしない)
-  - サービスは、メールアドレスの変更の確認メールを攻撃者のメールアドレスの送信する(まだ確定はしない)
-  - 被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
-  - 被害者が、パスワードリセットしてサービスにログインして利用する
-  - 攻撃者、メールアドレスの変更の確認メールからメールアドレスの変更を確定する
-  - 攻撃者は、攻撃者のメールアドレスでログインできるので、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
-  - 対策:
-    - パスワードリセットするときに、メールアドレスの変更を保留している状態もリセットする
-    - メールアドレスの変更の有効期限を設定する
-5. Non-Verifying IdP Attack: 
-  - 攻撃者は、メールアドレスの確認をしないIdPで被害者のメールアドレスを使ってアカウントを作成する
-  - 被害者は、自分自身のメールアドレスでアカウントを作成して利用する
-  - 攻撃者は、被害者のメールアドレスを使ったIdPでサービスにログインしてアカウントをマージさせる
-  - 攻撃者は、被害者のアカウントを乗っ取れる
-  - 📝 メールアドレスの存在確認などをしてないIdP連携の問題
-    - またサービスが、OpenIDのclaimに含まれる `email_verified` をチェックせずにマージしているとこの問題が起きる
-    - マージするときは、そのサービスでメールアドレスが確認ずみ + IdPアカウントのメールアドレスが確認ずみで初めてマージする
-    - さらにより良くするには、マージするタイミングで、サービスのメールアドレスに紐づくパスワードをリセット または 再入力して、マージするタイミングでの持ち主をもう一度検証する
-  - 対策:
-    - そういうメールを検証しないIdPでSSOは実装しない
-    - アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
+### 1. Classic-Federated Merge Attack: 
+- ![image](https://user-images.githubusercontent.com/19714/174110330-eadcb549-7266-474d-839b-ad3869a9be60.png)
+- 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
+- 被害者は、GoogleログインなどのSSOでログインする
+- メールアドレスとIdPのメールアドレスが一致するのでアカウントがマージされる
+- 攻撃者は、メールアドレスと攻撃者が設定したパスワードでログインできるので、マージ後の被害者のアカウントを乗っ取れる
+- 対策:
+  - アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
+
+### 2. Unexpired Session Identifier Attack:
+- 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
+- 攻撃者は、そのままログイン状態を維持するように定期的にアクセスし続ける
+- 被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
+- 被害者が、パスワードリセットしてサービスにログインして利用する
+- パスワードリセット時に、攻撃者がログインしていたセッションが切れないため、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
+- 対策:
+  - パスワードリセットするときに、セッションもリセットする
+
+### 3. Trojan Identifier Attack:
+
+![image](https://user-images.githubusercontent.com/19714/174110076-11eb64ce-573d-4cc4-94ad-99ed1a600bc9.png)
+- 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
+- 攻撃者は、そのアカウントと攻撃者のIdPアカウントを紐づけておく
+- 被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
+- 被害者が、パスワードリセットしてサービスにログインして利用する
+- 攻撃者は、攻撃者のIdPアカウントでサービスにログインできるので、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
+- 対策:
+  - アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
+- 📝 Classic-Federated Merge Attack は被害者がSSOでログイン、Trojan Identifier Attackは攻撃者がSSOでログイン の違い
+  - どちらもマージの挙動を利用した攻撃
+- 📝 もと論文だと、もう一つの攻撃が含まれていて、サブメールアドレスや電話番号を最初に紐づけておいて、それでリセットする攻撃も同じくTrojan Identifier Attackと言ってる
+  - Classic-Federated Merge Attackの対義語として扱った方がいいので、SubProcess Attackみたいな別の名前に分離したい
+
+### 4. Unexpired Email Change Attack:
+- 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
+- 攻撃者は、そのアカウントで攻撃者のメールアドレスに変更の申請をしておく(まだ確定はしない)
+- サービスは、メールアドレスの変更の確認メールを攻撃者のメールアドレスの送信する(まだ確定はしない)
+- 被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
+- 被害者が、パスワードリセットしてサービスにログインして利用する
+- 攻撃者、メールアドレスの変更の確認メールからメールアドレスの変更を確定する
+- 攻撃者は、攻撃者のメールアドレスでログインできるので、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
+- 対策:
+  - パスワードリセットするときに、メールアドレスの変更を保留している状態もリセットする
+  - メールアドレスの変更の有効期限を設定する
+
+### 5. Non-Verifying IdP Attack: 
+- 攻撃者は、メールアドレスの確認をしないIdPで被害者のメールアドレスを使ってアカウントを作成する
+- 被害者は、自分自身のメールアドレスでアカウントを作成して利用する
+- 攻撃者は、被害者のメールアドレスを使ったIdPでサービスにログインしてアカウントをマージさせる
+- 攻撃者は、被害者のアカウントを乗っ取れる
+- 📝 メールアドレスの存在確認などをしてないIdP連携の問題
+  - またサービスが、OpenIDのclaimに含まれる `email_verified` をチェックせずにマージしているとこの問題が起きる
+  - マージするときは、そのサービスでメールアドレスが確認ずみ + IdPアカウントのメールアドレスが確認ずみで初めてマージする
+  - さらにより良くするには、マージするタイミングで、サービスのメールアドレスに紐づくパスワードをリセット または 再入力して、マージするタイミングでの持ち主をもう一度検証する
+- 対策:
+  - そういうメールを検証しないIdPでSSOは実装しない
+  - アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
 
 ## チェックリスト
 

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -7,7 +7,7 @@ Pre-hijacking Attacksについてのメモ書きです。
 Pre-hijacking Attacks はメールアドレスの確認をしないでアカウントを作れるサービスという前提があります。
 
 アカウント作成からそのまま機能を利用できるようにすることで、利用体験をよくするための施策としてメールアドレスの確認のステップを後回し(またはしない)サービスがあります。
-モバイルアプリでアカウント作成時に、メールアプリをわざわざ別で開かせるようなフローを避けたりするためにメールを確認しないでアカウント作成ができるサービスもあります。
+モバイルアプリでアカウント作成時に、メールアプリをわざわざ別で開かせるようなフローを避けたりするために、メールアドレスの検証をしないでアカウント作成ができるサービスもあります。
 
 例) Dropboxはメールアドレスとパスワードを入力して新規アカウントを作成できる。
 このときに、自分が持っていないメールアドレスでもとりあえずアカウントを作成できて、そのままログインできる。

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -71,8 +71,13 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
 
 ## チェックリスト
 
-- [ ] アカウントを作成時には、メールアドレスの検証をしてからアカウントを作成する
+- [ ] アカウント作成時には、メールアドレスの検証をしてからアカウントを作成する
   - これができるとPre-hijacking AttacksのNon-Verifying IdP Attack以外は防げる
+- [ ] アカウント作成時に、メールアドレスの検証用のトークンなどを露出しない
+  - https://example.com/account/activate?token=xxx みたいなURLをメールに載せると思うが、このxxxトークンをレスポンスとかメールを確認してねページなどに露出しない
+  - メールアドレスの検証を回避できてしまうため
+- [ ] メールアドレス変更時に変更後のメールアドレスに確認メールを飛ばしているか
+  - [#791775 Email Confirmation Bypass in myshop.myshopify.com that Leads to Full Privilege Escalation to Any Shop Owner by Taking Advantage of the Shopify SSO](https://hackerone.com/reports/791775)
 
 メールアドレスの検証前にアカウントを作るサービスの場合
 
@@ -85,14 +90,20 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
 - [ ] パスワードをリセットすると、そのアカウントのセッションを全て無効にする
 - [ ] パスワードをリセットすると、メールアドレスの変更を保留している状態もリセットする
 - [ ] パスワードをリセットしたときの通知メールに、紐づくIdPやメールアドレスの情報を掲載する
+- [ ] パスワードリセットのトークンには有効期限をつける
+- [ ] パスワードリセットのトークンが利用できるのは一度だけにする
+  - 何度も同じトークンでリセットできないようにする
+  - [#772886 Password Reset Link Works Multiple Times](https://hackerone.com/reports/772886)
 - [ ] アカウントをマージする際には、サービスのアカウントとIdPのアカウントが両方検証ずみアカウントであることを確認する
   - OpenID Connectならclaimの`email_verified`をチェックする
-    - ライブラリがやってくレルこともあるが、手動でやらないといけないこともあるので必ず確認する
+    - ライブラリがやってくれることもあるが、手動でやらないといけないこともあるので必ず確認する
     - Passport + Googleなら、`email`配列の要素の`verified`プロパティ
       - [passport-google-oauth2](https://github.com/jaredhanson/passport-google-oauth2/blob/2399ef47f00b47ac587f056f2f100a2c4db81928/lib/profile/openid.js#L33)
     - Next Auth + Googleなら`profile.email_verified`をチェックする
       - [Google | NextAuth.js](https://next-auth.js.org/providers/google#example)
   - verifiedされていないアカウントはマージしてはいけない
+- [ ] アカウントをマージする際には、パスワードをリセット or アカウントのパスワードの再入力を求める
+  - [#796956 Able to Takeover Merchants Accounts Even They Have Already Setup SSO, After Bypassing the Email Confirmation](https://hackerone.com/reports/796956)
 - [ ] メールアドレスの変更の確認メールは、一定の有効期限をつける
   - 1日以内に確定されないならメールアドレスの変更自体を無効にするなど
 - [ ] IdPでアカウントを作成した場合、そのアカウントでパスワードリセットはできないようにする
@@ -106,3 +117,4 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
   - [セシールオンラインショップへの不正アクセス、二重登録防止機能を悪用しリストをスクリーニング（ディノス・セシール） | ScanNetSecurity](https://scan.netsecurity.ne.jp/article/2018/06/12/41039.html)
 - [ ] 多要素認証を推奨する
 - [ ] 多要素認証を有効化した際に、そのアカウントのセッションを全て無効化する
+  - これはセッションを維持し続けた攻撃者の攻撃を防ぐ目的(MFAを突破されないようにするため)
diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -80,7 +80,7 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
 - [ ] メールアドレス未確認状態での機能を制限する
 - [ ] アカウント作成時にreCAPTCHAなどを導入し、機械的にアカウントを作成しにくくする
 
-どちらのケースでも共有でやるべきもの
+どちらのケースでも共通でやるべきもの
 
 - [ ] パスワードをリセットすると、そのアカウントのセッションを全て無効にする
 - [ ] パスワードをリセットすると、メールアドレスの変更を保留している状態もリセットする

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -77,6 +77,7 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
 メールアドレスの検証前にアカウントを作るサービスの場合
 
 - [ ] メールアドレス未確認のアカウントを定期的に削除する
+- [ ] メールアドレス未確認状態での機能を制限する
 - [ ] アカウント作成時にreCAPTCHAなどを導入し、機械的にアカウントを作成しにくくする
 
 どちらのケースでも共有でやるべきもの

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -71,7 +71,7 @@ Pre-hijacking Attacks はメールアドレスの確認をしないでアカウ
 
 ## チェックリスト
 
-- [ ] アカウントを作成時には、メールアドレスの検証をしてからアカウントをする
+- [ ] アカウントを作成時には、メールアドレスの検証をしてからアカウントを作成する
   - これができるとPre-hijacking AttacksのNon-Verifying IdP Attack以外は防げる
 
 メールアドレスの検証前にアカウントを作るサービスの場合

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -5,7 +5,8 @@ Pre-hijacking Attacksについてのメモ書きです。
 - [New Research Paper: Pre-hijacking Attacks on Web User Accounts – Microsoft Security Response Center](https://msrc-blog.microsoft.com/2022/05/23/pre-hijacking-attacks/)
 
 Pre-hijacking Attacks はメールアドレスの確認をしないでアカウントを作れるサービスという前提があります。
-アカウント作成からそのまま特定の機能をすぐ利用できるようにすることで、体験をよくするための施策としてメールアドレスの確認のステップを後回し(またはしない)サービスがあります。
+
+アカウント作成からそのまま機能を利用できるようにすることで、利用体験をよくするための施策としてメールアドレスの確認のステップを後回し(またはしない)サービスがあります。
 モバイルアプリでアカウント作成時に、メールアプリをわざわざ別で開かせるようなフローを避けたりするためにメールを確認しないでアカウント作成ができるサービスもあります。
 
 例) Dropboxはメールアドレスとパスワードを入力して新規アカウントを作成できる。

diff --git a/Pre-hijacking Attacks.md b/Pre-hijacking Attacks.md
@@ -0,0 +1,106 @@
+Pre-hijacking Attacksについてのメモ書きです。
+元の論文と記事は次のページを読んでください。
+
+- [[2205.10174] Pre-hijacked accounts: An Empirical Study of Security Failures in User Account Creation on the Web](https://arxiv.org/abs/2205.10174)
+- [New Research Paper: Pre-hijacking Attacks on Web User Accounts – Microsoft Security Response Center](https://msrc-blog.microsoft.com/2022/05/23/pre-hijacking-attacks/)
+
+Pre-hijacking Attacks はメールアドレスの確認をしないでアカウントを作れるサービスという前提があります。
+アカウント作成からそのまま特定の機能をすぐ利用できるようにすることで、体験をよくするための施策としてメールアドレスの確認のステップを後回し(またはしない)サービスがあります。
+モバイルアプリでアカウント作成時に、メールアプリをわざわざ別で開かせるようなフローを避けたりするためにメールを確認しないでアカウント作成ができるサービスもあります。
+
+例) Dropboxはメールアドレスとパスワードを入力して新規アカウントを作成できる。
+このときに、自分が持っていないメールアドレスでもとりあえずアカウントを作成できて、そのままログインできる。
+
+## 攻撃の種類
+
+📝 メールアドレスと書いてるけど、電話番号 + SMSも基本同じ。ログインするIDという意味合い
+
+1. Classic-Federated Merge Attack: 
+   - ![image](https://user-images.githubusercontent.com/19714/174110330-eadcb549-7266-474d-839b-ad3869a9be60.png)
+  - 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
+  - 被害者は、GoogleログインなどのSSOでログインする
+  - メールアドレスとIdPのメールアドレスが一致するのでアカウントがマージされる
+  - 攻撃者は、メールアドレスと攻撃者が設定したパスワードでログインできるので、マージ後の被害者のアカウントを乗っ取れる
+  - 対策:
+    - アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
+2. Unexpired Session Identifier Attack:
+  - 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
+  - 攻撃者は、そのままログイン状態を維持するように定期的にアクセスし続ける
+  - 被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
+  - 被害者が、パスワードリセットしてサービスにログインして利用する
+  - パスワードリセット時に、攻撃者がログインしていたセッションが切れないため、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
+  - 対策:
+    - パスワードリセットするときに、セッションもリセットする
+3. Trojan Identifier Attack:
+  - ![image](https://user-images.githubusercontent.com/19714/174110076-11eb64ce-573d-4cc4-94ad-99ed1a600bc9.png)
+  - 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
+  - 攻撃者は、そのアカウントと攻撃者のIdPアカウントを紐づけておく
+  - 被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
+  - 被害者が、パスワードリセットしてサービスにログインして利用する
+  - 攻撃者は、攻撃者のIdPアカウントでサービスにログインできるので、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
+  - 対策:
+    - アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
+  - 📝 Classic-Federated Merge Attack は被害者がSSOでログイン、Trojan Identifier Attackは攻撃者がSSOでログイン の違い
+    - どちらもマージの挙動を利用した攻撃
+  - 📝 もと論文だと、もう一つの攻撃が含まれていて、サブメールアドレスや電話番号を最初に紐づけておいて、それでリセットする攻撃も同じくTrojan Identifier Attackと言ってる
+    - Classic-Federated Merge Attackの対義語として扱った方がいいので、SubProcess Attackみたいな別の名前に分離したい
+4. Unexpired Email Change Attack:
+  - 攻撃者は、被害者のメールアドレスを使ってアカウントを作っておく
+  - 攻撃者は、そのアカウントで攻撃者のメールアドレスに変更の申請をしておく(まだ確定はしない)
+  - サービスは、メールアドレスの変更の確認メールを攻撃者のメールアドレスの送信する(まだ確定はしない)
+  - 被害者が、そのサービスを新規で使おうとして「メールアドレスは既に登録されています」となって「このサービスの使ってたけ?」と思ってパスワードリセットする
+  - 被害者が、パスワードリセットしてサービスにログインして利用する
+  - 攻撃者、メールアドレスの変更の確認メールからメールアドレスの変更を確定する
+  - 攻撃者は、攻撃者のメールアドレスでログインできるので、被害者が設定した内容を盗み取れる(アカウントも乗っ取れる)
+  - 対策:
+    - パスワードリセットするときに、メールアドレスの変更を保留している状態もリセットする
+    - メールアドレスの変更の有効期限を設定する
+5. Non-Verifying IdP Attack: 
+  - 攻撃者は、メールアドレスの確認をしないIdPで被害者のメールアドレスを使ってアカウントを作成する
+  - 被害者は、自分自身のメールアドレスでアカウントを作成して利用する
+  - 攻撃者は、被害者のメールアドレスを使ったIdPでサービスにログインしてアカウントをマージさせる
+  - 攻撃者は、被害者のアカウントを乗っ取れる
+  - 📝 メールアドレスの存在確認などをしてないIdP連携の問題
+    - またサービスが、OpenIDのclaimに含まれる `email_verified` をチェックせずにマージしているとこの問題が起きる
+    - マージするときは、そのサービスでメールアドレスが確認ずみ + IdPアカウントのメールアドレスが確認ずみで初めてマージする
+    - さらにより良くするには、マージするタイミングで、サービスのメールアドレスに紐づくパスワードをリセット または 再入力して、マージするタイミングでの持ち主をもう一度検証する
+  - 対策:
+    - そういうメールを検証しないIdPでSSOは実装しない
+    - アカウントをマージするときには、サービスのメールアドレスとIdPのメールアドレスをどちらも検証済みであるかを確認する
+
+## チェックリスト
+
+- [ ] アカウントを作成時には、メールアドレスの検証をしてからアカウントをする
+  - これができるとPre-hijacking AttacksのNon-Verifying IdP Attack以外は防げる
+
+メールアドレスの検証前にアカウントを作るサービスの場合
+
+- [ ] メールアドレス未確認のアカウントを定期的に削除する
+- [ ] アカウント作成時にreCAPTCHAなどを導入し、機械的にアカウントを作成しにくくする
+
+どちらのケースでも共有でやるべきもの
+
+- [ ] パスワードをリセットすると、そのアカウントのセッションを全て無効にする
+- [ ] パスワードをリセットすると、メールアドレスの変更を保留している状態もリセットする
+- [ ] パスワードをリセットしたときの通知メールに、紐づくIdPやメールアドレスの情報を掲載する
+- [ ] アカウントをマージする際には、サービスのアカウントとIdPのアカウントが両方検証ずみアカウントであることを確認する
+  - OpenID Connectならclaimの`email_verified`をチェックする
+    - ライブラリがやってくレルこともあるが、手動でやらないといけないこともあるので必ず確認する
+    - Passport + Googleなら、`email`配列の要素の`verified`プロパティ
+      - [passport-google-oauth2](https://github.com/jaredhanson/passport-google-oauth2/blob/2399ef47f00b47ac587f056f2f100a2c4db81928/lib/profile/openid.js#L33)
+    - Next Auth + Googleなら`profile.email_verified`をチェックする
+      - [Google | NextAuth.js](https://next-auth.js.org/providers/google#example)
+  - verifiedされていないアカウントはマージしてはいけない
+- [ ] メールアドレスの変更の確認メールは、一定の有効期限をつける
+  - 1日以内に確定されないならメールアドレスの変更自体を無効にするなど
+- [ ] IdPでアカウントを作成した場合、そのアカウントでパスワードリセットはできないようにする
+  - IdPでアカウントを作成した場合、そのアカウントにはパスワードそのものがないはず
+  - パスワードリセットによって、パスワードが設定できてしまうと、パスワードレスじゃなくなるため、セキュリティの強度が下がる
+  - IdPのみのアカウント(マージされていないアカウント)の場合は、パスワードリセットは、SSOでログインできる有無のメールをリセットメールの代わりに送信するなど
+- [ ] パスワードリセットによって、そのアカウントの存在が判定できないようにする
+  - パスワードリセットの結果(レスポンス)が、アカウントの存在の有無で変わらないようにする
+  - メールの内容を変更すればいいので、レスポンスはアカウントの有無で変更しない
+  - 攻撃者が機械的にパスワードリセットしていくことで、アカウントのスクリーニングを防ぐ目的
+  - [セシールオンラインショップへの不正アクセス、二重登録防止機能を悪用しリストをスクリーニング（ディノス・セシール） | ScanNetSecurity](https://scan.netsecurity.ne.jp/article/2018/06/12/41039.html)
+- [ ] 多要素認証を推奨する
+- [ ] 多要素認証を有効化した際に、そのアカウントのセッションを全て無効化する