Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
クレジットマスターとの戦い
Search
Nakamigawa
October 08, 2023
Technology
0
1.4k
クレジットマスターとの戦い
Nakamigawa
October 08, 2023
Tweet
Share
More Decks by Nakamigawa
See All by Nakamigawa
宅配クリーニングサービス「Lenet」開発におけるDDD7年の歩み
nakamigawa
0
2.9k
PHPカンファレンス関西202402 nullsafe演算子を使おう〜if文地獄からの開放〜
nakamigawa
0
410
null判定をis_nullでしてたけど止めた話
nakamigawa
0
440
Other Decks in Technology
See All in Technology
Delegating the chores of authenticating users to Keycloak
ahus1
0
190
Introduction to Bill One Development Engineer
sansan33
PRO
0
260
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
18k
QuickSight SPICE の効果的な運用戦略~S3 + Athena 構成での実践ノウハウ~/quicksight-spice-s3-athena-best-practices
emiki
0
290
セキュアな社内Dify運用と外部連携の両立 ~AIによるAPIリスク評価~
zozotech
PRO
0
130
振り返りTransit Gateway ~VPCをいい感じでつなげるために~
masakiokuda
4
210
データ駆動経営の道しるべ:プロダクト開発指標の戦略的活用法
ham0215
2
140
【あのMCPって、どんな処理してるの?】 AWS CDKでの開発で便利なAWS MCP Servers特集
yoshimi0227
6
990
Deep Security Conference 2025:生成AI時代のセキュリティ監視 /dsc2025-genai-secmon
mizutani
4
3.1k
AWS CDK 入門ガイド これだけは知っておきたいヒント集
anank
5
770
サイバーエージェントグループのSRE10年の歩みとAI時代の生存戦略
shotatsuge
4
1.1k
三視点LLMによる複数観点レビュー
mhlyc
0
240
Featured
See All Featured
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.5k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Unsuck your backbone
ammeep
671
58k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Visualization
eitanlees
146
16k
Scaling GitHub
holman
460
140k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
BBQ
matthewcrist
89
9.7k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Transcript
クレジットマスターとの戦い PHPカンファレンス 2023/10/08 仲見川勝人@NakMeKtt
- 仲見川 勝人(@NakMeKtt) - 職業 - Software Engineer - Mobile
App, Front End, Server Side - 所属 - 株式会社ホワイトプラス - 宅配クリーニング「リネット」の開発 - Tech lead - アプリ開発G Engineering Manager 2 自己紹介
- 後ほどforteeの本セッションproposalページにアップします - https://fortee.jp/phpcon-2023/proposal/da4ef7a1-3aa9-47a9-bd87-c1c03ac68b65 3 本日のスライド
- クレジットマスターとは? - クレジットマスター対策として私たちが行ったことについてLaravelの throttleを中心にお話 - throttleとは別に行った対策について軽くご紹介 4 本日の内容
5 クレジットマスターとは?
クレジットマスターとは、クレジットカード番号の規則性を悪用し、他人の カード番号を割り出す犯罪行為を指す言葉です。 聞き慣れない手口ですがその歴史は古く、アメリカでは1989年から、日本では 1999年から被害が確認されています。この手口により、カードそのものは手元 にありながらも知らないうちにクレジットカード番号が盗まれるといった被害 が相次いでいるのです。 6 クレジットマスターとは? 三井住友カードWebサイトより https://www.smbc-card.com/mem/hitotoki/solution/credit_master.jsp
クレジットカード番号の規則性(例) - 先頭数桁がIssuer(発行者)を示す - Visaは4始まり、MasterCardは51、55始まりなど - 16桁の数字である(Issuerによって15桁や14桁の場合も) - 0000-0000-000-000 -
最後の1桁は特定のアルゴリズムを用いたチェックサム 7 クレジットマスターとは?
有効期限やCVCなどもある為、カード番号が一致しても簡単に使 用することは出来ません、 これらの規則性に基づいた番号を使えるか確認する方法は? 8 クレジットマスターとは?
有効期限やCVCなどもある為、カード番号が一致しても簡単に使 用することは出来ません、 これらの規則性に基づいた番号を使えるか確認する方法は? 9 クレジットマスターとは? Issuerに決済出来るか問い合わせる
どのようにして? - 当然攻撃者がIssuerと契約を結んで行うことはない 10 クレジットマスターとは?
どのようにして? - 当然攻撃者がIssuerと契約を結んで行うことはない 11 クレジットマスターとは? ECショップなどでカード登録出来るか繰り返し試行する ↑これがクレジットマスター攻撃
12 弊社の事例
- 決済代行会社より同一顧客にて連続した多数の有効性確認があり不正ア タックの可能性があると連絡が入る - 調べたところクレジットカードの有効性を検証しているAPIでクレジットマ スターの対応が行われていないことが判明 - この際は、一次対応としてすぐにユーザーを特定しCSと連携しながら 通常の利用者ではないと判断し該当アカウントを停止 13
ある日......
- このAPIはユーザー情報が無いケース(新規ユーザー)の場合 もあることから処理時点では識別する情報を持っていない - なので、顧客ID単位などで制限をかけるだけではダメ 14
- Laravelのルーティングによるレート制限(以降throttle)を 行うのがよさそう - 認証している場合は顧客ID単位で制限可能 - 未認証の場合でもIPベースで同一のアクセスを制限可能 15
ルーティングにthrottleを導入すること自体はとても簡単で、最 小限だと以下のように記述出来ます。 これで、/example/validateは1分に10回の制限となります。 16
制限を超過すると429が返されます。 また、Response Headerに以下が載っているためどのような制限がかかってい るか知ることが出来ます。 - Retry-After(制限が解除される時間) - X-Ratelimit-Limit(レートリミットの閾値) - X-Ratelimit-Remaining(閾値までのカウントダウン)
17
- 実際に設定した物に近い設定内容 18
'throttle:10|20,30,throttle_id_1', 19 未認証での制限回数 (IPアドレス制限) 認証済での制限回数 (UserID制限) 範囲(分) throttleの単位(Key) ※弊社の環境(K8s[Ingress]→Nginx→php-fpm)ではユーザーのIPアドレスで制限がかかってることを確認
'throttle:10|20,30,throttle_id_1', 'throttle:5|10,1,throttle_id_2' 20 上記の定義は 未認証の場合30分に10回、認証済の場合は30分に20回の制限 または 未認証の場合1分に5回、認証済の場合は1分に10回の制限 となります。
ここまではLaravel7.xまでの書き方 (※10.xでも動きます) 8.x以降新しい書き方があります 21
8.x以降は(Routeは) こう書けます!すっきりしましたね! 22
はて? 何分に何回とか設定してなくない? 23
8.x以降は(Routeは) こう書けます!すっきりしましたね! 24
実体はRouteServiceProviderクラスのbootメソッドに置きま す。先ほどと同じ内容を設定した物がこちら 25
コード量は増えていますが、ロジックとして書けるため個人的に はこちらの書き方の方が好みです。 26
注意点というか個人的にハマったポイントとして、 Limit::perMinute()->by($key)の$key部分が他の制限と重複し ないようにしなければなりません。 keyの重複がある場合、時間制限は長い方、回数は少ない方が採 用されるなど意図しない動作となりました。 27 Limit::perMinute(5) ->by('throttle_id_1_' . $request->ip()),
28 https://laravel.com/docs/10.x/routing#multiple-rate-limits ドキュメントにkeyについては説明があまりなく、どのように チェックしているかロジックと実際の振る舞いを検証したとこ ろ。 キャッシュのkeyとしてそのまま使用されているようでした。 そのため、同一keyに複数のRateLimitの時間や回数がアクセス を行い意図しない動作となっている事がわかりました。 ※正しくソースを読み切れているか自信が無いので詳しい方いたら是非教えてください
29 https://laravel.com/docs/10.x/routing#throttling-with-redis defaultはCacheファサード、Redisを明示的に指定も可能
throttleで試行回数の制限はできた 30
throttleしたからといって クレジットマスターに対して安全ではない 充分に有効だとは考えていますが、 あくまで試行回数を稼げないようにやりづらくしただけ 31
throttleの制限にかかった (攻撃を受けている) ことを検知したいですよね? 32
とは言え、発生都度Slack等に通知すると - 100回行われたら100回Slack通知が来 るとしんどい - なんならSlackのAPI制限で他の通知も 止まる巻き込み事故が起きかねない 33
なので特定のログが出力されたら 1時間1回だけ通知して欲しい 34
クラウドインフラとしてGoogle Cloudを利用しているためCloud Loggingの「ログベースのアラート」を使って通知することに。 一定期間内で閾値を越えたら発報するという定義が作れる。 この仕組みを使いSlack通知を構築。 「ログベースのアラート」ドキュメント https://cloud.google.com/logging/docs/alerting/log-based-alerts?hl=ja 35
まずはthrottleで制限がかかった際にログを 出力するようにします 36
制限がかかった場合 ThrottleRequestsExceptionが投げられる ためこれをハンドリングします 37
app/Exception/Handler.phpに記述を追加。 report()の方が目的には沿っているのですが、request内容がほ しかったのでrender()をオーバライドしています。 38
ログベースのアラートは ドキュメントを参考に構築 39
運用開始! 40
後日throttleの制限範囲で細々と続けられて いるケースを検知……ウセヤロ 41
検知する仕組みを入れておいて良かった 42
調査したところ、ゲストでは無く会員登録のあるユーザーで行わ れていた。 (新規会員登録の場合、全ての情報を入力しないとカード情報入 力にたどり着かないので効率が悪いのだと思われる) 43
- 打ち手 - 会員登録後に行われている事から会員IDが特定可能 - 一定期間内に閾値を超えたチャレンジがあった場合に該当 ユーザーからのクレジットカード登録を永久凍結 - 一般ユーザーが誤って凍結されてしまった場合はCS問合 せにて解除する
44
通常の機能開発と同様に開発 ※こちらの仕組みは最近の施策なので まだ成果は出ていません 45
まとめ 46
クレジットマスターなどの攻撃に対して - throttleは一定の効果があった - 流量制限の為の機能なので充分とは言えない - Laravelの標準機能なので導入が簡単なため取り急ぎの対 策としてはよかった - 状況に応じて次の手を打っていく事が大事
- そのために検知の仕組みも重要 47
俺たちの戦いはこれからだ! 48
ご静聴ありがとうございました 49
Appendix 50
他のクレジットマスター対策 51
- クレジットカード登録時にSMSやメールでの多要素認証を必 須として攻撃により手間がかかるようにする - reCAPTCHA v3などのスパム抑止サービスを導入する 52
- クレジットカード登録時にSMSやメールでの多要素認証を必 須として攻撃により手間がかかるようにする - reCAPTCHA v3などのスパム抑止サービスを導入する これらは通常利用してくれるユーザーにとっては手間が増えるため現状の対策 で問題が出た場合の対策として今後の状況により検討。 53
- WAF(Web Application Firewall) 54
- WAF(Web Application Firewall) クレジットカード登録のリクエスト自体は正規のリクエストとなるため、WAF で防げるのはDDoS攻撃と判断された場合と想定。その場合、今回行った throttleの対応で十分なためクレジットマスター対策としては除外。 55