836

REST APIまたはサービスを設計するとき、セキュリティ（認証、承認、ID管理）を処理するための確立されたベストプラクティスはありますか？

SOAP APIを構築するときは、ガイドとしてWS-Securityがあり、このトピックに関する多くの文献があります。RESTエンドポイントの保護に関する情報が少なくなっています。

RESTには意図的にWS-*に類似した仕様がないことは理解していますが、ベストプラクティスまたは推奨されるパターンが出現したことを期待しています。

議論や関連文書へのリンクをいただければ幸いです。重要な場合は、.NETFrameworkのv3.5を使用して構築されたRESTAPI/サービスのPOX/JSONシリアル化メッセージでWCFを使用します。

4

18 に答える 18

302

tweakt が言ったように、Amazon S3 は使用するのに適したモデルです。彼らのリクエスト署名には、偶発的および悪意のあるリクエストのリプレイを防ぐのに役立ついくつかの機能 (タイムスタンプの組み込みなど) があります。

HTTP Basic の優れた点は、事実上すべての HTTP ライブラリが HTTP Basic をサポートしていることです。もちろん、この場合は SSL を要求する必要があります。なぜなら、ネット経由で平文のパスワードを送信することは、ほぼ例外なく悪いことだからです。SSL を使用する場合は、Digest よりも Basic の方が適しています。これは、呼び出し元が資格情報が必要であることを既に知っている場合でも、Digest では nonce 値を交換するために追加のラウンドトリップが必要になるためです。Basic では、発信者は最初に資格情報を送信するだけです。

クライアントの ID が確立されると、承認は実際には単なる実装上の問題になります。ただし、既存の承認モデルを使用して、承認を他のコンポーネントに委任することもできます。ここでも Basic の優れた点は、サーバーが最終的にクライアントのパスワードのプレーンテキスト コピーを保持し、必要に応じてインフラストラクチャ内の別のコンポーネントに渡すことができることです。

于 2008-08-11T08:45:13.343 に答える
117

HTTP 以外に REST の標準はありません。そこには確立された REST サービスがあります。それらをのぞき見して、それらがどのように機能するかを感じることをお勧めします。

たとえば、独自のサービスを開発する際に、Amazon の S3 REST サービスから多くのアイデアを借りました。ただし、リクエスト署名に基づくより高度なセキュリティ モデルは使用しないことにしました。より単純なアプローチは、SSL 経由の HTTP 基本認証です。自分の状況で何が最適かを判断する必要があります。

また、O'reillyのRESTful Web Servicesという本を強くお勧めします。中心となる概念について説明し、いくつかのベスト プラクティスを提供します。通常、提供されているモデルを使用して、独自のアプリケーションにマップできます。

于 2008-08-11T06:07:03.680 に答える
72

OAuthも参照してください。これは、特に http API を対象とした、トークンベースの認証用の新しいオープン プロトコルです。

これは、 flickrが取ったアプローチと非常によく似ており、milk の「rest」APIを思い出してください (必ずしも安らかな API の良い例ではありませんが、トークンベースのアプローチの良い例です)。

于 2008-09-18T02:55:07.493 に答える
43

クライアント証明書を使用した SSL がまだ言及されていないことに少し驚いています。確かに、このアプローチは、証明書によって識別されるユーザーのコミュニティを当てにできる場合にのみ、本当に役立ちます。しかし、多くの政府/企業はユーザーにそれらを発行しています. ユーザーは、さらに別のユーザー名とパスワードの組み合わせを作成することを心配する必要はありません。ID はすべての接続で確立されるため、サーバーとの通信は完全にステートレスであり、ユーザー セッションは必要ありません。（言及されている他のソリューションの一部またはすべてがセッションを必要とすることを意味するものではありません）

于 2009-09-25T19:39:38.080 に答える
40

これらの回答の誰もが、真のアクセス制御/承認を見落としています。

たとえば、REST API / Web サービスが医療記録の POST / GET に関するものである場合、誰がどのような状況でデータにアクセスできるかについて、アクセス制御ポリシーを定義することができます。例えば：

  • 医師は、ケア関係にある患者の医療記録を取得できます
  • 診療時間外 (例: 9 時から 5 時) に医療データを投稿することはできません。
  • エンドユーザーは、自分が所有する医療記録、または自分が保護者である患者の医療記録を取得できます
  • 看護師は、看護師と同じ病棟に属する患者の医療記録を更新できます。

これらのきめの細かい承認を定義して実装するには、XACML (eXtensible Access Control Markup Language) と呼ばれる属性ベースのアクセス制御言語を使用する必要があります。

