web-dev-qa-db-ja.com

REST APIエンドポイントの乱用を防止する

質問1

ログインAPIエンドポイントを持っています

http://127.0.0.1:8080/api/account/login

電話番号が検証されたかどうかをチェックします。そうでない場合は、

POST http://127.0.0.1:8080/api/account/sendsms  country_code=1, phone_number=1234567

SMSのリクエストに対する悪用を防ぐにはどうすればよいですか？ （私には費用がかかります。スロットル機能もあります）
/loginが失敗した場合にのみSMSを送信します（この時点でメールは検証されています）
私が行う方法は、jwtトークンを持つ認証ヘッダーのように機能するカスタムヘッダーX-TOKEN-SMSを送信することです。 X-TOKEN-SMS jwtトークンは、電話番号が検証されていない場合は/loginで作成されます= True。
/sendsmsがエラーなしでjwtをデコードしたら、SMSのリクエストに進みます。 jwtがエラーでデコードした場合、フロントエンドは/loginにリダイレクトします。

この方法は良い方法ですか？
一部のエンドポイントにアクセスした場合にのみ、APIエンドポイントにアクセスできるようにするにはどうすればよいですか？

質問2

許可されたユーザーのみがアクセスできるエンドポイントがあるとします

http://127.0.0.1:8080/api/account/points

ユーザーはポイントを取得できます（ポイントをすべて取得できます）POSTポイント（新しいポイントを作成）またはPATCH（ポイントを更新）

承認されたユーザーがPOST/pointsを悪用することを防ぐにはどうすればよいですか？彼らは好きなようにポイントを追加する可能性がありますが、これは私のアプリの意図とは異なります。ポイントの追加はアプリで処理する必要があります論理。

ポイントの追加がREST APIによって消費されるべきではない場合、データベースに直接新しい行を作成する方が安全ですか？

同様の質問が以前に尋ねられました 認証されたユーザーからのSecure Rest api しかし、それを理解できなかったようです。

restsecurityapiauthorization
8
momokjaaaaa

最初の質問については、あなたのアプローチは私には正しいようです。 sendsmsエンドポイントでのみ生成できるトークンをloginエントリで使用します。データベースタプルの主キーとして使用される、ログインによって作成された、簡単に推測できない一般的なトークン（暗号で生成されたセッションIDと同等）を使用することもできます。そこには、好きなものを保存できます（たとえば、SMSの数はまだ送信が許可されています）。

「状態」を変数に格納し、HMACなどを使用して保護し、サーバーとクライアントの間で継続的に交換することもできますが、それでもsomeサーバーの状態を要求して、リプレイ攻撃から防御します。非べき等エンドポイント;少なくとも、セッションごとの増分カウンターが必要です。

2番目の問題はよりトリッキーであり、最初に、ロジックを備えたアプリと繰り返しリクエストを送信する悪意のあるユーザーとの間の動作の違い（サーバーから見て）がどうなるかを自問する必要があります。アプリを駆動できる最大レートに匹敵する、リクエスト間の最小遅延を強制することができます。これにより、アプリを通過するのではなくトリックを使用する利点がなくなります。

3
LSerni

ここに提案されたアプローチの問題があります。 HTTP経由でリクエストを送信すると、サードパーティがトラフィックをスヌープして認証トークンを取得できます。次に、トークンを使用して独自のリクエストをエンドポイントに送信できます。

解決策：トークンを取得するための初期認証を行うとき、およびトークンを使用するときは常に、HTTPではなくHTTPSを使用してください。

2番目の質問については、問題は基本的に扱いにくいものです。これらの「ポイント」は、ユーザーが設定したいくつかのルールに従ってのみ変更する必要があるものだと思います。ルールがこのようなものでない限り、チートを検出できますサーバー側から行き詰まっています。これを解決する唯一の方法は、サーバー側のスコアリングに直接または間接的に関与するすべてを実装することです。それはおそらくあなたのゲームの目的を無効にします。

127.0.0.1を使用していることに注意します。私はそれが実際のIPアドレスの単なるプレースホルダーだと思います。

ただし、そうでない場合は、ユーザー自身のコンピューター/デバイスで実行されているサービスと通信していることに注意してください。ユーザーが物理的なアクセスと十分な時間/専門知識を持っている場合、ユーザーはサービスに実装するアクセス制御を破壊する可能性があります。

ルールの適用または不正の防止を目的としたクライアント側のロジックにも同じことが当てはまります。

（MMOなどがチートに問題があるのはなぜか疑問に思ったことはありませんか？それはベンダーが試さないからではありません。チートがソフトウェアを制御している場合、ソフトウェアでチートを無効にするのは不可能だからです。ソフトウェアが実行されるクライアント側プラットフォーム。）

3
Stephen C