誰かが私のWebサービス用に自分自身のクライアントアプリを作成するのを防ぐ方法はありますか?

フロントエンドにRESTful Webサービスとそれと対話するために使用される市販のAndroidアプリがあるとします。エンドポイントが見えないようにSSLを使用することもできますが、それでも見つけるためにリバースエンジニアリングを行うことができます。

代わりにSOAPを使用することもできます。そのため、Webサービスへの呼び出しはもう少し複雑になります。しかし、これがRESTfulベースのサービスよりも優れているかどうかはまだわかりません。

私は自分のクライアントアプリにキーをハードコーディングして、自分のクライアントアプリだけがサービスを利用できるようにすることを考えていた。また、多少のコード​​の難読化も役に立つかもしれません。しかし、これは実際にどれほど役立つのでしょうか。

UPDATE: As JOW pointed out Fiddler

httpsを復号化して完全な要求を見るために使用される可能性があります。ただし、Androidアプリのみを使用している場合は、Androidクライアントアプリでサーバー証明書をハードコーディングすることで解決できる場合があります。また、SOAP WS-Securityもありますが、それを回避するための手間のかからない方法でツールを機能させることができます。

30
ハードコーディングされたサーバー証明書を置き換えるためにあなたのapkを解凍することは非常に簡単です。許可されていないクライアントアプリケーションを防ごうとするのは時間の浪費です、常に認証をAPIに置いてください。
追加された 著者 Jay Corbett,
@jasonszhaoもちろん、重要なのはあなたのクライアントが故意に動揺しているということではありません。例えば、公式クライアントは、地図上にエンティティの半分だけを表示するか、壁によって隠されているエンティティを表示しないか、または他のエンティティへの軌跡を手動で識別して計算することをユーザに要求します。
追加された 著者 Haakon,
あらゆる種類のAPIの@Jab
追加された 著者 Haakon,
私はなぜあなたがこれをしたいのか尋ねることができますか?一般的なケースでは不可能ですが、基本的な目標を達成できるような取り決めがあるかもしれません。例えばあなたが人々にApp Storeで0.99ドルを使わせることを強制したいならば、単にいくつかの単純な難読化を持つことはおそらく十分でしょう。
追加された 著者 FryAmTheEggman,
あなたはそれを試した人なら誰でも弁護士になることができますが、それはあなたのユーザーをいらいらさせ、市場シェアを失うためのレシピです。 ICQに聞いてください。
追加された 著者 Michael Hampton,
@AronなぜRESTful APIを使ってゲームを運営するのですか?
追加された 著者 JAB,
アプリだけを使用すること、またはWebサービスにアカウントを持っていることを知っているユーザーだけがどのアプリからでもそれを使用できることが重要ですか。何人かの人々が後者を念頭に置いて答えを出したので、私はそれがあなたが何を意味したのかわからないからです。どうか明らかにしてください。自分の広告だけを表示して公式のユーザーエクスペリエンスを提供したいだけで、他の誰かが自分の広告や一部の悪いUXでアプリを作成させたくないため、OPは自分のWebサービスを自分のアプリのみに制限したいかもしれません。
追加された 著者 user29563,
これがSnapchatが必死に解決しようとしている問題です…それでも「スナップアップロード」を素早く検索すると、複数のサードパーティクライアントが生まれます。唯一の解決策は、第三者が自分たちで作るための正当な理由を与えないために、そもそも不正なクライアントを作らないことです。
追加された 著者 André Borie,
Tinderは何年もの間この正確なことをやろうとしてきました、そして、彼らは失敗しました。
追加された 著者 HEidi,
回答を削除しました。人々は私が問題を解決するのではなく文字通りの質問に答えることを望んだので、それはマークダウンされました。つまり、クライアントではなくユーザーを認証します。
追加された 著者 Tim,
クライアント側の何かは信頼できません。あなたはそれを困難にすることができるのはあなたのクライアントサイドコードとコミュニケーションを難読化することによってだけです。しかし、リソースを持っている決心した人はあなたのクライアントをエミュレートすることができます。
追加された 著者 gmaclachlan,
クライアントアプリをそれほどうまく作らないことで、他に何も使いたくないでしょうか。
追加された 著者 QuirkyScientist,

