13

ここに課題があります：

サービス/ビジネス層には REST (JSON) インターフェースがあります。API を呼び出すことができるクライアントには 2 種類あります。ブラウザで実行される Web アプリケーションと、モバイル アプリケーション (Android) です。どちらも公開です。承認された (!) webapp または承認された (!) mobile-app を使用するすべての人が、リソースにアクセスできる必要があります。許可されていないクライアント (スクリプトなど) はすべて禁止する必要があります。

注: サービス層にアクセスできるユーザーの数やユーザー数に制限はありません -> クライアントの公開鍵証明書はおそらく使用できません。クライアント ソフトウェアのみを認証する必要があります。

私の意見では、唯一の解決策は「あいまいさによる」です。

アイデア:

  • ブラウザ（またはアプリ）で実行されるサーバーからランダムなJS関数（「チャレンジ」と呼びましょう）をロードし、特定の方法（ブラウザの欠陥？）でブラウザをフィンガープリントし、結果を計算して結果を送信しますすべての REST-API 呼び出しで戻ります。

さらにアイデアや提案はありますか？

よろしくお願いします。下手な英語で申し訳ありません

編集：

私の質問は、ユーザー認証および/または承認とは関係ありませんが、クライアントソフトウェア認証+承認とは関係ありません。

私の質問の背景は、私自身のアプリケーション (Android + Web) 用の RESTful バックエンドがあり、その上に誰かが独自のクライアント ソフトウェアを作成したくないということです。その理由は、収集するのに非常に費用がかかるデータを提供する商用 Web サイト/アプリケーションであるためです。RESTapi (またはサードパーティの競合他社) ではなく、Web サイトとモバイルアプリを宣伝したいと考えています。

4

2 に答える 2

12

残念ながら、私の回答は、クライアントアプリケーションを決して信頼してはならないというものです。

配布したクライアントとの信頼関係を構築するにはさまざまな方法がありますが、それらはすべてハッキング、クラック、またはバイパスされる可能性があります。サーバーの外部からのデータは絶対に信用しないでください。これまで。クライアントまたは主要なWebブラウザからの接続に依存しないでください。十分な時間と労力ですべてを偽装することができます。

業界でのこのような問題のいくつかの良い例は、ゲームのようなものから簡単に見られます。メモリハックやその他のアプローチをチェックするルーチンがあっても、World of Warcraftのような莫大な予算のサービスでさえ、クライアントのハッキングが発生するか、コマンドを送信できる完全なクライアントエミュレータは、通常のクライアントでは送信できません。安全を維持し、サーバーに適切なデータのみを送信するためにクライアントソフトウェアに依存することは、災害のレシピです。重要なものである場合は、常にサーバー側を検証してください。データを常に適切にエスケープ/パラメータ化します。ホワイトリストモデルを使用し、必要に応じてユーザーデータ自体ではなく、ユーザー入力に基づくシンボルテーブルルックアップを使用することをお勧めします。などクライアント側の検証は、安全なものとしてではなく、ユーザーを支援するものとしてのみ見なされるべきです。

単に「十分に良い」ことを目指している場合は、提案したような隠すことによるセキュリティなど、これが発生する可能性を減らすのに役立ついくつかのオプションがありますが、それでも発生しないことに依存しないでください。

1つの解決策は、基本的にクライアントの主要な機能をクライアント内に含めず、代わりに実行時にサーバー（javascript / etc）から送信し、ロジックパッケージをクライアントに送信するたびに異なるフィンガープリントを使用することです。ランダムに選択された、さまざまなロジックルーチン。次に、パッケージをタイムアウトし、どのユーザーがどのパッケージにアクセスしたかを追跡し、セキュリティの維持に役立つテレメトリをパッケージに返すことができます。返されたロジックと指紋とともに送信されたロジックの不一致は、すぐになりすましまたはハッキングの試みであると見なすことができます。ただし、最終的には、これらすべてを打ち負かすことができます（このような比較的初歩的な例は、特にランタイムメモリのセキュリティがない場合は、決定された誰かによってかなり簡単に打ち負かされる可能性があります）。

中間者（MITM）攻撃に対処する方法はいくつかあります。この攻撃では、誰かがデータを傍受しようとしますが、侵害されたエンドポイントを完全に説明することはできません。

于 2012-12-27T18:20:01.697 に答える
5

Webサーバーは通常、「セッション」の概念をサポートします。Webブラウザーが接続すると、サーバー上にセッションが作成され、セッションIDが（通常はHTTP cookieとして）返されます。次に、Webブラウザーは、そのセッションIDCookieをサーバーへの後続のすべての要求に送信します。

このメカニズムを使用して、多くのプログラミング言語/フレームワークには認証/承認モジュールがあり、ユーザーは（通常はユーザー名とパスワードを使用して）自分自身を認証できます。ユーザーのIDが検証されると、セッションはユーザーのIDで更新されます）。次に、サーバーコードは、各リクエストのセッションからユーザーIDをチェックして、ユーザーが認証されているか、リクエストの発行が許可されていることを確認します（HTMLページビューまたはAPI GET / POSTのいずれか）。

Android（またはiOS ...）アプリでは状況が少し異なる場合がありますが、考え方は似ています。ユーザーに一度認証してもらい、サーバーにユーザーレコードでマッピングされる「シークレットトークン」をクライアントに提供します。次に、このトークンは、クライアントによって送信されたすべての要求に対して渡されます。

そのために自家製のライブラリを使用することも、OAuth2のようなより標準的なライブラリを使用することもできます。

于 2012-12-27T17:44:17.160 に答える