web-dev-qa-db-ja.com

HTTP基本認証に使用するエンコードは何ですか？

RFC2617では、ユーザー名とパスワードをbase64にエンコードするように指定されていますが、base64アルゴリズムへの入力用のオクテットを作成するときに使用する文字エンコードは指定していません。

US-ASCIIまたはUTF8を想定すべきですか？または、誰かがこの質問をすでにどこかで解決しましたか？

httpbasic-authentication
72
Dobes Vandermeer

元の仕様-RFC 2617

RFC 2617 は、「ISO-8859-1」または「未定義」として読み取ることができます。あなたの選択。多くのサーバーがISO-8859-1を使用して（それが好きかどうかは問わない）、他のサーバーに送信すると失敗することが知られています。したがって、おそらく唯一の安全な選択はASCIIに固執することです。

詳細および状況を修正する提案については、ドラフト "HTTP基本認証のエンコードパラメータ" （RFC 7617の基礎を形成した）を参照してください。

新規-RFC 7617

2015年以降、RFC 2617を廃止する RFC 7617 があります。古いRFCとは対照的に、新しいRFCはユーザー名とパスワードに使用される文字エンコードを明示的に定義します。

  • デフォルトのエンコーディングは未定義のままです。 IsはUS-ASCIIとの互換性のみが必要です（つまり、ASCIIバイトをASCIIバイト、UTF-8と同様にマッピングします）。
  • オプションで、サーバーは追加の認証パラメーターcharset="UTF-8"その挑戦では、このように：
    WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"
    これは、サーバーがユーザー名/パスワードに非ASCII文字を受け入れ、UTF-8（具体的には正規化フォームC）でエンコードされることを期待していることを通知します。 UTF-8のみが許可されていることに注意してください。

完全版：

仕様 を読んでください。正確なエンコード手順、サポートされるべきUnicodeコードポイントのリストなどの追加の詳細が含まれている場合。

ブラウザのサポート

2018年の時点で、ユーザーがユーザー名またはパスワードに非ASCII文字を入力すると（サーバーがcharsetパラメーターを使用しない場合でも）、通常、最新のブラウザーはデフォルトでUTF-8になります。

  • ChromeもUTF-8を使用しているようです
  • Internet ExplorerはUTF-8を使用しません（ issue＃11879588 ）
  • Firefoxは、v59で現在計画されている変更を試行しています（ bug 1419658 ）

レルム

realmパラメーターは、R​​FC 7617でもASCII文字のみをサポートしています。

57
Julian Reschke

簡単な答え：encoded-wordsがRFC2047（MIME）に従って使用されない限り、iso-8859-1。

長い説明：

RFC2617、セクション2 （HTTP認証）定義basic-credentials：

basic-credentials = base64-user-pass
base64-user-pass  = <base64 encoding of user-pass, 
                     except not limited to 76 char/line>
user-pass         = userid ":" password
userid            = *<TEXT excluding ":">
password          = *TEXT

BNF（上記のような）の定義については、RFC2616（HTTP 1.1）を参照せずに仕様を読むべきではありません。

この仕様は、HTTP/1.1仕様 2 のコンパニオンです。このドキュメントの拡張BNFセクション2.1を使用し、そのドキュメントで定義されている非端末とHTTP/1.1仕様の他の側面の両方に依存しています。

RFC2616、セクション2.1 定義[〜＃〜] text [〜＃〜]（エンファシスマイニング）：

TEXTルールは、メッセージパーサーによって解釈されることを意図していない説明的なフィールドの内容と値にのみ使用されます。 * TEXTの単語には、RFC 2047の規則に従ってエンコードされた場合にのみ、ISO-8859-1以外の文字セットの文字が含まれる場合があります。

TEXT           = <any OCTET except CTLs, but including LWS>

RFC2047 （MIME pt。3）ルールに従って他のエンコーディングを検出しない限り、間違いなくiso-8859-1です。

// Username: Mike
// Password T€ST
Mike:=?iso-8859-15?q?T€ST?=

この場合、Wordのユーロ記号は、 iso-8859-15 に従って0xA4としてエンコードされます。これらのエンコードされたWord区切り文字を確認し、指定されたエンコードに基づいて内部の単語をデコードする必要があることを理解しています。そうしないと、パスワードは=?iso-8859-15?q?T¤ST?=（iso-8859-1として解釈されたときに0xA4が¤にデコードされることに注意してください）と思うでしょう。

これは私の理解であり、これらのRFCよりも明確な確認を見つけることはできません。そして、それのいくつかは矛盾しているようです。たとえば、RFC2047の4つの目標（MIME、pt。3）の1つは、再定義することです。

uS-ASCII以外の文字セットのテキストヘッダー情報を許可するメッセージの形式。

ただし、RFC2616（HTTP 1.1）は、デフォルトでiso-8859-1に設定されるTEXTルールを使用してヘッダーを定義します。つまり、このヘッダー内のすべての単語はエンコードされた単語（つまり、=?...?=フォーム）である必要がありますか？

また、関連する、現在のブラウザはこれを行いません。 utf-8（Chrome、Opera）、iso-8859-1（Safari）、システムコードページ（IE）またはその他（Firefoxの場合はutf-8の最上位ビットのみ）を使用します。

編集：私はちょうどこの答えがサーバー側の観点から問題をもっと見ることに気付いた。

38
Michiel van Oosterhout

ログインプロンプトで非ASCII文字を入力したときのブラウザーの動作に興味がある場合は、Firefoxで試しました。

各ユニコード値の最下位バイトを取得することにより、everithingをISO-8859-1に遅延変換するようです、例えば：

User: 豚 (\u8c5a)
Password: 虎 (\u864e)

以下と同じようにエンコードされます：

User: Z (\u005a)
Password: N (\u004e)

0x5a 0x3a 0x4e base64-> WjpO

4
anda apterus

RFCは別として、Spring framework、BasicAuthenticationFilterクラスでは、デフォルトはTF-8です。

この選択の理由は、UTF-8はすべての可能な文字をエンコードできるのに対し、ISO-8859-1（またはASCII）はエンコードできないためです。システムでサポートされていない文字でユーザー名/パスワードを使用しようとすると、動作が壊れたり、セキュリティが低下したりする可能性があります。

4
holmis83