8 答え

これは不可能でしょう。 APIを使用するために必要なすべての命令をアプリに含めることが基本です。十分なスキルと時間があれば、だれでもこれらの秘密を抽出して自分のクライアントを作成することができます。

40
追加された
@Timアプリがストアで利用可能でサービスと通信できる場合、人々はアプリをダウンロードし、そのネットワークトラフィックを観察し、自分のクライアントで行うこと(認証など)を真似ることができます。ジャスティンはそれをかなり正しいとしています。
追加された 著者 Tristan,
Googleがサービスを提供した場合、Googleアカウントを使用して、サーバーがGoogleに確認できるトークンをサーバーに提供することはアプリではできませんか。
追加された 著者 user63551,
私はこれが尋ねられた質問に対する正しい答えだと思います。私は尋ねた質問が全く正しい質問だとは思わない。通常、アクセス方法ではなく、情報へのアクセスを制限します。
追加された 著者 Tim,
これは間違いです。私の答えを見てください。
追加された 著者 Tim,

既存のクライアントがPlayストアの全員に利用可能である限り、RESTまたはSOAPが使用されているかどうかにかかわらず、自分自身のクライアントを作成することは非常に簡単で簡単です。 Fiddler を使用してAndroidデバイスからのHTTPトラフィックをキャプチャするだけで、あなたのエンジニアを設計できます。キャプチャされたトラフィックに基づく独自のクライアント。

HTTPSトラフィックでも Fiddlerを使用して簡単に復号化できます。 HTTPメソッド、URL、ヘッダ、クッキー、ボディ、そしてあなたのキーはすべて表示されます。これが安全だとは思わない。 (Fiddlerと同じことができる他のリバースプロキシがあります。)

24
追加された
@AnaMandicたくさんのやり方があります。フィドラーといっそう劣らず。私たちが自分自身をいじる者に制限しないのであれば、もっと選択肢があります。私はAndroid携帯電話をハブ/転送スイッチ/ルーターに置くことができました。私はAndroidをVMに置くことができました。クリアテキストを送信するためにJVM httpsモジュールを置き換えることができます。など
追加された 著者 Haakon,
しかし、WebアプリではなくAndroidアプリがあれば、Fiddlerはトラフィックを傍受できますか?私はFiddler for Androidのようなアプリを見つけられませんでした、そして私のローカルネットワークのプロキシとしてPC上でそれを設定することがうまくいくかどうかはわかりません。また、私は私のAndroidアプリでサーバー証明書をハードコードすることができました。そして、SOAP WS-Securityはどうでしょうか。
追加された 著者 Nikita Prokopov,
はい、できます。私の最初のリンクをチェックしてください。
追加された 著者 BetterLateThanNever,

セキュリティの観点から、いいえ、これを実行する方法はありません。コードやプロトコルをどの程度難読化しても、実際には、APIにアクセスするためのコードと、APIにアクセスしたときに生成されるネットワークトラフィックがユーザーの手に渡るため、あらゆるリバースエンジニアリングツールを使用できます。彼らはそれを望んでいます。

ビジネスの観点からすると、それを防ぐための対策を実施するための追加コストとは対照的に、誰かが代替クライアントを作成した場合のコストを評価する必要があります。たとえば、難読化された独自のAPI(REST、SOAP、およびその他の標準化されたプロトコルを使用しない)を完全に使用することはできますが、実装するのが難しくなり、そのためコストがかかります。一方、誰かがリバースエンジニアリングすることはかなり困難になります。そのような対策(または他の適切な対策)があなたのビジネスにとって価値があるかどうかを判断する必要があります。

