REST認証スキームのセキュリティ

228

バックグラウンド：

REST Webサービスの認証スキームを設計しています。これは「本当に」安全である必要はありません（個人的なプロジェクトに近いものです）が、エクササイズ/学習体験としてできるだけ安全にしたいと考えています。面倒なこと、たいていの場合は設定にかかる費用が不要なので、SSLを使用したくありません。

これらのSOの質問は、私を始めるのに特に役立ちました。

Amazon S3の認証の簡易バージョンを使用することを考えています（私はOAuthが好きですが、私のニーズには複雑すぎるようです）。リプレイ攻撃を防ぐために、サーバーによってランダムに生成されたnonceをリクエストに追加しています。

質問に行くには：

S3とOAuthはどちらも、いくつかの選択されたヘッダーとともにリクエストURLに署名することに依存しています。どちらも POSTまたはPUTリクエストのリクエスト本文に署名しません。これは、URLとヘッダーを保持し、リクエストの本文を攻撃者が必要とするデータに置き換える中間者攻撃に対して脆弱ではありませんか？

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

rest  authentication  oauth  amazon-s3  rest-security 
— dF。
ソース
6
Amazon S3は、ヘッダー文字列の一部としてContent-MD5を含めて、記述したMITM攻撃を防ぐことができます。
— laz
8
MD5は非常に弱いハッシュ関数であり、その使用は長年にわたって推奨されていません：en.wikipedia.org/wiki/MD5。最近はSHA2を使用してください。MD5は、アイデンティティの危機にある豚の口紅です。
— Henrik
6
Startcomは、主要なブラウザーで証明書の警告をスローしない無料のSSL証明書を提供しています
— Plato
5
@SeanKAnderson（暴言：2008年にすでに多くの攻撃を自動化しているスパイ機関によってインターネットが包囲されているときに人々が99.99999％sについて話すのは不合理だ「いや、問題ない。おばあちゃんがハッキングできないから」
— Henrik
2
私は、無料のSSL証明書のために、これらの日LetsEncryptをお勧めします@Plato
— shuttle87

回答:

168

以前の回答では、データ転送のコンテキストでSSLについてのみ言及しており、実際には認証については触れていませんでした。

REST APIクライアントを安全に認証することについて本当に質問しています。TLSクライアント認証を使用している場合を除き、SSL だけではREST APIの実行可能な認証メカニズムではありません。client authcを使用しないSSLはサーバーのみを認証します。これは、本当にクライアントを認証する必要があるため、ほとんどのREST APIには関係ありません。

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

これらのスキームは、要求が予期された誰かによって送信されたことを認証します。TLS（SSL）（クライアント認証なし）は、ネットワーク経由で送信されるデータが改ざんされないようにします。これらは別々ですが、補足的な問題です。

興味のある方のために、私はHTTP認証スキームとそれらがどのように機能するかについてのSOの質問を拡張しました。

— レヘーズルウッド
ソース
16
丁度。APIに関する限り、SSLが検証する唯一のことは、SSLが処理する呼び出しが途中で乱されていないことです。APIはまだ誰がそれと話しているのか、あるいはまったくアクセスできるべきかどうかわからない。
— Tim Gautier
1
いい答えだ。私はまた、これらの優れたリソースを見..持つ推薦owasp.org/index.php/Web_Service_Security_Cheat_Sheetとowasp.org/index.php/REST_Security_Cheat_Sheet（DRAFT）
— dodgy_coder
2
マイナーなポイントですが、SSLを使用すると、盗聴や中間者攻撃を防ぐという追加の利点もあります。
— dodgy_coder
@Les Hazlewood HTTPを介したHTTP基本認証が、サーバーが誰と通信しているかを判別するのにどのように役立つかを説明できますか？
— 春の
@Les Hazlewoodここで私はそれを質問しました。TNXのstackoverflow.com/questions/14043397/...
— 春の
60

RESTはWebの標準を使用することを意味し、Web上の「安全な」転送の標準はSSLです。それ以外のものは一種のファンキーなものになり、暗号化ライブラリを使用可能にする必要があるクライアントに追加の展開作業が必要になります。

SSLにコミットした後は、原則として認証に特別な必要はありません。これもまた、手の込んだ署名プロトコルよりもはるかに単純であり、安全な接続のコンテキストで効果的であるため、Web標準を使用してHTTP基本認証（各要求と共に送信されるユーザー名とシークレットトークン）を使用できます。パスワードがプレーンテキストを超えないようにする必要があります。そのため、パスワードがプレーンテキスト接続で受信された場合、パスワードを無効にして開発者にメールすることもできます。また、通常のパスワードを記録しない場合と同様に、受信時に資格情報がどこにも記録されないようにする必要があります。

HTTPダイジェストは、シークレットトークンが渡されないようにするため、より安全な方法です。代わりに、サーバーが相手側で確認できるハッシュです。ただし、上記の予防策を講じた場合、感度の低いアプリケーションではやり過ぎになる可能性があります。結局のところ、ユーザーのパスワードは、ユーザーがログインしたときに（ブラウザーで高度なJavaScript暗号化を実行している場合を除いて）プレーンテキストで送信され、同様に各リクエストでCookieが送信されます。

APIを使用する場合、開発者がWebサイトにログインするときに使用するパスワードではなく、トークン（ランダムに生成された文字列）をクライアントに渡す方がよいことに注意してください。したがって、開発者はサイトにログインして、API検証に使用できる新しいトークンを生成できる必要があります。

トークンを使用する主な理由は、侵害された場合はトークンを置き換えることができるためです。一方、パスワードが侵害された場合、所有者は開発者のアカウントにログインして、トークンで何でもできるようになります。トークンのさらなる利点は、同じ開発者に複数のトークンを発行できることです。おそらく、アプリが複数あるか、アクセスレベルの異なるトークンが必要なためです。

（SSLのみの接続にすることの影響をカバーするように更新されました。）

— マヘモフ
ソース
3
GoDaddyのSSL証明書は年間30ドルくらいで手に入ると思います。Verisign SSL証明書がどれだけの期間（年間600ドルか、私が正しく覚えていれば何か）を確認して驚いたが、GoDaddyオプションは完全に実現可能です。
— ブライアンアームストロング
19
SSL / TLS相互認証を使用しておらず、ユーザー/クライアントが使用する証明書がサーバーによって信頼されている場合を除き、サーバー/アプリケーションに対してユーザーを認証していません。サーバー/アプリケーションに対してユーザーを認証するには、さらに何かを行う必要があります。
— Pauld、2011
5
ライアン：SSL暗号化これらの日は、あなたがなどジャンゴやRailsのようなWebアプリケーションフレームワークとの応答を生成するために使用したいものと比較し、処理能力のかなり小さな量を取る
— キャメロン・ウォルシュ
4
startcomの証明書は無料で広く認知されています。cacert.orgが少ない認識とオープン代替手段です
— ディマTisnek
17
これは、認証に関する問題には対応していません。
— Sam Stainsby
8

または、この問題の既知の解決策を使用してSSLを使用することもできます。自己署名入りの証明書は無料で、個人的なプロジェクトの権利ですか？

— 西
ソース
2
自己署名証明書は無料ですが、静的IPが必要です。
— dF。
8
@dF証明書に対して支払われるコマーシャルの特定のライセンス要件を除いて、静的IPを持つ必要はありません。
— Chris Marisic
両端（クライアントとサーバー）で証明書ストアを制御できる場合、これは実行可能なオプションかもしれませんが...証明書の管理と配布は、おそらく開発環境よりも実稼働ではるかに複雑です。コミットする前に、この代替案の複雑さを理解してください。
— 2014年
5

URLのパラメーターの1つとして本文のハッシュが必要で、そのURLが秘密鍵を介して署名されている場合、中間者攻撃では、本文を生成するコンテンツでのみ本文を置き換えることができます。同じハッシュ。MD5ハッシュ値を使用して簡単に実行できるようになりました。SHA-1が壊れている場合でも、問題はありません。

改ざんからボディを保護するには、ボディの署名を要求する必要があります。中間者攻撃は、署名を生成する秘密鍵を知らないため、これを解読する可能性が低くなります。 。

— ZaDDaZ
ソース
9
有効なコンテンツと同じmd5ハッシュを生成する文字列を考え出すことは、本来よりもはるかに簡単かもしれませんが、同じ値にハッシュする有効なコンテンツの悪意のあるバージョンを思いつくことは、依然として非常に困難です。これが、md5がパスワードハッシュに使用されなくなった理由ですが、ダウンロードの確認には引き続き使用されます。
— Tim Gautier、
1

提案によって、クライアントがサーバーと通信することが困難になることを覚えておいてください。彼らはあなたの革新的なソリューションを理解し、それに応じてデータを暗号化する必要があります。このモデルは（amazon \ yahoo \ google ..でない限り）パブリックAPIにはあまり適していません。

とにかく、ボディコンテンツを暗号化する必要がある場合は、次のような既存の標準とソリューションを確認することをお勧めします。

XML暗号化（W3C標準）

XMLセキュリティ

— LiorH
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.