[解決済み】REST認証スキームの安全性

質問

背景

REST Webサービスの認証スキームを設計しています。これはセキュアである必要はありませんが（どちらかというと個人的なプロジェクトです）、練習や学習経験として可能な限りセキュアにしたいと思います。SSLを使用するのは、設定の手間と、ほとんどの場合、費用がかかるのが嫌だからです。

特にこのSOの質問は、私のスタートに役立つものでした。

• RESTful認証
• REST API / ウェブサービスを保護するためのベストプラクティス
• 最高のSOAP/REST/RPC Web APIの例？そして、なぜそれらが好きなのでしょうか？そして、それらの何が問題なのでしょうか？

の簡易版を使おうと思っています。 Amazon S3の認証 (私が好きなのは OAuth が、私のニーズには複雑すぎるようです）。私は、ランダムに生成される ノンス リプレイ攻撃を防ぐために、サーバーから提供されたものをリクエストに追加します。

質問に入ります。

S3もOAuthも、リクエストURLといくつかの選択されたヘッダーに署名することに依存しています。 どちらもリクエストボディに署名しない POSTやPUTリクエストの場合。これは、URLとヘッダを保持し、リクエストボディを攻撃者が望む任意のデータに置き換える、中間者攻撃に対して脆弱ではないでしょうか？

署名される文字列にリクエストボディのハッシュを含めることで、これを防ぐことができるようです。これは安全でしょうか？

解決方法は？

以前の回答では、データ転送の文脈でSSLに言及しただけで、実際には認証については触れていませんでした。

REST APIクライアントの安全な認証についての質問ですね。 TLSクライアント認証を使っていない限り、SSL 単独 は、REST API の認証メカニズムとして有効ではありません。 クライアント認証なしのSSLでは サーバー を認証したいのですから、ほとんどの REST API には関係ありません。 クライアント .

TLSクライアント認証を使用しない場合は、ダイジェストベースの認証スキーム（Amazon Web Serviceのカスタムスキームなど）、OAuth 1.0a、あるいはHTTP Basic認証（ただしSSL経由のみ）のようなものを使用する必要があります。

これらのスキームは、リクエストが期待される誰かによって送信されたことを認証するものです。 TLS (SSL)(クライアント認証なし)は、ワイヤ上で送信されたデータが改ざんされていないことを保証します。 これらは別個の、しかし補完し合う関係です。

興味のある方は、SOの質問で HTTP認証のスキームとその仕組み .