法的な観点から見ると、多くの場所にはサードパーティクライアントの生産または使用を禁止する利用規約があります。サードパーティクライアントを使用している可能性があるかどうかを判断するためにサーバーへのトラフィックを監視することによって、またはアプリストアでサードパーティクライアントの外観を監視することによってそれを強制するのはあなた次第です。法的措置を取るためのリソースがあるかどうか、またそのような措置を取る価値があるかどうかは、あなた次第です。

ユーザー関係の観点からは、すべてのサードパーティクライアントを包括的なルールとして禁止するという考えを再検討することをお勧めします。明らかに、開発者が自分自身の広告で恐ろしいクライアントを作成することを望んでいる人はいませんが、最近の多くのサービスではサードパーティの開発者が自分のアプリケーションを登録してAPIキーを受け取ることができます。登録のプロセスは、単純な使用条件(例:「アプリに広告を掲載しない」など)から、それらのインターフェースの評価、またはそれらの情報源の詳細な検査まで、必要に応じて簡単または複雑にすることができます。コード(もちろん、それが単純であればあるほど、開発者はより積極的にサインアップするでしょう)。サードパーティの開発者があなたのAPIを使用することを許可することは必ずしも悪いことではありません - 彼らはあなたのサービスをデータソースとして使用するが、いかなる方法でもそれに関連しないアプリを作りたいかもしれません。彼らは彼らのアプリに適切な認定を入れれば実際にあなたにもっとビジネスをもたらすでしょう、あるいは彼らはあなたのビジネスが入る意図がない市場を埋めたいと思うかもしれません、あるいは彼らは本当にあなたのサービスのクライアントアプリケーションのためにより良い考えを持ちますあなた自身のアプリを改良するためにあなたが学ぶことができる何か。

17
追加された

不要な使用を防ぐ理由は、何らかの形でユーザー認証を実行することだけです。アプリを起動するたびにアプリのユーザーにユーザー名とパスワードの入力を要求し、これをサーバーに渡すなど。サーバーがユーザーを検証すると、それ以降のすべてのAPI呼び出しで使用する必要があるセッショントークンが返されます。ただし、アプリケーションがユーザーのログインには適していない可能性があります。

ログインしなくても、あなたのAPIにアクセスできる誰かがあなたのコードをリバースエンジニアリングしたりデータをスヌープしたりしてやりとりすることができるので、いつでも可能になります。したがって、あなたの目的は、誰かがあなたのコードとAPIをリバースエンジニアリングすることを可能な限り困難にすることです。クライアントからサーバーに固定値を指定しないでください。それは簡単に見つけて、それから代替クライアントで使用することです。

代わりに、サーバーにログインするたびに新しいコードを生成して、トラフィックを詮索するたびに異なる値が表示され、単純にその値を再生できないようにします。これにより、キーの生成に使用されたアルゴリズムを発見するためにコードをリバースエンジニアリングすることを強制されます。そのコードを理解しにくくして複製するようにするためにいくらかの努力を払う。

6
追加された
これは解決策ではありません。誰もが元のアプリのユーザー名とパスワードを持っている場合、彼らは簡単に自分のクライアントアプリを作るためにそれらを使うことができます - それはまさにOPが避けようとしているものです。
追加された 著者 MiaoHatola,

はい、これは可能ですが、もちろん完璧な解決策はありません。

クライアントとサーバーの両方に暗号化とメッセージ認証を追加する必要があります。どちらも共有秘密に基づいて、おそらく一意のクライアントIDを追加してセッションキーをネゴシエートします。その方法についてはたくさんのドキュメントがあります(キーワード:セッションキー、キー交換、APIキー)。このシステムの鍵は、通信が暗号化され、実際の鍵(別名共有秘密)ではなくセッション鍵で署名されることです。このようにして、本当の鍵が電信号を通過することはなく、傍受されることもありません。

