Web サービスと通信するモバイル アプリ (現在は IOS、まもなく Android) があります。ログインはなく、データは非公開ではありません。基本的に、アプリはマーカー (経度、緯度) を POST し、最も近い 25 個のマーカーを取得してマップに表示します。
これは非常に些細なアプリであり、この Web サービスを悪用することに多大な労力を費やす人がいるとは思えません。しかし、多くのマーカーを POST することには、誰かにとっての楽しみがあることがわかります。私が最も懸念しているのは、多くのリクエストをプッシュするスクリプトを実行している誰かです (高価な帯域幅を使用し、アプリ データを無意味にしています)。
私はゆっくりと、これは安全ではないという結論に達しています。最良の答えは「これをしないでください」です。認証なしで Web サービスを提供しないでください。こんなにオープンなサービスはなかなかありません。Google の You Tube API は公開されていますが、ほとんどは公開されていません。残念ながら、仕方がありません。それで、これを何日も見た後、これが私の考えです。私はセキュリティの専門家とはかけ離れており、私のアプローチは改善できると確信しています。しかし、それはあなたを正しい方向に向けるかもしれません。うまくいけば、より経験豊富な誰かが参加して、これを修正/改善するかもしれません. この記事とコメントは特に役に立ちました。
メッセージ レベルのセキュリティ
ハッシュ暗号化でメッセージを保護します。クライアントと Web サービスはすべて、URL とすべての POST 引数からハッシュを作成するためのソルトとして使用される共有シークレットのコピーを保持します。ハッシュは追加の引数として渡され、ハッシュは再構築され、反対側で比較されます (共有キーをソルトとして使用)。これは、モバイル クライアント コードを数分でリバース エンジニアリングできることを理解するまでは、非常に良いことです。その時点で、この防衛線はまったく役に立ちません。
クライアント対策
クライアントには、正当なユーザーによって送信されるメッセージの数を制限する手段として、メッセージのレート制限が含まれています。これもまた、モバイル デバイスをジェイルブレイクする攻撃者に対しては役に立ちません。
サーバー側のセキュリティ
そのため、クライアント (および共有シークレット) が危険にさらされているという前提で独立するために、サーバー側はできるだけ多くの追加のセキュリティ対策を講じる必要があります。ここに私が持っているものがあります:
1 つのメッセージ引数は、リプレイ攻撃を制限するために使用される UTC 時間です。これにより、攻撃者がサーバーで同じメッセージを繰り返し送信するのを防ぐことができます。
サーバーは IP によるレート制限を行います。はい、IP は簡単にスプーフィングされ、プロキシ スイッチングはチャイルド プレイですが、IP がほとんどない場合はすべてが役に立ちます。
もちろん、サーバーはすべての引数を厳密に検証し、パラメーター化されたクエリを使用し、例外を返しません。
トランスポート レベルのセキュリティ
残念ながら、登録プロセスなしでは個々のクライアント SSL 証明書を発行することはできないと確信しています。また、私は msg ハッシュ チェックを使用しているため (そして私のデータは非公開ではないため)、SSL がテーブルに何をもたらすのか完全にはわかりません。ただし、SSL を使用すると、簡単かつ安価に展開できる別のレベルのセキュリティが追加されるためです (メッセージごとに追加の接続時間がかかりますが)。
私のアプローチでぽっかり大きな大きな穴
アプリが人気になった場合、誰かがクライアントの共有秘密を侵害する可能性があると警告されています. 彼らができるという理由だけで、彼らはおそらくそれをインターネットに投稿するでしょう. したがって、実際にはすべてサーバー側にかかってきます。残念ながら、攻撃者を特定してブロックする方法はありません。これは私が心から愛するでしょう。
最後の嘆願
数日間の調査の後、これが私が持っているすべてです。でももっと欲しい。サーバー側を強化するためのアイデアがあれば特に感謝します。だから、私はすべてのSOポイントを賞金として上げました. はい、全部で97点!