Twilioが攻撃されたけどあまり痛くなかった。RetrospectiveTwilioが攻撃されたけどあまり痛くなかった。2019-10-22この記事は約4分で読めます。こんばんわ、hisayukiです。暇な人がいるもので、13時〜14時の間に370回近くのCallを受けましたね・・・というわけで、対応を書き残します。被害は自体ほぼありませんでした。攻撃されたといっても、Twilioの電話番号に電話掛けられてるだけなので。電話系サービス作る時点でこの辺りは考慮して、よくわからない人からの電話を繋がないようにはしてます。番号どうしてもれた?運用中サービスは登録型の電話サービスです。そのため、もともとサービスに登録している人しか電話ができない仕組みになってます。一応仕組み的にはサービス登録者からじゃないと番号は見えない様になっています。登録者は電話をかける際にTwilio側の電話番号を知ることになるので漏れる可能性は全然ありましたね。ある程度は仕組みで回避まずTwilio側の番号にかけると、WebhookでAPIサーバーに問い合わせてTwiMLを取得します。かかってきた番号と登録情報を紐付けて存在している場合は、実際の相手の電話番号に転送するTwiMLを返しています。</Dial></Response>それがホワイトリスト的な機能になっているので、登録者以外の電話番号からの着信はすべてBusyになるTwiMLが返ってきます。加えてサービス側の仕様で、登録者でもサービスから通話ボタンを押すことで初めて通話先との通話ルート情報がDBに格納されます。DBに問い合わせてこのルート情報が無ければBusyになるTwiMLが返ってきます。reason="busy"/></Response>なので今回のようにサービス未登録者がループで電話番号に攻撃するようなことされても、実際つながらないわけです。例外もあるただ、1回だけサーバーアクセスに失敗してます。Gatewayになりました。この時だけはAPIで返ってくるはずのTwiMLが取得できなかったので接続した扱いに。繋がってもTwiMLないのでその先の挙動もないんですけどね。結局やったこと一度番号漏れてしまってるのでTwilio側の番号は取り直しをしました。いう時に電話番号すぐすり替えられるのがTwilioのいいところですね。あと、知らなかったのですがWebhookでAPIの呼び出しに失敗した場合の挙動が設定できたようです。Gatewayで返ってきた場合のハンドリングもできるという事。Binを指定できるので予めbusy用のTwiML作っておけば、サーバーにつながらなければ一旦busyってこともできますね。まとめ今回特に被害はなかったのでよいのですが、困るのはAPIサーバーへの通信です。Twilioの番号に着信があるたびにAPIサーバーとの通信が発生するので、サーバーに負荷がかかるのは頂けない・・・なので、Twilioの番号にかかってきて、Webhook飛ばす前の時点でのフィルタリング機能があるといいですね。やり方はブラックリスト方式でもいいですし、ホワイトリスト方式でもいいですし。ホワイトリスト方式ならSDKでサービス登録時にTwilio側にも登録できる仕組みにしたいな〜あとは機械学習とかでおかしな挙動してる番号をブロックとかでもありがたいです。今のサービスでは、ポイ...技術ネタとあるSNSのSMS認証をTwilioで解決してみたこんばんわ、hisayukiです。今回、某SNSにて別アカウントの凍結をくらいまして・・・ちょっと止めるわけに行かないので、なんとか別アカ作って復旧しました。今回はサービス名をハッキリ書かずに某SNSで突き通します。...技術ネタTwilioSDKで翻弄されていますどうもhisayukiです。いうわけで、今日はTwilioSDKの所で...2019年上半期が終わったので振り返りしてみます。コメントをキャンセルメールアドレスが公開されることはありません。