REST API / Webサービスを保護するためのベストプラクティス[終了]

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

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

RESTにはWS- *に類似した仕様が意図的にないことを理解していますが、ベストプラクティスまたは推奨パターンが浮かび上がってきたことを願っています。

議論や関連文書へのリンクは非常に高く評価されます。必要に応じて、.NET Frameworkのv3.5を使用して構築されたREST API /サービスのPOX / JSONシリアル化メッセージでWCFを使用します。

微調整が言ったように、Amazon S3は作業に適したモデルです。それらのリクエスト署名には、偶発的および悪意のあるリクエストのリプレイの両方から保護するのに役立ついくつかの機能（タイムスタンプの組み込みなど）があります。

HTTP Basicの良いところは、事実上すべてのHTTPライブラリがサポートしていることです。もちろん、この場合はSSLを要求する必要があります。これは、プレーンテキストのパスワードをネット経由で送信することは、一般的には悪いことです。SSLを使用する場合は、ダイジェストよりもベーシックの方が適しています。これは、呼び出し元が資格情報が必要であることをすでに知っている場合でも、ダイスはnonce値を交換するために追加のラウンドトリップを必要とするためです。Basicでは、呼び出し元は資格情報を初めて送信するだけです。

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

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

たとえば、独自のサービスを開発する際に、AmazonのS3 RESTサービスから多くのアイデアを取り入れました。ただし、リクエストの署名に基づくより高度なセキュリティモデルを使用しないことを選択しました。より単純なアプローチは、SSLを介したHTTP基本認証です。あなたはあなたの状況で何が最もうまくいくかを決めなければなりません。

また、私はO'reillyの本RESTful Web Servicesを強くお勧めします。コアコンセプトについて説明し、いくつかのベストプラクティスを提供します。一般に、それらが提供するモデルを取得して、独自のアプリケーションにマップできます。

また、特にhttp apiを対象とするトークンベースの認証のための新たなオープンプロトコルであるOAuthもご覧ください。

これは、flickrが採用するアプローチと非常によく似ており、牛乳の「レスト」APIを覚えています（必ずしもレストフルAPIの良い例ではありませんが、トークンベースのアプローチの良い例です）。

Githubに優れたチェックリストがあります。

認証

• 認証、トークンの生成、パスワードの保存で車輪を再発明しないでください。標準を使用します。

• 使用Max Retryして刑務所にはログインしていただけます。

• すべての機密データに暗号化を使用します。

JWT（JSON Webトークン）

• ランダムな複雑なキー（JWTシークレット）を使用して、ブルートフォースによるトークンの強制を非常に困難にします。

• ペイロードからアルゴリズムを抽出しないでください。バックエンドでアルゴリズムを強制します（HS256またはRS256）。

• トークンの有効期限（TTL、RTTL）をできるだけ短くします。

• 機密データをJWTペイロードに保存しないでください。簡単にデコードできます。

OAuth

• redirect_uriホワイトリストに登録されたURLのみを許可するには、常にサーバー側を検証してください。

• 常にトークンではなくコードと交換してください（を許可しないでくださいresponse_type=token）。

• ランダムハッシュで状態パラメーターを使用CSRFして、OAuth認証プロセスを防止します。

• デフォルトのスコープを定義し、各アプリケーションのスコープパラメータを検証します。

アクセス

• DDoS /ブルートフォース攻撃を回避するためにリクエストを制限する（スロットリング）。

• サーバー側でHTTPSを使用してMITM（中間者攻撃）を回避する

• HSTSSSLヘッダーを使用してSSLストリップ攻撃を回避します。

入力

• GET（読み取り）、POST（作成）、PUT/PATCH（置換/更新）、およびDELETE（レコードを削除する）操作に応じて適切なHTTPメソッドを使用し405 Method Not Allowed、要求されたメソッドが要求されたリソースに適切でない場合に応答します。

• リクエストAcceptヘッダー（コンテンツネゴシエーション）のコンテンツタイプを検証して、サポートされている形式（など）のみを許可しapplication/xml、一致しない場合はapplication/json応答で406 Not Acceptable応答します。

• 検証content-typeポストされたデータのあなたは（例えば受け入れるようapplication/x-www-form-urlencoded、multipart/form-data、application/json、など）。

• ユーザー入力を検証して、一般的な脆弱性（XSS、SQLインジェクション、リモートコード実行など）を回避します。

• URLでは機密データ（資格情報、パスワード、セキュリティトークン、またはAPIキー）を使用しないでくださいAuthorization。標準のヘッダーを使用してください。