攻撃者は、クライアントをリバースエンジニアリングして共有秘密とそれからセッションキーを導出するメカニズムを抽出する可能性があります。しかし、これにはより高度なスキルが必要です。それから単にRESTに関するおしゃべりを聞いてください。

5
追加された
「攻撃者が共有秘密を抽出するためにクライアントをリバースエンジニアリングする可能性があります」=「いいえ、できません」、「はい、できます」。
追加された 著者 Gnubie,
@Tom、私はまともなJava開発者であり、それはAndroidアプリケーションを開発するために必要とされるコア知識です。そして与えられたTools(GoogleのAndroid Studio/IntelliJ)を使えば、Appを取り込んでそれを私のIDEに入れ、平文で行おうとするすべての行を読むことが楽しくなる。
追加された 著者 Serverfrog,
@Tomしかし質問がある場合:私はAndroidアプリをリリースした場合、誰かが私のWebインターフェイスに要求することができます答えはイエスです。質問が「だれかがリクエストを送信するのを難しくすることはできますか」という質問であれば、あなたの答えは正しいでしょう。そしてProGuardなどは、リクエストに使用されているURLを隠さないということです。つまり、実行中のBulldozerがドアの前に立ちます。誰かがあなたの地上にいて、彼が侵入したいのなら、彼はそれをとても簡単にすることができます。
追加された 著者 Serverfrog,
@誰かがしたい場合は、彼ができます。あいまいさによるすべてのセキュリティです。多かれ少なかれ何もない
追加された 著者 Serverfrog,
重複した質問に対するトップ投票の答えは、私が言っていることを言っていることに気付いただけです。だから私はここにいます。 facepalm
追加された 著者 Tom,
@Serverfrogですので、Androidアプリのリバースエンジニアリングをより困難にするためにProGuardやその他のテクニックを紹介する必要はありません。 JS minifyに相当するJavaと同じくらい単純なものが、スキルを欠いているか時間を費やしたくない人々の大多数を投げ出しています。
追加された 著者 Tom,
@Serverfrogそれは、「あなたの家の正面玄関に鍵をかけないでください。ブルドーザーが発明されたので、誰かが本当に望んでいれば、彼らはそうするでしょう」セキュリティはそれほどバイナリではありません。そしてそのロックをかけることをお勧めします。
追加された 著者 Tom,
右。私が主張していることを説明できないようです。リクエストを保護することを重視するすべてのアプリは、まさにこのようにしています。私は最初の回答でグーグルのキーワードを挙げた、あなた自身の調査をしなさい、みんな。
追加された 著者 Tom,
@StigHemmer - 知識は魔法のように広がることはありません。誰かがアプリのリバースエンジニアリングに成功したとしても、自分のクライアントを作成しようとしている人がその情報を見つけることは保証されていません。ひびの入ったソフトウェア以外では、この種のデータはよく知られているtorrentサイトにはありません。それはほとんどの人が自分自身のクライアントを実装するのを阻止し、最も熱心な攻撃者を阻止することはありませんが、NSAやChinese Mafiaに反対している場合は、stackexchangeよりもセキュリティに関するアドバイスが必要です。 :-)
追加された 著者 Tom,
@ OlegV.Volkov - 私は「はい」で立ちます。あなたは秘密を抽出するプロセスをかなり複雑にすることができます。間違いなく、ほとんどの攻撃者を阻止するのに十分なほどです。もちろんそれはあなたの脅威モデルによります。しかし、与えられた情報から、質問者が政府機関に反対しているようには見えません。これは、ほとんどの脅威に対する適切な保護を提供する妥当な努力を伴う、堅実で一般的に使用されているアプローチです。
追加された 著者 Tom,
リバースエンジニアリングにはより高いスキルが必要ですが、必要なスキルを持つ人はたくさんいます。また、1人のユーザーがこの仕事をすれば、知識を他の人に広めることができます。
追加された 著者 Mahesha999,

