RESTリクエストの承認
-
04-07-2019 - |
質問
いくつかの要件があるRESTサービスに取り組んでいます:
- 安全でなければなりません。
- ユーザーはリクエストを偽造できません。
現在提案されているソリューションは、次のようなカスタム認証ヘッダーを持つことです(これは、アマゾンウェブサービスが機能するのと同じ方法です):
Authorization: MYAPI username:signature
私の質問は、署名の作成方法です。ユーザーがサービスにログインすると、リクエストに署名するために使用できる秘密鍵が提供されます。これにより、他のユーザーがリクエストを送信するのを停止しますが、リクエストの偽造は停止しません。
このサービスを使用するアプリケーションはiPhoneアプリケーションであるため、追加の署名を行うことができる公開キーをアプリケーションに埋め込むことができると考えていましたが、これは2つ必要になることを意味します署名、1つはユーザーキー用、もう1つはアプリキー用ですか?
アドバイスをいただければ幸いです。初めてこれを正しく行いたいと思います。
解決
この権利を行う最も簡単な方法は、HTTPSクライアント認証を使用することだと思います。 Appleのサイトには、このテーマに関してスレッドがあります。
編集:認証を処理するために、ユーザーごとにサーバー上に個別のリソース(URI)を作成し、その(認証された)ユーザーのみがこのリソースを操作できるようにします。
Edit(2014):Appleは過去6年間でフォーラムソフトウェアを変更しました。スレッドは現在 https://discussions.apple.com/thread/1643618 にあります。 p>
他のヒント
答えは簡単です。実行できません。エンドユーザーにソリューションを出荷するとすぐに、エンドユーザーは通信しているサーバーを常に攻撃することができます。この問題の最も一般的なバージョンは、Flashゲームのハイスコアリストでの不正行為です。クライアントに何らかの暗号化を埋め込み、コードを難読化することにより、より難しくすることができます...しかし、すべてのコンパイルおよび難読化されたコードは、常に逆コンパイルおよび難読化されません。それは、あなたがどれだけの時間とお金を費やすかという問題であり、同様に潜在的な攻撃者にとっても同様です。
そのため、ユーザーがシステムに誤ったデータを送信しないようにする方法は ではありません。これは、ユーザーがシステムに損害を与えることを防ぐ方法です。欠陥のあるデータによって引き起こされるすべての損傷は、それを送信するユーザーにのみ影響するようにインターフェースを設計する必要があります。
HTTPダイジェスト認証の何が問題になっていますか?
これに関するより良い議論がここにあります: