問題の紹介
最近、私はいくつかのリクエスト署名アルゴリズムに取り組んでいましたが、署名される部分にクエリ文字列を含めることに関する意見が「多様」であることがわかりました。
簡単に言うと、署名用の文字列にクエリ文字列を含めることに反対する人の主張は、クエリ文字列が変更される可能性がある (たとえば、値が変更される、引数が削除/追加される、順序が変更される) というものです。
また、私はプロキシやロードバランサーでそのような動作を経験したことはありません。Authorizationヘッダーの非表示（Apache/WSGIなど）、リクエストのメソッドの変更（ロードバランサー、おそらくAmazonのサーバーがそのようなことをする）などの動作を経験したことがありますが。リバースプロキシやロードバランサーでカスタムスクリプト/ルールを使用してそのような動作を有効にできることは知っていますが、どれでもリクエストの一部。
クエリ文字列を含める必要があるという仮定に基づいて多くの作業が行われてきましたが、リクエストの最も重要な部分の 1 つに署名しないのは愚かなことです。したがって、クエリ文字列を生の形式で (URL 内で渡されるとおりに) 含めることが将来的に問題になるかどうかを知る必要があります。
実際の質問
私の質問は次のとおりです。
プロキシやロード バランサーがクエリ文字列を変更するのは一般的なことですか? 私には馬鹿げているように思えます。 デフォルトでそれを実行するプロキシやロード バランサー (ソフトウェアまたはそのインストール) をご存知ですか?
このような場合、プロキシ/ロードバランサーのレベルで署名検証を処理できると確信していますが、これが私たちが管理していない仲介者間で一般的である場合は、実行可能な議論になる可能性があります。
ぜひ、それについてあなたが知っていることを教えてください。質問があればお知らせください。
明確にするために、クエリ文字列?arg1=val1&arg2=val2次の URL の「 」の部分を意味します。
http://example.com/something/else?arg1=val1&arg2=val2
そして「クエリ文字列の変更「クライアントとサーバーで見た目が異なって見える可能性のあるアクション (サーバーはクライアントが使用したクエリ文字列とは異なるクエリ文字列を認識します) を意味します。」
答え1
最近のリバース プロキシの多くは、クエリ文字列を変更できます。ただし、ロード バランサーやプロキシがデフォルトでそれを実行する理由はわかりません。
おそらく、スティッキーセッションの負荷分散に URI を使用しているのでしょうが、それは本当に愚かなことです。
つまり、いいえ、デフォルトで URI とパラメータを変更するロード バランサーについては知りません。
答え2
これを実行するプロキシはまだ見たことがありませんが、IP ごとに実行できず、ユーザーが Cookie を無効にしている場合でも動作させたい場合には、セッションの固定性に対する実行可能なソリューションになる可能性があります。