セキュリティ上、APIへの不正アクセスを不可能にすることはできませんが、最小限に抑えることができます。これはセキュリティ上の問題ではありませんが、脅威モデルの概念は非常に適しています。自分のAPIにアクセスできないようにしたい人は誰ですか?また、どのような損害を避けたいですか?

多くの大規模Webサイトでは、サービスへの代替アクセス手段を禁止しているため、通常は広告を配信し続けることができます。彼らは多くのレベルでの対策の組み合わせを通してそうします:

  • リクエストヘッダーとユーザーエージェントをチェックする(これは普通の普通のユーザーを大量に阻止する)
  • 動的な状態、難読化、その他の手段を追加することによってAPIを複雑にします(これは不用意なリバースエンジニアリングを阻止しますが、決定的なものではありません)。
  • 利用規約でそれを禁止する(他の合法的な事業や少数の良心的な人を阻止する)
  • 弁護士によるToSの執行(これは非倫理的な事業には必要かもしれませんが、小規模な個人ユーザーに対して展開すると善よりも害が大きくなります)

これらのどれも100%効果的ではありませんが、それらはする必要はありません。重要なことは彼らが損失を減らすことです。達成したいことを考え、それに応じて対策を選択してください。

4
追加された

あなたはしたい :

他人が自分のWebサービス用に自分自身のクライアントアプリを作成するのを防ぐ

あなたはあなたのWebサービスがそれ以上の対話の前にユーザデバイス上のあなたのアプリを識別したいのですが、リバースエンジニアリングによって変更される可能性のあるアプリの完全性については保証がないのでこれは不可能に思えます。

ソリューションのアーキテクチャーを検討することを検討してください。

3
追加された

フロントエンドにRESTful Webサービスとそれと対話するために使用される市販のAndroidアプリがあるとします。エンドポイントが見えないようにSSLを使用することもできますが、それらを見つけるためにリバースエンジニアリングを行うことができます。

SSLはターゲットIPアドレスを隠蔽しないため、リバースエンジニアリングを行う必要さえありません。それ以外のものはすべてFiddler + MITM証明書によって入手できます。

代わりにSOAPを使うこともできるので、Webサービスへの呼び出しはもう少し複雑になります。しかし、これがRESTfulベースのサービスに勝るかどうかはまだわかりません。

まあ、もっと努力すればするほど、ハッカーがもっと努力しなければならなくなるでしょう、と私は思います。

そうは言っても、ハッカーはあなたよりもずっと自由な時間があります、そしてそれらの多くがあります、そしてそれらのうちの1人だけが掲示板に解決策を掲示する必要があり、それはゲームオーバーです。

だから、おそらく努力の価値はありません。

私は自分のクライアントアプリにキーをハードコーディングして、自分のクライアントアプリだけがサービスを利用できるようにすることを考えていました。また、多少のコード​​の難読化も役に立つかもしれません。しかし、これはどれほど役立つのでしょうか。

ハッカーは今すぐ解読ツールを持っています。 。

おそらく努力する価値はありません。

Fiddlerを使ってhttpsを復号化し、完全なリクエストを見ることができます。ただし、Androidアプリのみを使用している場合は、Androidクライアントアプリでサーバー証明書をハードコーディングすることで解決できる場合があります。また、SOAP WS-Securityもありますが、それを回避するための手間が省けるようにツールを機能させることができます。

ハッカーは、あなたがそれを構築することができるよりもはるかに速くリバースエンジニアリングをすることができます。

だから、おそらく努力の価値はありません。

ハッカーがクライアント上で動作するコードをリバースエンジニアリングするのを阻止することはできません。だから、どんな防護策を講じても、ハッカーはそれらを真似することができます。

その通りです。これに時間をかけないでください。

代わりに、機密性の高い機能がサーバー上で実行されるようにアプリケーションを設計してください。

顧客が他に何も望んでいないようにあなたのアプリの機能を改善する残りの時間を過ごしてください。

0
追加された