2017-09-09 16 views
1

私の現在のアーキテクチャはLDAP + JSONウェブトークン認証、および私のURLを経由して、トークンを渡すこの方法に基づいています。 https://myHostApp?jwt={myToken}JWTをURLに入れてユーザーを認証するのは安全ですか?

は安全なこの方法を続行するか、私は別の方法でトークンを渡す必要があることですか? また、そのSSLが有効であると仮定します。

+0

私の答えをお読みください。受け入れられた回答は信頼できると見なされるべきではありません。 –

答えて

1

リクエストごとにヘッダーにトークンを渡す必要があります。

+0

これは私がやろうとしていたものですが、クロスドメインWebアプリケーションでは機能しません。 – dbrrt

+0

私はあなたに同意します。また、私の答えをお読みください –

0

httpsを使用しているときは、クエリ文字列を含めてすべて暗号化されているので、あなたのアプローチは完璧です。

+0

ありがとう、私はこれについて疑いがあります。 – dbrrt

+0

リクエストがHTTPS接続で保護されている場合、このような推奨は間違っているため、私はダウンしています。 –

+0

@FlorentMorselli:URLを使用してトークンを渡すよりも、ユーザーリダイレクトに関する推奨事項はありますか?私の場合、私は一時的なトークンだけを渡すので、ブラウザの履歴を使用しても、ユーザーのアクセスが悪い行為になることはありません。 – dbrrt

1

私は受け入れられたanwserに同意しません。 HTTPSを使用するとデータ漏洩を防ぐことができます。しかし、クエリ文字列にトークンが設定されていれば、多くの攻撃が可能です。例:攻撃者はサーバー上のアクセス権を取得する場合

はさらに、すべてのWebサーバは、このようにアクセス要求を記録透過プロキシを使用してブラウザの履歴

  • を使用して、すべてのトークンになります利用可能です。

    偶数RFC6750(OAuth2ベアラトークンの使用)DO NOTは、このトランスポートモードの使用をお勧めしません。

    は、ページのURL内のトークンベアラ渡さないでください:ベアラトークンは は、(例えば、クエリ文字列パラメータとして)ページのURLで渡されるべきではありません。 ベアラトークンは、HTTPメッセージヘッダーまたは機密保持対策が行われている メッセージ本文で渡されるべきです(SHOULD)。 ブラウザ、Webサーバー、およびその他のソフトウェアでは、ブラウザの履歴、Webサーバーのログ、およびその他の のデータ構造で、URLを適切に保護できないことがあります。ベアラトークンがページURLに渡された場合、 の攻撃者は、履歴データ、ログ、 などのセキュリティ保護されていない場所から盗むことができます。

    RFC6750はOAuth2 Frameworkプロトコルを指しますが、これに限定されるものではなく、Webコンテキストでトークンを送信するたびに考慮する必要があります。

  • +0

    おかげさまで、これは非常に興味深いものです。バニラJavaScriptコンテキストで認証トークンをWeb上の外部リソースに渡すことをお勧めしますか?私は、ヘッダーにトークンを渡すユーザーをリダイレクトしたいと仮定しますか? – dbrrt

    関連する問題