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.3k
クレジットマスターとの戦い
Nakamigawa
October 08, 2023
Tweet
Share
More Decks by Nakamigawa
See All by Nakamigawa
宅配クリーニングサービス「Lenet」開発におけるDDD7年の歩み
nakamigawa
0
2.7k
PHPカンファレンス関西202402 nullsafe演算子を使おう〜if文地獄からの開放〜
nakamigawa
0
350
null判定をis_nullでしてたけど止めた話
nakamigawa
0
380
Other Decks in Technology
See All in Technology
OPENLOGI Company Profile for engineer
hr01
1
22k
OCI見積もり入門セミナー
oracle4engineer
PRO
0
110
DevinはクラウドエンジニアAIになれるのか!? 実践的なガードレール設計/devin-can-become-a-cloud-engineer-ai-practical-guardrail-design
tomoki10
3
1.3k
非エンジニアにも伝えるメールセキュリティ / Email security for non-engineers
ykanoh
13
3.8k
バックエンドエンジニアによるフロントエンドテスト拡充の具体的手法
kinosuke01
1
630
3/26 クラウド食堂LT #2 GenU案件を通して学んだ教訓 登壇資料
ymae
1
190
Explainable Software Engineering in the Public Sector
avandeursen
0
340
お問い合わせ対応の改善取り組みとその進め方
masartz
1
290
パスキーでのログインを 実装してみよう!
hibiki_cube
0
590
ペアプログラミングにQAが加わった!職能を超えたモブプログラミングの事例と学び
tonionagauzzi
1
130
PostgreSQL Unconference #52 pg_tde
nori_shinoda
0
190
これからクラウドエンジニアになるために本当に必要なスキル 5選
hiyanger
1
460
Featured
See All Featured
YesSQL, Process and Tooling at Scale
rocio
172
14k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Building a Modern Day E-commerce SEO Strategy
aleyda
39
7.2k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Fontdeck: Realign not Redesign
paulrobertlloyd
83
5.4k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
16
1.1k
Building Applications with DynamoDB
mza
94
6.3k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
The Language of Interfaces
destraynor
157
24k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
177
52k
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