ここでのその他の基準は、次のとおりです。

  • OAuth: id. 承認のフェデレーションと委任 (たとえば、サービスが別のサービスで自分の代わりに機能するようにする (Facebook は自分の Twitter に投稿できます)
  • SAML: ID フェデレーション / Web SSO。SAML は、ユーザーが誰であるかについて非常に重要です。
  • WS-Security / WS-* 標準: これらは、SOAP サービス間の通信に焦点を当てています。これらはアプリケーションレベルのメッセージング形式 (SOAP) に固有のものであり、メッセージングの側面 (信頼性、セキュリティ、機密性、整合性、原子性、イベント処理など) を扱います。アクセス制御をカバーするものはなく、すべて SOAP に固有のものです。

XACML はテクノロジーに依存しません。Java アプリ、.NET、Python、Ruby... Web サービス、REST API などに適用できます。

以下は興味深いリソースです。

于 2013-09-24T22:22:33.730 に答える
25

OAuth を数回使用し、他の方法 (BASIC/DIGEST) も使用しました。OAuth を心からお勧めします。次のリンクは、OAuth の使用に関して私が見た中で最高のチュートリアルです。

http://hueniverse.com/oauth/guide/

于 2009-01-09T21:25:56.060 に答える
17

RESTに関連するセキュリティに関して私が今まで出会った中で最高の投稿の1つは、1RainDropで終わりました。MySpace APIはセキュリティにもOAuthを使用しており、RestChessコードでカスタムチャネルに完全にアクセスできます。これは私が多くの調査を行ったものです。これはMixでデモされたもので、ここに投稿があります。

于 2008-09-18T20:53:16.903 に答える
15

素晴らしいアドバイスをありがとう。RESTful API を Microsoft の今後の Zermatt Identity フレームワークと統合する準備として、カスタム HTTP ヘッダーを使用してクライアントからサービスに ID トークンを渡すことになりました。ここで問題を説明し、ここで解決策を説明しました。また、tweaktのアドバイスを受けて、RESTful Web Servicesを購入しました。これは、あらゆる種類の RESTful API を構築している場合に非常に役立つ本です。

于 2008-09-17T20:30:10.570 に答える
14

OWASP (Open Web Application Security Project) には、Web アプリケーション開発のあらゆる側面をカバーするいくつかのチート シートがあります。このプロジェクトは、非常に貴重で信頼できる情報源です。REST サービスに関しては、これを確認できます: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

于 2014-02-24T18:41:39.710 に答える
7

OAuth 2/3 をお勧めします。詳細については、http://oauth.net/2/を参照してください。

于 2013-03-14T00:59:38.470 に答える
6

私は安らかな ws セキュリティについて多くのことを検索しましたが、クライアントからサーバーへの Cookie を介してトークンを使用してリクエストを認証することにもなりました。DB に既に存在する指定されたセキュリティ ポリシーに基づいて各リクエストを認証および承認する必要があったため、サービス中のリクエストの承認にスプリング セキュリティを使用しました。

于 2012-05-15T10:36:28.137 に答える
4

REST 自体にはセキュリティ標準はありませんが、OAuth や SAML などは急速にこの分野の標準になりつつあります。ただし、認証と承認は、考慮する必要があるもののほんの一部にすぎません。Web アプリケーションに関連する既知の脆弱性の多くは、REST API に非常に当てはまります。入力の検証、セッション クラッキング、不適切なエラー メッセージ、社内の従業員の脆弱性などを考慮する必要があります。それは大きなテーマです。

于 2012-10-12T08:22:50.130 に答える
4

（stinkeymattに沿って）追加したいのですが、最も簡単な解決策は、SSL証明書をサイトに追加することです。つまり、URL が HTTPS:// であることを確認してください。それはあなたの輸送セキュリティをカバーします（お金に見合った価値があります）。RESTful url では、(WS* セキュリティ/SAML とは異なり) シンプルに保つことが考えられます。oAuth2/openID 接続または基本認証 (単純な場合) を使用できます。ただし、SSL/HTTPS は引き続き必要です。ここで ASP.NET Web API 2 セキュリティを確認してください: http://www.asp.net/web-api/overview/security (記事とビデオ)

于 2014-03-01T01:04:58.197 に答える
3

Web アプリケーション セキュリティについては、さまざまなセキュリティ攻撃のチートシートを提供するOWASP ( https://www.owasp.org/index.php/Main_Page ) を参照してください。アプリケーションを保護するために、できるだけ多くの対策を組み込むことができます。API セキュリティ (承認、認証、ID 管理) に関しては、既に述べたように複数の方法 (Basic、Digest、OAuth) があります。OAuth1.0には抜け穴があるため、OAuth1.0aを利用できます（OAuth2.0は仕様上の懸念からあまり採用されていません）

于 2014-10-06T06:05:08.970 に答える
3

@Nathanが最終的に単純なHTTPヘッダーになり、OAuth2およびクライアント側のSSL証明書と言う人もいました。その要点はこれです... APIの範囲外であるため、REST APIはセキュリティを処理する必要はありません。

代わりに、Web プロキシの背後にある HTTP ヘッダー (SiteMinder、Zermatt、さらには Apache HTTPd などの一般的なアプローチ) であるか、OAuth 2 のように複雑であるかにかかわらず、セキュリティ レイヤーをその上に配置する必要があります。

重要なことは、エンドユーザーの操作なしでリクエストが機能することです。必要なのは、REST API への接続が認証されていることを確認することだけです。userPrincipalJava EE では、 で取得できるの概念がありHttpServletRequestます。また、URL パターンを保護できるデプロイメント記述子で管理されるため、REST API コードでチェックする必要がなくなります。

WCF の世界ではServiceSecurityContext.Current、現在のセキュリティ コンテキストを取得するために使用します。認証を要求するようにアプリケーションを構成する必要があります。

上記のステートメントには例外が 1 つあります。それは、リプレイを防止するための nonce の使用です (リプレイは、攻撃または同じデータを 2 回送信するだけの誰かである可能性があります)。その部分はアプリケーション層でしか扱えません。

于 2014-07-17T15:08:57.343 に答える