Werkzeug: WerkzeugがRFC2616に準拠していません

作成日 2016年05月26日  ·  6コメント  ·  ソース: pallets/werkzeug

特に、内部的にWerkzeugは、タイプ「Transfer-Encoding」または「X-PoweredBy」のヘッダーをそれぞれ「HTTP_TRANSFER_ENCODING」および「X_POWERED_BY」に変換します。 ただし、2つのヘッダー「App-Header-1」と「App_Header_1」の両方がリクエストに存在する場合(または「App_Header_1」のみ)、両方とも内部で同じ方法で保存され、さらにWerkzeugは2つを区別しません。 。 この動作はRFC2616HTTP 1.1仕様に準拠していません。この場合、ヘッダー名は、制御文字または区切り文字のない任意の有効なトークンにすることができます。 これには多くの問題があります。リクエストが「App_Header_1」で受信された場合、「HTTP_APP_HEADER_1」に変換され、Flaskなどのフレームワークはそれを同じではない「App-Header-1」として解釈し、それらの値を渡します。正しい動作に依存しているシステムでは、適切な比較戦略の下で「App_Header_1」!= "App-Header-1"として失敗します。

最も参考になるコメント

PEP 3333を参照している場合、この動作はWSGI仕様が原因ではありません。
PEP 3333は、次のように述べています。
HTTP_変数
クライアント提供のHTTPリクエストヘッダーに対応する変数(つまり、名前が「HTTP_」で始まる変数)。 これらの変数の有無は、リクエスト内の適切なHTTPヘッダーの有無に対応している必要があります。

仕様には、アンダースコアの扱い方については何もありません。 実際、どのヘッダーが存在するか存在しないか、つまり「App_H」または「App-H」が存在するかどうかがわからないため、PEP3333に準拠していません。

全てのコメント6件

この動作はWSGI仕様自体が原因で発生し、WerkzeugがWSGI仕様を順守しながら、これら2つのヘッダーを区別することは不可能です。 これが実際に問題になっている状況はわかりません。

ちなみにRFC2616は非推奨ですが、新しいRFCはその点に関して何も変更していません。

また、Werkzeugは、構文レベルでのHTTP要求または応答の解析または書き込みについて責任を負いません。 これは、選択したWSGIサーバーによって実行されます。 Werkzeugにはサーバーが組み込まれていますが、これは標準ライブラリからWSGIサーバーを拡張するだけです。

PEP 3333を参照している場合、この動作はWSGI仕様が原因ではありません。
PEP 3333は、次のように述べています。
HTTP_変数
クライアント提供のHTTPリクエストヘッダーに対応する変数(つまり、名前が「HTTP_」で始まる変数)。 これらの変数の有無は、リクエスト内の適切なHTTPヘッダーの有無に対応している必要があります。

仕様には、アンダースコアの扱い方については何もありません。 実際、どのヘッダーが存在するか存在しないか、つまり「App_H」または「App-H」が存在するかどうかがわからないため、PEP3333に準拠していません。

WSGIは、CGIのPython固有のポートです。 PEP 0333は、「CGI環境変数」の定義に関するCGI仕様を参照しており、次のように述べています。

The HTTP header field name is converted to upper case, has all occurrences of "-" replaced with "_" and has `HTTP_' prepended to give the meta-variable name.

https://tools.ietf.org/html/rfc3875#section-4.1.18を参照して

Werkzeugは、ほとんどの場合、生のHTTPリクエストを解析せず、WSGI環境を生成しないため、これはすべて無関係です。 WSGI環境を解析します。 この特定の実装に対してこの問題を提出している理由がわかりません。 使者を撃ってはいけません。

基本的に、ここにはCGIからの多くのレガシーがあります。これは、Werkzeugが実装しようとしているWSGIに継承されています。

私は本当に戦いを始めるつもりはありません。 ただし、セキュリティへの影響には問題があります。特に、他のヘッダーをフィルタリングせずにアンダースコアを含むヘッダーで機密情報やアプリケーション固有の情報を渡す「レガシー」風のアプリケーションゲートウェイの背後にあるWebサーバーの場合は問題です(具体的な例があります。つまり、これは実際には、最初のコメントで却下した実際の問題です)。 CGIは20年以上前のものであるため、WSGIとHTTPの仕様を優先する必要があります。

生の構文解析について:
https://github.com/pallets/werkzeug/blob/03faf0569861e9d8c8c94785ad5560f735ba72da/werkzeug/serving.py#L123

(具体的な例があります。つまり、これは実際の問題であり、最初のコメントで却下しました)

それなら、私が言えるのは、そのようなサーバーをお持ちでごめんなさいということだけです。 Werkzeugはそれについて何もできません。 あなたが見せたスニペットは、まさに私が「大部分」と言った理由です。 Werkzeugには、開発で使用できる簡単なテストサーバーも含まれています(たとえば、Gunicorn + Nginx / Apacheをセットアップする必要がないようにするため)。 ただし、そのサーバーをインターネットに公開している場合、言及する潜在的な問題は、(セキュリティ)問題の中で最も少ないものになります。

WSGIは、可能な限りCGIと互換性があるように設計されています。 WSGIは、CGIを上書きしたり置き換えたりすることはありません。 WSGI _is_CGI。 WSGIアプリケーションを有効なCGIアプリケーションにするための作業はほとんどありません。 PythonCGIスクリプトのos.environは、ほとんど同等のWSGI環境のように見えます。 これについて何かを変更するときに考慮すべき多くの遺産があります。 プロジェクトとしてのWerkzeugは、これについては何も言いません。特に私はそうです。

繰り返しますが、このプロジェクトのこの問題は無意味です。 この振る舞いはWerkzeugだけではありません。 前回、全体のあいまいさの問題のため、nginxブロックのHTTPヘッダーにアンダースコアがデフォルトで含まれていることを確認しました。 他のほとんどのツールは、おそらくそれらを単に混同しているだけです。 ほとんどのツールでダッシュとアンダースコアの違いがわからない場合は、標準でダッシュとアンダースコアがあると言われていても問題ありません。 誰もが一緒に遊ぶことを余儀なくされ、最終的にはアンダースコア付きのヘッダーを発行するツールが原因です。

このページは役に立ちましたか?
0 / 5 - 0 評価