17

Suppose you have a mobile application (Windows Phone or Android) that connects yo your back-end using SOAP.

For making it easy, let's say that we have a Web Service implemented in C#. The server exposes the following method:

[WebMethod]
public string SayHallo() { return "Hallo Client"; }

From the server perspective, you can't tell if the caller is your mobile application or a developer trying to debug your web service or a hacker trying to reverse engineer/exploit your back-end.

How can one identify that the origin of the web service call is THE application? as anyone with the WSDL can invoke the WS.

I know I can implement some standard security measures to the web service like:

  • Implement HTTPS on the server so messages travel encrypted and the danger of eavesdropping is reduced.
  • Sign the requests on the client-side using a digest/hashing algorithm, validate the signature in the server and reject the messages that have not been signed correctly.
  • Write custom headers in the HTTP request. Anyways headers can be simulated.

However, any well experienced hacker or a developer who knows the signing algorithm, could still generate a well signed, well, formatted message. Or a really good hacker could disassemble the application and get access to the hidden know-how of my "top secret" communications protocol.

Any ideas how to make the SayHallo() method to answer ONLY to request made from my mobile application?

We are running in the context of a mobile application, with hardware access, there could be something that can be done exploiting the hardware capabilities.

If someone wonders, I'm thinking on how to make a mobile app secure enough for sensitive applications like banking, for example.

Thanks for your ideas.

4

6 に答える 6

10

あなたが説明しているのは双方向認証です。これは、通信の両側に署名された公開鍵（証明書）を保存することによってのみ実行できます。つまり、各アプリはサーバーの公開鍵を使用してサーバーを認証する必要があり、サーバーはアプリの各インスタンスを認証する必要があります。アプリの公開鍵は、アプリの各インスタンスでデプロイ時に作成され、サーバーに保存される必要があります。これを双方向HTTPSと考えてください。一般に、実行する必要がある唯一の認証は一方向であり、ブラウザは信頼できる署名キーを使用してサーバーを認証します。あなたの場合、これは両側で行う必要があります。通常、VeriSignのようなサービスは、公開鍵の各インスタンスに署名します。これは、アプリの複数の展開でかなりの費用がかかる可能性があります。あなたの場合、OPENSSLのようなものを使用して社内署名アプリケーションを作成し、配布されるたびにアプリに署名することができます。これは、誰かがまだあなたのコードをハッキングしてアプリ側で署名キーを抽出できなかったことを意味するものではありません。一般に、どのコードもハッキングされる可能性があります。それは、あきらめる前にどれだけ難しいコードを作成できるかという問題です。カスタムハードウェアルートを使用する場合、暗号チップやTMPなどのキーソースとして機能し、デバイス上の秘密キーへのアクセスを困難にする可能性があります。s彼らが諦める前にあなたがそれをどれだけ難しくすることができるかという質問だけですか？カスタムハードウェアルートを使用する場合、暗号チップやTMPなどのキーソースとして機能し、デバイス上の秘密キーへのアクセスを困難にする可能性があります。s彼らが諦める前にあなたはそれをどれだけ難しくすることができるかという質問だけですか？カスタムハードウェアルートを使用する場合、暗号チップやTMPなどのキーソースとして機能し、デバイス上の秘密キーへのアクセスを困難にする可能性があります。

クイックグーグル検索は次のようになりました：

http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

リワードポイントの使用を考えていて、誰かがシステムを外部からゲームしていることを本当に心配している場合、より良い解決策は、サーバーに安全に保存されているアカウントを各人に作成させ、ポイントを保存してそこに集計することです。これにより、すべてのデータが一元化され、悪意のあるアプリが存在しないポイントを報告することを心配することなく、データを完全に制御できます。（これが銀行の仕組みです）

于 2012-12-24T16:24:56.630 に答える
6

ユーザーがモバイル であることと、そのユーザーが 誰であるかを確認したい場合は、ネットワークを活用するのが最善の方法です。ユーザーに使用させたいハッシュ化されたキーを含むプッシュ通知を次の方法で送信します。

于 2013-01-02T23:23:30.213 に答える
2

次の方法を使用して、サーバーへのリクエストを保護および追跡できます。

  1. Custom Headersを介してWebサービスにアクセスするときに、モバイルクライアントまたはWebクライアントにデバイスタイプのを送信するように強制できます。REST methods

  2. 承認されたWebサービスプロバイダーとして提供された独自のユーザー名とパスワードを各クライアントに強制することにより、基本的なhttp認証を使用します。

  3. より高度な保護が必要な場合は、WebサービスOAuth 2.0を保護するために使用できます。

于 2013-01-02T18:00:39.963 に答える
2

すでに与えられた答えに加えて、電話の一意のIDとパスワードを使用したログインタイプスキームを使用するのはどうですか？ユーザーに「バックエンド」に登録してもらい、バックエンドでトランザクションを実行する必要があるたびに、パスワードを要求するか、自動的にログインするオプションを用意します。

于 2012-12-30T03:43:36.773 に答える
2

一般に、モデルは次のようになります。

  • サーバーは、認証された公開鍵を使用して多くのクライアントに対して自身を認証します (これは、公開鍵インフラストラクチャ、認証局など全体です)
  • 各クライアントは、他の認証システムを介してサーバーに対して自身を識別します (99.9% の場合、これはパスワードです)。

したがって、銀行アプリなどの場合にこの種のことがどのように機能するのか疑問に思っている場合、それは基本的にどのように分解されるかです: (1) クライアントとサーバーは、サーバーの公開鍵を使用して、共有秘密鍵などの安全なチャネルを確立します。 (2) クライアントは、他のメカニズムを使用して、この安全なチャネルを介して認証します。

ただし、具体的には、アプリのみが認証され、アプリが適切に動作している場合、すべてが安全であるという考えで、アプリ自体を認証すること (つまり、アプリからの要求はすべて本物) を対象としているようです。 . これにはいくつかの意味があります。

  • これは、アプリのすべてのユーザーが信頼されていることを意味します。セキュリティの観点から言えば、それらは「信頼できるコンピューティング ベース」の一部です。
  • ユーザー/ユーザーのコンピューティング プラットフォームを信頼できるものと見なさずに、この種の目標を達成しようとすることが、本質的にDRMの目標です。音楽出版社にとってはお金を節約するのに十分ですが、本当にデリケートなものにとっては十分とは言えません。

一般に：

  • 非常に強力なセキュリティ プロパティを探している場合、具体的に見ている問題を解決するのは非常に困難です。
  • おそらく、その問題を解決する必要はありません。
  • もう少し背景を教えていただければ、より具体的なアドバイスができるかもしれません。
于 2012-12-24T16:49:59.267 に答える
1

元のアプリは Android アプリまたは Windows Phone アプリになるため、ハッカーになりたい人にとってはどちらも比較的簡単にデバッグできます。いずれにせよ、制御できないマシンでコードを実行することになるため、ssl トリックや署名のチェックを行っても根本的な問題は解決されません。

その脅威と戦う唯一の方法は、クライアントを信頼しないことです。ゲームを作成している場合は、クライアントからの入力が有効であることを確認してから、有効なセキュリティトークンなどを伴っていることを確認してください。

本質的に、ユーザーが非公式のクライアントを使用しているかどうかが問題にならないようにサービスを構築します。

于 2013-01-03T09:44:24.407 に答える