クレジットマスターとの戦い

Transcript

1. クレジットマスターとの戦い PHPカンファレンス 2023/10/08 仲見川勝人@NakMeKtt
2. - 仲見川 勝人（@NakMeKtt） - 職業 - Software Engineer - Mobile App, Front End, Server Side - 所属 - 株式会社ホワイトプラス - 宅配クリーニング「リネット」の開発 - Tech lead - アプリ開発G Engineering Manager 2 自己紹介
3. - 後ほどforteeの本セッションproposalページにアップします - https://fortee.jp/phpcon-2023/proposal/da4ef7a1-3aa9-47a9-bd87-c1c03ac68b65 3 本日のスライド
4. - クレジットマスターとは？ - クレジットマスター対策として私たちが行ったことについてLaravelの throttleを中心にお話 - throttleとは別に行った対策について軽くご紹介 4 本日の内容
5. 5 クレジットマスターとは？
6. クレジットマスターとは、クレジットカード番号の規則性を悪用し、他人の カード番号を割り出す犯罪行為を指す言葉です。 聞き慣れない手口ですがその歴史は古く、アメリカでは1989年から、日本では 1999年から被害が確認されています。この手口により、カードそのものは手元 にありながらも知らないうちにクレジットカード番号が盗まれるといった被害 が相次いでいるのです。 6 クレジットマスターとは？ 三井住友カードWebサイトより https://www.smbc-card.com/mem/hitotoki/solution/credit_master.jsp
7. クレジットカード番号の規則性（例） - 先頭数桁がIssuer（発行者）を示す - Visaは4始まり、MasterCardは51、55始まりなど - 16桁の数字である（Issuerによって15桁や14桁の場合も） - 0000-0000-000-000 - 最後の1桁は特定のアルゴリズムを用いたチェックサム 7 クレジットマスターとは？
8. 有効期限やCVCなどもある為、カード番号が一致しても簡単に使 用することは出来ません、 これらの規則性に基づいた番号を使えるか確認する方法は？ 8 クレジットマスターとは？
9. 有効期限やCVCなどもある為、カード番号が一致しても簡単に使 用することは出来ません、 これらの規則性に基づいた番号を使えるか確認する方法は？ 9 クレジットマスターとは？ Issuerに決済出来るか問い合わせる
10. どのようにして？ - 当然攻撃者がIssuerと契約を結んで行うことはない 10 クレジットマスターとは？
11. どのようにして？ - 当然攻撃者がIssuerと契約を結んで行うことはない 11 クレジットマスターとは？ ECショップなどでカード登録出来るか繰り返し試行する ↑これがクレジットマスター攻撃
12. 12 弊社の事例
13. - 決済代行会社より同一顧客にて連続した多数の有効性確認があり不正ア タックの可能性があると連絡が入る - 調べたところクレジットカードの有効性を検証しているAPIでクレジットマ スターの対応が行われていないことが判明 - この際は、一次対応としてすぐにユーザーを特定しCSと連携しながら 通常の利用者ではないと判断し該当アカウントを停止 13 ある日......
14. - このAPIはユーザー情報が無いケース（新規ユーザー）の場合 もあることから処理時点では識別する情報を持っていない - なので、顧客ID単位などで制限をかけるだけではダメ 14
15. - Laravelのルーティングによるレート制限（以降throttle）を 行うのがよさそう - 認証している場合は顧客ID単位で制限可能 - 未認証の場合でもIPベースで同一のアクセスを制限可能 15
16. ルーティングにthrottleを導入すること自体はとても簡単で、最 小限だと以下のように記述出来ます。 これで、/example/validateは1分に10回の制限となります。 16
17. 制限を超過すると429が返されます。 また、Response Headerに以下が載っているためどのような制限がかかってい るか知ることが出来ます。 - Retry-After（制限が解除される時間） - X-Ratelimit-Limit（レートリミットの閾値） - X-Ratelimit-Remaining（閾値までのカウントダウン） 17
18. - 実際に設定した物に近い設定内容 18
19. 'throttle:10|20,30,throttle_id_1', 19 未認証での制限回数 （IPアドレス制限） 認証済での制限回数 （UserID制限） 範囲（分） throttleの単位（Key） ※弊社の環境（K8s[Ingress]→Nginx→php-fpm）ではユーザーのIPアドレスで制限がかかってることを確認
20. 'throttle:10|20,30,throttle_id_1', 'throttle:5|10,1,throttle_id_2' 20 上記の定義は 未認証の場合30分に10回、認証済の場合は30分に20回の制限 または 未認証の場合1分に5回、認証済の場合は1分に10回の制限 となります。
21. ここまではLaravel7.xまでの書き方 （※10.xでも動きます） 8.x以降新しい書き方があります 21
22. 8.x以降は（Routeは） こう書けます！すっきりしましたね！ 22
23. はて？ 何分に何回とか設定してなくない？ 23
24. 8.x以降は（Routeは） こう書けます！すっきりしましたね！ 24
25. 実体はRouteServiceProviderクラスのbootメソッドに置きま す。先ほどと同じ内容を設定した物がこちら 25
26. コード量は増えていますが、ロジックとして書けるため個人的に はこちらの書き方の方が好みです。 26
27. 注意点というか個人的にハマったポイントとして、 Limit::perMinute()->by($key)の$key部分が他の制限と重複し ないようにしなければなりません。 keyの重複がある場合、時間制限は長い方、回数は少ない方が採 用されるなど意図しない動作となりました。 27 Limit::perMinute(5) 　　->by('throttle_id_1_' . $request->ip()),
28. 28 https://laravel.com/docs/10.x/routing#multiple-rate-limits ドキュメントにkeyについては説明があまりなく、どのように チェックしているかロジックと実際の振る舞いを検証したとこ ろ。 キャッシュのkeyとしてそのまま使用されているようでした。 そのため、同一keyに複数のRateLimitの時間や回数がアクセス を行い意図しない動作となっている事がわかりました。 ※正しくソースを読み切れているか自信が無いので詳しい方いたら是非教えてください
29. 29 https://laravel.com/docs/10.x/routing#throttling-with-redis defaultはCacheファサード、Redisを明示的に指定も可能
30. throttleで試行回数の制限はできた 30
31. throttleしたからといって クレジットマスターに対して安全ではない 充分に有効だとは考えていますが、 あくまで試行回数を稼げないようにやりづらくしただけ 31
32. throttleの制限にかかった （攻撃を受けている） ことを検知したいですよね？ 32
33. とは言え、発生都度Slack等に通知すると - 100回行われたら100回Slack通知が来 るとしんどい - なんならSlackのAPI制限で他の通知も 止まる巻き込み事故が起きかねない 33
34. なので特定のログが出力されたら 1時間1回だけ通知して欲しい 34
35. クラウドインフラとしてGoogle Cloudを利用しているためCloud Loggingの「ログベースのアラート」を使って通知することに。 一定期間内で閾値を越えたら発報するという定義が作れる。 この仕組みを使いSlack通知を構築。 「ログベースのアラート」ドキュメント https://cloud.google.com/logging/docs/alerting/log-based-alerts?hl=ja 35
36. まずはthrottleで制限がかかった際にログを 出力するようにします 36
37. 制限がかかった場合 ThrottleRequestsExceptionが投げられる ためこれをハンドリングします 37
38. app/Exception/Handler.phpに記述を追加。 report()の方が目的には沿っているのですが、request内容がほ しかったのでrender()をオーバライドしています。 38
39. ログベースのアラートは ドキュメントを参考に構築 39
40. 運用開始！ 40
41. 後日throttleの制限範囲で細々と続けられて いるケースを検知……ｳｾﾔﾛ 41
42. 検知する仕組みを入れておいて良かった 42
43. 調査したところ、ゲストでは無く会員登録のあるユーザーで行わ れていた。 （新規会員登録の場合、全ての情報を入力しないとカード情報入 力にたどり着かないので効率が悪いのだと思われる） 43
44. - 打ち手 - 会員登録後に行われている事から会員IDが特定可能 - 一定期間内に閾値を超えたチャレンジがあった場合に該当 ユーザーからのクレジットカード登録を永久凍結 - 一般ユーザーが誤って凍結されてしまった場合はCS問合 せにて解除する 44
45. 通常の機能開発と同様に開発 ※こちらの仕組みは最近の施策なので まだ成果は出ていません 45
46. まとめ 46
47. クレジットマスターなどの攻撃に対して - throttleは一定の効果があった - 流量制限の為の機能なので充分とは言えない - Laravelの標準機能なので導入が簡単なため取り急ぎの対 策としてはよかった - 状況に応じて次の手を打っていく事が大事 - そのために検知の仕組みも重要 47
48. 俺たちの戦いはこれからだ！ 48
49. ご静聴ありがとうございました 49
50. Appendix 50
51. 他のクレジットマスター対策 51
52. - クレジットカード登録時にSMSやメールでの多要素認証を必 須として攻撃により手間がかかるようにする - reCAPTCHA v3などのスパム抑止サービスを導入する 52
53. - クレジットカード登録時にSMSやメールでの多要素認証を必 須として攻撃により手間がかかるようにする - reCAPTCHA v3などのスパム抑止サービスを導入する これらは通常利用してくれるユーザーにとっては手間が増えるため現状の対策 で問題が出た場合の対策として今後の状況により検討。 53
54. - WAF(Web Application Firewall) 54
55. - WAF(Web Application Firewall) クレジットカード登録のリクエスト自体は正規のリクエストとなるため、WAF で防げるのはDDoS攻撃と判断された場合と想定。その場合、今回行った throttleの対応で十分なためクレジットマスター対策としては除外。 55