Requests: セッションのAuthorizationヘッダーがリダイレクト時に送信されない

リダイレクト先はどこですか？

ああ、別のドメイン。 firebase-apiserver03-tah01-i​​ad01.dapi.production.nest.com

そうです、それはやや意図的なことです。新しいホストにリダイレクトされるときに、認証ヘッダーを削除することに非常に積極的です。 これは、オフホストリダイレクトでヘッダーを永続化することによって引き起こされたCVE2014-1829に対処するための安全機能です。

ただし、特定の観点からは、リクエストではなくSessionにAuthorizationヘッダーを設定しているため、ここにはまだバグがあります。 原則として、これが意味するのは、「リダイレクトがどこに行くかは気にしない、ヘッダーを追加する」ということです。 私はまだこのアプローチを望んでいます。これにより、この特定のインスタンスが多少トリッキーになったとしても、少なくともどのような形の攻撃にもさらされないようになります。 しかし、私はここで私たちがあまりにも妄想的であると確信することを受け入れています。

しかし、私はここで私たちがあまりにも妄想的であると確信することを受け入れています。

私は確信することに対してあまりオープンではありませんが、耳を傾けることをいとわないです。

とは言うものの、_allowed_ドメイン間でそのようなヘッダーを永続化するために、別のAuthメカニズムを作成することもできます。そのため、 rebuild_auth何らかの作業を行う必要があります。

私はそれが今どのように機能するかの安全性について議論するつもりはありません。 ただし、「安全でない」動作を選択するためのメカニズムがあると便利です。 おそらく、これらのヘッダーを永続化するためのベースドメイン（この場合はnest.com）を設定するか、それらを送信してもよいドメインのリストを設定します。

ええ、それはリクエストのコアが提供するよりもはるかに複雑です。 そのため、この種の場合は、別のAuthクラス/ハンドラーが最適に機能するのではないかと考えています。 無条件にprepare_auth呼び出さないと確信しているので、うまくいくとは思いません。

prepare_auth無条件に呼び出さないため、標準モデルでは機能しません。 ただし、そのAPIの少し珍しい使用法であっても、トランスポートアダプターを使用してこの役割を果たすことができます。

TAはここで推奨するのは絶対に間違っていると思います。

• authがセッションに提供されている場合、セッションが行うすべての要求に対して認証を送信する必要があります。
• おそらく、 session.authを削除する必要があります。 特に役に立ちません。

authがセッションに提供されている場合、セッションが行うすべての要求に対して認証を送信する必要があります。

私は根本的に同意しません。 セッションは単一のドメインでは使用されません。使用されていれば、問題はありません。

おそらく、session.authを削除する必要があります。 特に役に立ちません。

便利だと思います。 ただし、タプルの割り当てが許可されていない方がよいと思います。 むしろ、それを使用するドメインを指定するAuthクラスが必要です。 リクエストを使用するときにドメインの認証情報を指定できるrequests- toolbeltからすることもできます。 これにより、セッションベースの認証を処理するためのもう少し安全な方法が提供されます。 欠点は、ユーザーがその種の認証にオプトインする必要があることです。

また、リダイレクトのためにヘッダーを永続化できるように、これを修正する必要があります。

@jtherrmannこれが認証ヘッダーである場合、問題を回避する最も簡単な方法は、要求に必要なヘッダーを常に配置するセッションレベルの認証ハンドラーを設定することです。

これについて何か進展や追加の考慮がなされていますか？
私は同じ問題にぶつかっています。

@ethanroyあなたのすぐ上のコメントで、セッションレベルの認証ハンドラーを使用するという私の提案以外に追加の考慮

関連：セッションが認証をリダイレクトして削除した場合、 get再度呼び出すと、認証が再適用され、キャッシュされたリダイレクトが使用されます。 だから2回ノックするとあなたは入ります。意図された行動？

>>> s = requests.Session()
>>> s.headers.update({"Authorization": "Token {}".format(API_TOKEN)})
>>> s.get(url)

<Response [403]>

>>> s.get(url)

<Response [200]>

@GregBakkerはい、そうです。 それは意図された行動の合流点です。 ただし、このバグは、元の403が発生してはならないことを示しています。

