Webサービスぶっ壊れ地獄、行きやすぜ！
はじめに
なあジョージさんよ……あんた、いつもこう言ってたよな？
「便利さとシンプルさ、それがユーザーも開発者も幸せにする秘訣だ」ってよ。
あたしゃな、その言葉に乗っかっちまった。ユーザーのため？ 開発を効率化するため？
そりゃあ立派なもんだ。でもな、それが「命取り」になることがあるんだぜ。
シンプルに作ったはずのサービスが、悪意ある奴らに好き勝手利用されて、時には「あたしの知らなかった地獄」を見せてくれる。越えたらいけない一線がある。そんな話を、今日はしようじゃねえか。
さあ、これがあたしらの舞台だ。
セキュリティの教科書には載らない、バグバウンティでも指摘されない、ニュースにもならない、「 現場のWebサービスぶっ壊れ地獄 」
……教えてやりますぜ！！
1. サインアップし放題からのクレカ決済し放題地獄
この地獄、知ってやがるかい？
聞いてくれよ。ユーザーを簡単にサインアップさせる……そいつは、あんたのサービスの「顔」でありゃあ、看板だ。だがな、そのシンプルさ、悪い奴らが嗅ぎつけるとどうなる？
「サインアップし放題」 だ。それだけなら、まだいいかもねえ。
悪党どもがさらに頭をひねると、どうなりやすかね？
無限にアカウント作成 → 無限にクレカ決済を試行！
「クレジットマスター攻撃」 ってやつだ。
どいつもこいつも次々とアカウントを作っては、あんたのサービスの決済APIエンドポイントをポコポコ叩きやがる。気がつきゃ、クレカ決済会社もカード保有者も被害を受け、あんたのサービスは「不正利用の温床」として悪名高くなるって寸法さ。
おまけに？ そのユーザーが即解約、また即課金……そんな流れを許してたら、そこはもう地獄だろうがよ……。
対策？ あたしゃこう考える
- サインアップ後、クレカ決済前の「電話番号認証」か「メール認証」を必須にする。
- 追加の認証ができていてもサインアップの直後はクレカ決済を制限する。悪い奴らは急ぎますからね。
- 決済 → 即解約 → 即再決済 なんて動きは確実に検知して、きっちりブロックしなきゃあな。
なあ、ジョージさんよ。
「面倒くせえ」って？ そう言ってたら、あんたのサービスは「地獄の入り口」になるだけですぜ。
2. ありえんほどデカいリクエスト地獄
「便利」ってやつが招いた惨劇だ
APIってのは便利だよな、ジョージさんよ……でもな、「便利」に甘えすぎると、ろくなことにならねえ。
例えばよ、あんたのAPIエンドポイント。クエリパラメーターに数百文字、数千文字のデータを詰め込まれたらどうなる？
「ありえんほどデカいリクエスト地獄」 ってやつさ。
わかりやすか……？ たったの数百文字、数千文字の話で。
現実の現場には、サービスをワンパンでいきなりぶっ壊してくる、極めて洗練された、 味な攻撃的リクエスト というものがありやしてね。何万文字だとか何千回も、全然いらねえんですわ。まったく冗談じゃねえけど……。
攻撃者はよ、そいつを使ってサーバーに負荷をかけまくる。最悪の場合、リクエスト10発でCPU使用率が100%にもなるんですわ。
APIバックエンドはステートレスでスケールアウトできる？ そりゃあそうでしょうよ。しかし、さらに裏側にあるKVSや検索エンジンや外部APIはどうですかね。…くくっ、確認しやしたか？ 数百文字や数千文字で本当にぶっ壊れないこと を。
なあ、それがどんな気分かわかるか？ あんたのサービスが、通常のユーザーにすらマトモに応答できねえ……そいつは、「終わり」ってやつだろうがよ……。
対策？ あたしの提案だ
- GETリクエストのクエリパラメーターの文字数制限をつける。例えば、ほとんどのパラメーターは1000文字未満で十分ですぜ。
- 認証制限やレートリミットをかける。例えば、ログイン済みでなければ弾く、ログイン済みかつ同一ユーザーからの1秒間に100リクエスト以上は弾くってな。
- 入力フォームにはサーバー側でも文字数チェックのバリデーションをする。例えば、1000文字の検索クエリ、1000文字のユーザー名なんて、マトモじゃあないでしょう。
ジョージさん、これは「サービスを守る最低限」ですぜ。甘く見ちゃいけねえよ。
3. メール送られまくり地獄
「便利」ってやつが招くメールの嵐
あんたのサービスが、メールを通じた「パスワードリセット機能」や「招待機能」、「お知らせ機能」を持ってるのはいいことだ。でもな、これが無制限に実行可能だとどうなるか……
「メール送られまくり地獄」 の幕開けだ。
攻撃者はよ、短期間であっという間に何万通ものメールを送れるようになっちまう。
するとどうなる？ あんたらのメール送信元はスパム扱い、重要な通知メールは通常のユーザーに届かなくなる……おまけに、大抵のメール送信サービスは従量課金請求ですぜ。
結局のところ、この「便利」がサービスの首を絞めちまうんだよ。
対策？ あるのよ
- 各メール送信機能にレートリミットをつける。例えば、1分間に10人も招待すれば十分だろうよ。
- ユーザーのアクションでは通知メールを送信しない。例えば、一日や一週間単位でお知らせをまとめて送ったほうが、受け取る側も便利ってもんよ。
ジョージさんよ……あんたのサービスが「メール送り放題」になった日には、翌月の請求が一体どうなるか、想像してみな。
おわりに
酒…女……博打………へ……つまんねえ…
あたしのタイクツを吹き飛ばしてくれるのは、「Webサービスぶっ壊れ地獄」だけですぜ！！
ジョージさん、あんたがシンプルさと利便性を追い求めるのはわかる。でもよ、それが時として「地獄」への片道切符になるってこと、忘れちゃいけねぇですぜ。
あたしが今日話した3つのリスク――
- サインアップし放題からのクレカ決済し放題地獄
- ありえんほどデカいリクエスト地獄
- メール送られまくり地獄
どれも地味でニュースにもなりやしませんが、現場じゃあ、しょっちゅう起きてることでしてね。
個人情報や機密情報が漏洩しなくても、データを改竄されなくても、Webサービスはしっかりぶっ壊れて、地獄になることがあるんですぜ。
さあて、
セキュリティの教科書には載らない、バグバウンティでも指摘されない、ニュースにもならない、「 現場のWebサービスぶっ壊れ地獄 」
は、今日話した3つだけだと思いますかい？
で…お代はいかほどいただけるんで……？
Discussion
最後にようやく阿紫花だとわかった
セキュリティはなんとなく理解できてるつもりだけど、いまだにこういう類のものの知見がないので新鮮でした 🙏