HTTPSがある場合にRESTサービスセキュリティが必要な理由

この素晴らしい記事http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/を参照してください。これは、WebサービスのAmazonのようなセキュリティについて述べています。ただし、既にHTTPSを使用している場合、なぜ必要なのかという質問がチームにありました。私は答えることができませんでした。実際のところ、彼らは正しいかもしれませんが、ガットはそうではないと教えてくれます。

RESTサービスを提供するときにHTTPSが機能しない場所もありますか？サードパーティのウェブサイトが好きですか？

パブリックインターウェブ経由でWebサービスをセキュリティで保護した経験がある人は、あなたの経験に光を当ててください。

前もって感謝します。

編集：明確にするために、私はユーザー認証ではなく、クライアント認証について話します。ユーザー認証は、HTTPS + RESTを介したプレーンテキストであると想定できます。

私の心配は、HTTPSを介してクライアントエンドポイントがクライアントアプリケーションなしでWebサービスを使用できるにもかかわらず、すべてがプレーンテキストであるため、クライアントがアクセスせずに誰でもWebサービスを使用できることです。

すでにHTTPSを使用している場合、Gmailまたはユーザーアカウントを持つ他のサイトにユーザー名とパスワードを提供する必要があるのはなぜですか？答えはあなたの質問に対する答えと同じです。

HTTPSは、何よりもまず、サーバーとクライアント間の暗号化された接続を提供します。

HTTPSに固有の信頼は、ブラウザソフトウェアにプリインストールされている主要な認証局に基づいています（これは、「信頼する必要があることを証明するために、認証局（VeriSign / Microsoft / etcなど）を信頼する」と同等です）。

サーバーが各ユーザーに証明書を提供しない限り、サーバーは他の認証方法なしではクライアントを信頼できません。

HTTPSは、盗聴や「中間者」攻撃の防止に非常に優れています。セッションのすべてのトラフィックを暗号化するため。

しかし、ほとんどの人はブラウザに付属しているデフォルトの証明書を使用しているため、独自の個人証明書を作成する方法や、それを使用するようにブラウザを設定する方法がわかりません。

これにより、HTTPSは認証ダイアログを盗聴などから保護する以外に、ユーザー認証にはほとんど役に立たなくなります。

HTTPSは、チャネルのセキュリティを確保することを目的としており、発信者が誰であるかを証明することや、考慮する必要がある他の多くのことを証明することではありません。認証、承認、およびトランスポート層の暗号化は、考慮する必要があるもののほんの一部です。Webアプリケーションに関連する既知の脆弱性の多くは、REST APIに非常に適用されます。入力の検証、セッションクラッキング、不適切なエラーメッセージ、内部の従業員の脆弱性などを考慮する必要があります。大きなテーマです。

ロバート

クライアントSSL証明書のアプローチを採用し、セキュリティをAPIから分離できます。このアプローチの大きな欠点は、APIを使用するクライアントが増えるにつれてコストが高くなる操作オーバーヘッドです。

とにかく、HTTP基本認証は、公に消費されるサービスの大部分にとっては問題ありません。