【転載】実際の問題シリーズ：会社のSMSインターフェースが攻撃された、どう防ぐか

title: 【転載】実際の問題シリーズ：会社の SMS インターフェースが攻撃された、どう防ぐか
date: 2021-08-06 08:51:49
comment: false
toc: true
category:

テクニック
tags:
転載
攻撃
防止
SMS
インターフェース
問題

この記事は転載です：実際の問題シリーズ：会社の SMS インターフェースが攻撃された、どう防ぐか

QQ や WeChat が登場した後、SMS の役割は個人にとって特に重要ではなくなったようです。普段、友人とのコミュニケーションは WeChat（QQ もあります）を通じて行われ、SMS の役割は徐々に薄れてきました。しかし、開発者としては SMS プラットフォームに触れることがあります。
SMS の現在の用途：

ウェブサイトやアプリのセキュリティ検証（登録、ログイン、パスワード変更など）
広告のプッシュによる迷惑
誕生日の祝福（資産管理、保険、銀行から）
彼女の誕生日
そして自信を持って A 商品を販売する（興味がある方は文末を見てください）
.......

現在、アリババクラウド、百度クラウド、テンセントクラウドにはそれぞれの SMS プラットフォームがあり、私たちのシステムにも統合されています。

以前、私たちの本番環境のシステムはそのうちの 1 つの SMS プラットフォームを設定しており、すでに 2 年間継続して使用しています。

最近の使用中に、悪意のある送信によって数万件の SMS が送信される事例が発生しました（プラットフォーム上で毎日の最大制限を設定することをお勧めしますが、私たちは設定していませんでした）。

私たちの一部の SMS インターフェースは public で（パスワードを忘れた場合や登録機能）、認証なしで直接 API 呼び出しが可能です。また、私たちのシステムでも一部の頻度制御を行っていますが、IP 制限は行っていません。

SMS 機能はどのように開発すれば安全になるのでしょうか。

一言で言えば：インターネット上に本当の安全は存在しません。安全は相対的であり、攻撃者のコストをできるだけ高くすることが重要です。

初心者：送信できるかどうかだけを考え、SMS プラットフォームの API ドキュメントを研究し、コードをデバッグし、最終的に正常に SMS を送信できるようにします。ビジネス関連のコードを書き、関連情報をストレージキャッシュし、検証を待ち、SMS 機能の開発が完了します。

ベテラン：SMS プラットフォームの API ドキュメントを研究し、コードをデバッグし、正常に SMS を送信できるようにします。SMS インターフェースをさらに封装し、頻度制御を追加します。例えば、SMS送信間隔時間、認証コードの有効期限、同一アカウントの送信制限、回数制限の間隔時間など。設定は以下の通りです。

captcha:
    sms:
      # SMS認証コードの有効期限（分）
      expire: ${SMS_EXPIRE:5}
      # 認証コード送信間隔時間（秒）
      interval: ${SMS_INTERVAL:60}
      # 同一アカウントの送信回数制限
      limit-time: ${SMS_LIMIT_TIME:10}
      # 回数制限の間隔時間（時間）
      limit-interval: ${SMS_LIMIT_INTERVAL:12}

さらに、呼び出し IP 制限を追加します（同一 IP からの頻繁なインターフェース呼び出しを防ぐため）。その後、ビジネスコードを書き、開発を完了します。

無効な SMS 送信をフィルタリングすることもできます。例えば：

1. 電話番号の検証#

不適格な電話番号は送信しないようにし、Google のコンポーネントを使用して検査できます。国内外の電話番号を検証できます。

<dependency>
    <groupId>com.googlecode.libphonenumber</groupId>
    <artifactId>libphonenumber</artifactId>
    <version>8.12.6</version>
</dependency>

2. 登録機能#

システムに既に存在する場合は送信しないようにし、SMS を送信する際に電話番号が既に登録されているかどうかを検証します。実際に登録データを提出する際に検証するのではなく。

3. パスワード変更#

システムに存在しない場合は送信しないようにし、認証コードを送信する際に電話番号がシステムのユーザーであるかどうかを検証します。

上記の方案は同一の電話番号と IP に対して頻度制御を行っていますが、攻撃者が IP を頻繁に変更して異なる電話番号に SMS を送信する場合、SMS の無駄遣いやユーザーへの迷惑を避けることはできません。

解決するためには、画像認証コードまたは行動式認証コードを使用する必要があります。

画像認証コードは比較的簡単で、費用もかからず、自分でプログラムを開発すれば実現できます。効果は以下の通りです。

このように視覚的に見た目が難しく、ユーザーの入力操作を増やす必要があるため、体験はあまり良くありません。また、機械がその中の文字を認識して解析するのは比較的容易です。機械の認識の難易度を上げたい場合は、画像のぼかしを増やす必要があり、そうするとユーザーの誤り率がさらに高くなり、体験が悪化します。

行動式認証コードについては、年末年始の切符購入で人々を苛立たせる 12306 の画像認証を挙げざるを得ません。これはタッチ式のもので、以下のようになります。

現在、より一般的に使用されている方法はドラッグ式のもので、以下のようになります。

この体験は画像認証よりもはるかに良く、便利で美観的であり、背景画像を広告に使用することもできます。

行動式認証の核心的な考え方は、ユーザーの「行動特性」を利用して安全性の判別を行うことです。機械学習や深層学習を通じて人の行動特性を大量に分析し、安全モデルを構築して人と機械プログラムを区別します。深層学習で構築された神経ネットワークは、自主的に学習を続けることができ、検証の過程で新しい特性分析を学び続けます（出典：百度百科）。

一般企業にはこの能力がなく、費用がかかります。

費用をかけたくない場合は、画像を切り抜いて簡単なスライドブロックを実現することもできます。サーバー側はスライドブロックの位置を画像の端からの距離として記録し、元の画像とスライドブロックをフロントエンドに提供します。ユーザーがスライドした後、スライドした距離をサーバーに送信し、サーバーはユーザーがスライドブロックをドラッグした距離を比較して正しいかどうかを検証します（安全性は不十分です）。

さらに、API に制限を追加することもできます。

まとめ#

頻度制御を行い、SMS送信間隔時間、認証コードの有効期限、同一アカウントの送信制限、回数制限の間隔時間を制御します。
IP によるインターフェースの呼び出し頻度を増やします。
検証を通じて不必要なインターフェース呼び出しを避けます。例えば、電話番号形式の検証、登録機能：システムに既に存在する場合は送信しない、パスワード変更：システムに存在しない場合は送信しない
行動式認証コードを追加します。
制限を設けます。

“ やはりその言葉、絶対的な安全は存在せず、安全は攻撃と防御の戦いです。 ”