@Lukasaが「問題を回避する最も簡単な方法は、セッションレベルの認証ハンドラーを設定することです」と言うとき、それは今日機能するものですか？ 私がコードで見ているものに基づいて、答えはノーですが、あなたの言葉遣いは私が何かを逃しているかどうか疑問に思います。 あなたはセッション認証属性を設定することについて話しているのですよね？

ええ、それはうまくいくはずです。

@jwineingerでは、どうやってこの問題を回避したのですか？ それでも同じように動作するようです。

Nest固有の回避策は2つあります。

1つは、Authorizationヘッダーを使用するのではなく、access_tokenでauthパラメーターを渡すことです。 https://gist.github.com/tylerdave/409ffa08e1d47b1a1e23でこれを見つけました

もう1つは、使用するヘッダーを含む辞書を保存し、リダイレクトに従わずに、ヘッダーを再度渡す2番目の要求を行うことです。

    headers = {'Authorization': 'Bearer ' + access_token, 'Content-Type': 'application/json'}
    initial_response = requests.get('https://developer-api.nest.com', headers=headers, allow_redirects=False)
    if initial_response.status_code == 307:
        api_response = requests.get(initial_response.headers['Location'], headers=headers, allow_redirects=False)

私はこれと同じ問題に遭遇し、カスタムrequests.Session実装でrebuild_authメソッドをオーバーライドすることで回避しました。

from requests import Session

class CustomSession(Session):
    def rebuild_auth(self, prepared_request, response):
        return

s = CustomSession()
s.get(url, auth=("username", "password"))

@ sigmavirus24 @ gabriel-looのソリューションの何が問題になっていますか？ セキュリティ上の懸念？

@ j08lueはい。 スレッドをお読みください。 新しいドメインへの任意のリダイレクトに従う前に認証を削除しないことに関連するCVEがあります。 このように問題について考えてください：

私はapi.github.comリクエストを送信していますが、攻撃者が管理しているanother-domain.comへのリダイレクトを追跡させ、リポジトリへの書き込みアクセス権（リクエストを含む）でトークンを渡します。実際にはAPIを介してコミットを行っているのに、リクエストに対してコミットを行っているように見える場合があります。 リクエストにコードを含めると、セキュリティ体制が弱まり、積極的に害を及ぼす可能性があります。 これは、リダイレクトごとに認証資格情報を無条件に送信した場合に発生する可能性があります。

それでも、リダイレクトが悪意のあるものではないとしましょう。サービスの資格情報を別の会社やサービスに漏らしても問題ありませんか？ 元のサービスは、あなた、あなたの顧客、または他の何かのために機密データを保存する場合があります。 リダイレクトされた新しいドメインが資格情報を使用せず、予期しないデータとしてログに記録する可能性がある場合でも、それらを攻撃してそれらのログを取得できる人は、どこにパズルを解くことができれば、元のドメインに対して資格情報を使用できます。彼らは属しています。 あなたは本当にそのリスクを冒しても構わないと思っていますか？

イラストをありがとう、@ sigmavirus24。 この懸念が最終的に機密ヘッダーをリダイレクトに転送することを禁止している場合、なぜこのスレッドはまだ開いているのですか？ 私はあなたが得るもの（403）よりも適切なエラーを考えることができなかったので、ここでアクションのバグの必要はありませんか？ それとも、@ Lukasa、何を考えていましたか？

私は最近、非公開APIを使用しているときにこの問題にぶつかっていました。 セキュリティ上の懸念は、リダイレクトで認証を取り除く理由として完全に理にかなっています。 @ gabriel-looのような解決策は、そうするのに十分安全な環境にいると人々が信じている場合に検討できるものだと思います。 または、セッションレベルのハンドラー。 または、可能であれば、上記のようにリダイレクトを完全にスキップして回避する別の方法を見つけてください。 したがって、この見解に沿って、これは実際にはバグではありません。

ただし、Python以外のHTTPクライアントの一部がauthヘッダーを_did_受け渡し、そうでない場合でも正常に機能していた理由について、おそらく混乱する必要があるよりも多くの時間を費やしました。 1つの提案：ここでwarningsを介して警告を発行し、ヘッダーが存在して削除されているときに発信者にわかりやすくすることをお勧めします。 これが発信者に警告されたくないものであるということはめったにないと思います。

