5

私は、この質問が以前にさまざまな形で尋ねられたことを知っています。ただし、「https を使用する」という回答は求めていません。私はすでに HTTPS を使用しており、送受信されるペイロードの機密性については心配していません。

ただし、私が取り組んでいる iPhone アプリケーションは、私が構築した REST API と通信しています (アプリケーションとサーバーを制御しているため、提案は大歓迎です)。

認証に OAuth2 プロトコルを使用しています。つまり、「API キー」は、クライアント ID とクライアント シークレットの組み合わせであり、access_token. その後、すべてのリクエストはaccess_token、リクエスト本文の HMAC を含むヘッダー (クライアント シークレットをキーとして使用) を使用してサーバーに送信されます。この追加の唯一の理由は、誰かが JUST で API リクエストを作成できないようにするためでしたaccess_token。

私が話している API は、アプリケーションをリリースするときに公開される予定です。したがって、他の人が API 呼び出しを行うことができることを必ずしも心配しているわけではありません。

私が気にしているのは：

  • アプリケーションのクライアント資格情報を使用して API 呼び出しを行うことができる人々 (つまり、アプリケーションからのものではないことをサーバー側で検出できないことを意味します)
  • 私のクライアント ID が許可する追加のスコープを悪用することができ、従来の API ユーザーにはありません。

私の推測では、この問題に対する解決策は実際にはありません (UIWebView を使用し、美化された webapp を作成する以外に) と思いますが、とにかくここで尋ねてみようと思いました。

アプリで使用する必要がある場合、クライアント ID/クライアント シークレットを保護する方法を考えられますか?

4

1 に答える 1

7

これがあなたが望んでいた答えではないことは承知していますが、残念ながら、絶対的な確信を持って目的を達成できるとは思いません。結局のところ、コントロールできないクライアントを信頼することはできません。

2 つの目的を達成するには、API にアクセスするクライアントが作成されたものであることを確認する必要があります。これを行う方法は、公開鍵と秘密鍵のペアを使用することです。何かに署名するために使用できる秘密鍵をクライアントに埋め込む必要があります。このようにして、サーバーは、リクエストが他の誰かのものではなく、あなたのクライアントからのものであることを認識します。これにより、特定の呼び出しをクライアントのみに制限することもできます.

ただし、知識のあるユーザーがリバース エンジニアリングを行ってアプリから秘密キーを抽出し、それを使用してソースを偽装する可能性があるため、これは防弾ではありません。防弾ではありませんが、それを行うには多くの作業が必要であり、非常に技術的であるため、特にバッファースミアリング、マスレッドニシンなどの反RE技術を使用する場合は防弾です.

もし私があなただったら、誰かがそれをハッキングした場合、どのような損害が生じるかを自問するでしょう. あなたがFacebookなら、それは壊滅的です。内部組織にサービスを提供している場合、それは大したことではないかもしれません。乱用を 1 回も行う余裕がない場合は、設計を再検討する必要があります。これはうまくいかないからです。自分が制御していないコードを信頼することはできません。また、クライアントが他人のデバイス上にあると、クライアントを制御できなくなります。

于 2013-03-07T17:18:09.720 に答える