2016-11-12 16 views
0

these instructionsのように、CASサーバをREST認証を有効にするように設定しました。しかし、それを動作させるためには、資格情報を平文(コンテンツタイプtext/htmlまたはxml)で提出しなければならず、指示に従ってapplication/x-www-form-urlencodedではありません。後者の形式で送信すると、資格情報が失われます。CAS REST認証APIはtext/*を受け付けますが、application/*コンテンツタイプは受け入れません

ログイン資格情報をプレーンテキストで送信するのは不快です。これはCASのバグですか、どのように修正できますか?私は、テキストコンテンツタイプ対アプリケーションとしてログインクレデンシャルを送信するのが安全ではないと想定しています。後者は、送信されたコンテンツをハッシュ(または何らかの形で他のものを難読化する)しているためです。

maven overlaythis solutionを実装することで、コンテンツタイプに関係なく資格情報が失われているため、CASのバグを修正する必要があることにも言及しておきます。その後、テキストベースのコンテンツタイプだけが動作し、CASは認証されます(プログラム処理の容易さのために、XML/XMLまたは通常のテキストではなくHTMLを返しても迷惑に見えます)。

RELATED REST API endpoint /v1/tickets appears to lose credential request parameters

答えて

1

コンテンツタイプは、要求内のデータの機密性には影響を与えません。要求でapplication/x-www-form-urlencodedで送信する場合は、機密性のみが考慮される場合は、text/htmlまたはtext/xmlより安全ではありません。リクエストに含まれているものを使用する際にセキュリティ上の付加価値はありません。生のリクエストソース(MitM攻撃者)にアクセスする人は、リクエストの内容をどちらかの方法で確認します。 HTTPSは、ノード間のネットワーク上のMitM攻撃者に関して、SSLが終了したエンドポイント(ソースとターゲットのコンピュータ、および信頼できるルートを持つ企業プロキシなどのSSLを終了するノード間のノード)では効果的にこのリスクを緩和しますクライアント上の証明書 - かなり一般的な設定です)。

text/plain代わりのapplication/x-www-form-urlencodedを使用しての可能性のあるセキュリティのため利益として、あなたの他の質問にmy answerを参照してください。要するに、text/plainを使用すると、CSRF攻撃を防ぐことができます。

関連する問題