@tlantz通常、それはかなり合理的に思えます。 プロジェクトとしてのリクエスト（およびその依存関係の1つであるurllib3）は、warningsモジュールまたはロギングを介して何らかの警告を発行するときにかなりの怒りを引き起こしました。 さらに、警告モジュールは、たとえば、最近のバージョンのOpenSSLに対してコンパイルされたバージョンのPythonを使用しないなど、ユーザーがアクションを実行する必要があるもののためのものです。

ほとんどの場合、この動作は、たとえばTLS接続の証明書を検証できないほど問題にはなりません。 それは明らかにあなたやこの問題について彼らの本物のそして正当な欲求不満を表明した他の誰かを助けません。 そのことを念頭に置いて、これをDEBUGレベルでログに記録する方がよいのではないかと思います。 誰かがロギング（一般的にはまともな方法）を使用していて、そのレベルを有効にすると、ログが表示されます。 さらに、リクエスト自体のログが非常に少ないことを考えると、これはデバッグログとしてかなり目立つようになります。 それは公正なトレードオフのように見えますか？

ええ、それは完全に公正なトレードオフのようです。 warnings周りの推論は、私には理にかなっています。 30分ほど戸惑う頃には、とにかくDEBUGで自分のものの周りにlogging追加していると思うので、 DEBUGメッセージだと思います何が機能していないのかを理解しようとして人々が立ち往生しているケースの95％に当たるでしょう。

セッションを使用してAuthorizationヘッダーを保持していますが、リダイレクトで送信されていません
リクエスト（2.18.4）

同僚と私は、この動作に直接関連する問題のデバッグに少なくとも2時間費やしました。 私のユースケースは、API呼び出しをapi.my-example-site.orgからwww.api.my-example-site.orgリダイレクトすることです。 ヘッダーはリダイレクト時に削除されていました。

これが意図された動作である場合（または近い将来変更されない場合）、少なくともドキュメントに追加していただけますか？ 私は自分が間違っていることを理解しようとしてドキュメントを読んで再読し、 Requestクラスのすべてのコードを読みました。 ドキュメントでこの動作に関する警告が表示されていた場合は、数分で問題を修正できたはずです（このスレッドを見つけてからの時間です）。 ただし、ドキュメントの間違った部分を読んでいた可能性があります。

こんにちは@ndmeiri 、カスタムヘッダーの見出しの下にあるリクエストのクイックスタートガイドでこれについての呼びかけがあります。 これを置くのにもっと良い場所があると感じたら、私たちはあなたが持っている提案を検討させていただきます。 このチケットとは直接関係がないので、別の号またはPRに移動することをお勧めします。 ありがとう！

こんにちは@nateprewitt 、カスタムヘッダーセクションを指摘してくれてありがとう！ 明らかに、私はドキュメントのその部分をチェックすることを考えていませんでした。

認証のセクションに、コールアウトまたはコールアウトへの参照も含めると便利だと思います。 現在はかなり忙しいですが、落ち着いたらPRを開いてドキュメントを更新することを検討します。

これが意図された動作である場合

@ndmeiriはい、信頼できない可能性のあるソースに機密認証資格情報を漏らさないようにすることを目的としています。 （ただ明確にします）

＃4983の「信頼できるドメイン」はsessions.pyの実装に含まれなくなったようです。

特定の異なるが安全なURLにリダイレクトすることを_知っている_URLにリクエストを送信していて、Authorizationヘッダーの永続性を使用してリダイレクトを有効にしたい場合、どうすればそれを実現できますか？

どうすればそれを達成できますか？

rebuild_authメソッドにパッチを適用できます。 これは私のために働きます： https ：

@ j08lueありがとう！ コメントが届く前に、 allow_redirectsをFalseに設定し、ユースケースで予想されるいくつかの特定のリダイレクトに明示的に従うコードを追加することで、この問題を回避しました。 これは私にとって短期的な状況なので、これが適切な一時的な解決策であることを願っていますが、必要に応じて長期的にそれを行うためのより良い方法があることを知っておくのは素晴らしいことです。