1

私は asp.net mvc-4 Web アプリケーションに取り組んでおり、サイトに関する統計情報を提供する Web サービスの実装を開始しました。しかし、承認および認証されたコンシューマーのみが Web サービスを呼び出して使用できるようにするために、コンシューマーごとにマスター ログイン ユーザー名とパスワードを定義することを考えています。コンシューマーが Web サービス リクエストを送信するときは、これらのマスター ログイン ユーザー名とパスワードを含める必要があります。 (ハッシュ値として格納されます) Web サービス呼び出しで。

たとえば、私の Web サイトから特定の Web サービスを呼び出すための Web サービス リンクは次のようになります。

/web/json/statistic/getsummaryinfo/areacode?j_username=masterusername&hash=D012B772672A55A0B561EAA53CA7734E

私の質問は、私が従っているアプローチが私の Web サービスと消費者に安全なソリューションを提供するかどうかということです。または、私のアプローチには、私が気付いていないセキュリティホールがありますか?

:::編集::

WebAPI コントローラーを使用して、asp.net mvc-4.** 内に Web サービスを実装しています。

よろしくお願いします

4

2 に答える 2

3

物事が安全であることを確認する方法はいくつかあります。

  1. http://techcrunch.com/2012/11/08/soa-softwares-api-management-platform-and-how-it-compares-to-its-sexy-counterparts/この記事は今日公開されたばかりで、いくつかの API ツールを強調しています。 . あなたがどのくらいの規模であるか、またはどの程度になる予定かはわかりませんが、スケールを探しているなら、これらのツールはかなり人気があるようです (注: 私自身は大規模な API プロジェクトを持っていないので、これらを使用しました）。
  2. ServiceStack などを使用して API レイヤーを構築できます。認証プロバイダーのボートロードを使用して、承認と認証が組み込まれています。拡張性が高く、認証の呼び出し後はセッションベースであるため、呼び出しごとに認証する必要はありません。
  3. 「署名付き」リクエストを使用できます。署名されたリクエストは、多くの場合、次のようになります。秘密鍵!!)をリクエストに送信します。」リクエストがクライアント側 (AJAX) で行われた場合でも、秘密鍵を使用してサーバー側で生成されるため、これは安全な方法です。したがって、改ざんされていないことを確認できます。
  4. oauth/token ルートに進むことができます (多くの場合、上記の方法 #3 を使用します)。
  5. 取り消すことができる単純な API キーを使用できます (ここでも、方法 3 で使用される fotne です)。bit.ly はこの方法を使用していると思います。

オプション＃2は私のお気に入りです。ServiceStack が好きです。しかし、正直なところ、最初のプロジェクトの学習曲線は少し急勾配になる可能性があります。

マスターユーザー名とハッシュ化されたパスワードは私には弱いと感じているので、少なくとも他の人がどのようにそれを行っているかを見て回ることを強く検討したいと思います.

HTH

于 2012-11-08T19:34:39.797 に答える
0

私はあなたの道が安全であるとは考えていません。有線でリッスンしてリクエストをキャッシュできれば、サービスへのログインとパスワードを取得できます。パスワードがハッシュ化されているかどうかは問題ではありません。Eli Gassertの答えのポイント3.が好きです。非常に便利で軽量に聞こえますが、パスワードはリクエストの「どこか」でハッシュされているため、パスワードを公開していません。

于 2012-11-08T20:28:10.913 に答える