• API Gatewayサービスを使用して、キャッシング、Rate Limitポリシー（割り当て、スパイクアレスト、同時レート制限など）を有効にし、APIリソースを動的にデプロイします。

処理

• 認証プロセスの破損を防ぐために、すべてのエンドポイントが認証の背後で保護されているかどうかを確認してください。

• ユーザー独自のリソースIDは避けてください。/ user / 654321 / ordersの代わりに/ me / ordersを使用します。

• IDを自動インクリメントしないでください。代わりにUUIDを使用してください。

• XMLファイルを解析する場合は、XXE（XML外部エンティティ攻撃）を回避するために、エンティティ解析が有効になっていないことを確認してください。

• XMLファイルを解析する場合は、エンティティ展開が有効になっていないことを確認して、指数エンティティ展開攻撃によるBillion Laughs / XML爆弾を回避してください。

• ファイルのアップロードにはCDNを使用します。

• 大量のデータを処理する場合は、ワーカーとキューを使用してバックグラウンドでできるだけ多くの処理を行い、HTTPブロッキングを回避するために応答を高速で返します。

• DEBUGモードをオフにすることを忘れないでください。

出力

• X-Content-Type-Options: nosniffヘッダーを送信します。

• X-Frame-Options: denyヘッダーを送信します。

• Content-Security-Policy: default-src 'none'ヘッダーを送信します。

• -指紋ヘッダを削除しX-Powered-By、Server、X-AspNet-Versionなど

• content-type応答を強制します。戻るapplication/json場合、応答のコンテンツタイプはapplication/jsonです。

• 資格情報、パスワード、セキュリティトークンなどの機密データを返さないでください。

• 完了した操作に応じて適切なステータスコードを返します。（例えば200 OK、400 Bad Request、401 Unauthorized、405 Method Not Allowed、など）。

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

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

たとえば、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などに適用できます。

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

• OASIS XACML Webサイト
• NIST ABAC標準

私はOAuthを数回使用し、他のいくつかの方法（BASIC / DIGEST）も使用しました。私は心からOAuthを提案します。次のリンクは、OAuthの使用に関して私が見た中で最高のチュートリアルです。

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

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

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

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

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

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

SOAPの世界がセキュリティ標準でかなりカバーされているという事実は、それがデフォルトで安全であることを意味しません。そもそも、規格は非常に複雑です。複雑さはセキュリティのよい友ではありません。XML署名のラッピング攻撃などの実装の脆弱性は、ここでよく見られます。

.NET環境については、あまり役に立ちませんが、「JavaでWebサービスを構築する」（10人程度の作者によるブリック）は、WS- *セキュリティアーキテクチャ、特にその癖を理解するのに大いに役立ちました。

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

追加したい（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（記事とビデオ）

@NathanはどちらがシンプルなHTTPヘッダーであるかを示し、一部のユーザーはOAuth2とクライアント側のSSL証明書を言っていました。その要点はこれです... REST APIは実際にはAPIのスコープ外であるため、セキュリティを処理する必要はありません。

代わりに、Webプロキシの背後にあるHTTPヘッダー（SiteMinder、Zermatt、またはApache HTTPdのような一般的なアプローチ）であるか、OAuth 2のように複雑であるかに関係なく、セキュリティ層をその上に置く必要があります。

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

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

上記のステートメントには例外が1つあります。それは、ナンスを使用してリプレイ（攻撃または誰かが同じデータを2回送信するだけ）を防ぐことです。その部分は、アプリケーション層でのみ処理できます。

Webアプリケーションセキュリティについては、さまざまなセキュリティ攻撃のチートシートを提供するOWASP（https://www.owasp.org/index.php/Main_Page）をご覧ください。アプリケーションを保護するために、できるだけ多くの手段を組み込むことができます。APIセキュリティ（承認、認証、ID管理）に関しては、すでに述べたように複数の方法があります（基本、ダイジェスト、OAuth）。OAuth1.0にはループホールがあるため、OAuth1.0aを使用できます（OAuth2.0は、仕様の関係上、広く採用されていません）。

久しぶりですが、質問はまだ関連性がありますが、答えが少し変わった可能性があります。

API Gatewayは、柔軟で高度に構成可能なソリューションです。私はKONGをかなりテストして使用し、私が見たものを本当に気に入りました。KONGは、ユーザーの管理に使用できる独自の管理REST APIを提供します。

Express-gateway.ioはより新しいAPIゲートウェイでもあります。