開発者ツール · Base64 エンコーダーおよびデコーダー
HTTP 基本認証ヘッダーが Base64 で構築およびデコードされる方法
· 仕組み
base64 セキュリティ
Authorization: Basic ヘッダーは、Base64 を介して実行される単なるユーザー名:パスワードです。この投稿では、値がどのように構築されるか、リクエスト ログから値をデコードする方法、およびエンコードによって何も隠蔽されない理由を示します。
資格情報が正しいにもかかわらず存続する 401 — 微妙に間違った文字列にデコードされるヘッダー値
HTTP API は 401 Unauthorized を返し、Authorization: Basic ヘッダーを期待します。値は、スキーム単語 Basic、1 つのスペース、および Base64 文字列です。プレフィックスの欠落、エンコードされたプレフィックス、または気づかれない改行により、表示されているユーザー名とパスワードが正しいように見えても、サーバーが受け取る内容が変化します。
その文字列をデコードすると、ユーザー名:パスワード (文字通り 2 つの間のコロン) が読み取られます。ユーザー名:パスワードのバイトは UTF-8 でエンコードされてから Base64 でエンコードされ、ヘッダー値が生成されます。資格情報が admin:s3cret で、UTF-8 バイトが 0x61 0x64 0x6D 0x69 0x6E 0x3A 0x73 0x33 0x63 0x72 0x65 0x74 (ASCII 文字とコロン) の場合、Base64 エンコードにより YWRtaW46czNjcmV0 が生成されます。ヘッダーは Authorization: Basic YWRtaW46czNjcmV0 です。
RFC 7617 のレシピ: 'user:pass'、UTF-8、Base64 — 正確な手順とコロンの役割
これは、RFC 7617 で定義されている完全な HTTP 基本認証スキームです。これはシンプルで標準化されており、それ自体ではセキュリティは提供されません。ヘッダーを読み取る人は誰でもすぐにそれをデコードしてパスワードを読み取ることができます。これが、Basic 認証に HTTPS が必須である理由です。エンコーディングはトランスポート要件であり、セキュリティ機能ではありません。パスワードは、他のデータと同様に、UTF-8 バイトとして転送されます。 Base64 は HTTP プロトコルで使用される単なる表記法です。
ネットワーク ログから Basic ヘッダーをデコードする必要がある場合、プロセスは簡単です。Basic を削除し、Base64 デコードの残りを取得すると、ユーザー名:パスワードが得られます。コロンはユーザー名とパスワードの間の区切り文字です。 RFC 7617 では、資格情報がユーザー ID : パスワードであり、最初のコロンが区切り文字であると指定されています。パスワードにコロンが含まれている場合、2 番目のコロンはパスワード内の単なる文字です。受信者には 1 つの明確な境界が必要であるため、コロンは構造的です。デコード後に最初のコロンを検索します。ユーザーを識別する前のすべてがパスワードであり、その後のすべてがパスワードです。したがって、コロンが欠落している場合は、Base64 アルファベットの問題ではなく、不正な形式の資格情報ペアを示します。
成功した例: admin:s3cret のエンコードとログからのヘッダーのデコード - 両方向 (末尾の改行バグを含む)
ユーザー名が admin、パスワードが pass:word の場合、資格情報は admin:pass:word となり、YWRtaW46cGFzczp3b3Jk にエンコードされます。デコードするときは、最初のコロンでのみ分割し、ユーザー名 admin とパスワード pass:word を指定する必要があります。コロンごとに分割すると、パスワードが誤って分割されてしまいます。 RFC 7617 の charset パラメーターでは、資格情報は UTF-8 でエンコードされると記載されています。つまり、ユーザー名またはパスワード内の非 ASCII 文字は、Base64 エンコードの前に UTF-8 バイトに変換されます。
ユーザー名がカフェ (アクセント付き e) の場合、UTF-8 バイトは 0x63 0x61 0x66 0xC3 0xA9 (ASCII 文字の 4 バイトとアクセント付き文字の 2 バイト) であり、完全な資格情報のカフェ:パスワードにはカフェのバイト、コロン バイト 0x3A、パスワードの順が含まれます。 Base64 出力はすべてのバイトを忠実にエンコードします。デコーダーは、デコードされたバイトをラテン語の 1 ではなく UTF-8 テキストとして解釈することを知っている必要があります。
コロン、スペース、および非 ASCII を含むパスワード — 最初のコロンが分割される理由と、charset パラメータの目的
実際に動作する例: admin:s3cret から始めます。 UTF-8 バイトに変換します: a=0x61、d=0x64、m=0x6D、i=0x69、n=0x6E、:=0x3A、s=0x73、3=0x33、c=0x63、r=0x72、e=0x65、t=0x74。 10 進数: (97、100、109、105、110、58、115、51、99、114、 101、116)。これらの 12 バイトを Base64 エンコードし、3 つずつ 4 つのグループにグループ化します (Base64 文字 4 つからなる 4 つのグループが生成されます)。
エンコードされた値は YWRtaW46czNjcmV0 です。 Authorization ヘッダーは Authorization: Basic YWRtaW46czNjcmV0 です。最初の境界を移動せずに、パスワード側に別のコロンを含めることができます。スペースと非 ASCII テキストも、両方のピアがテキスト エンコーディングに同意する場合は存続します。 ToolAcre は、発行する UTF-8 バイトを検証できますが、異なる文字セットを予期する古いサーバーには、Base64 変換以外の相互運用性の問題が残ります。
TLS なしではこれが安全ではない理由 — デコードすると、ヘッダーを見た人にはパスワードが表示されます
受信したヘッダーをデコードするには、Basic を取り除き、YWRtaW46czNjcmV0 を Base64 デコードしてバイトを戻し、UTF-8 テキストとして解釈して admin:s3cret を取得し、最初のコロンで分割してユーザー名とパスワードを抽出します。よくある間違いは、echo の後に改行が続くことです。 echo admin:s3cret | を実行すると、 Unix シェルの Base64 では、echo はデフォルトで改行を追加するため、admin:s3cret を改行でエンコードします (12 ではなく 13 バイト)。
Base64 出力は異なります: YWRtaW46czNjcmV0Cg== (パディングと余分な文字)。パスワードに改行文字が含まれているため、この値を含む認証ヘッダーは失敗します。修正するには、echo -n を使用するか、printf または改行を追加しないツールを介してパイプします。 Base64 エンコーダとデコーダはこれを回避します。貼り付けたものを正確にエンコードし、隠された改行はありません。 TLS は、認証情報の形式ではなく、トランスポートの脅威を変更します。保護された接続内では、ヘッダーはリクエストの残りの部分とともに暗号化されます。ソフトウェアがそれをログに記録または表示すると、Base64 値により、再利用可能な資格情報がデコードできる人に再び公開されます。墨消しはどの観測点でも依然として重要です。
よくある間違い — エコーからの改行、'Basic ' プレフィックスの欠落、値の二重エンコード
別のエラーとして、Basic プレフィックスがありません。 Authorization ヘッダー値は Base64 単独では有効ではありません。スキーム名 (Basic または Bearer など) の後にスペース、資格情報が続きます。一部のシステムでは、YWRtaW46czNjcmV0 を認証情報として認識できませんが、Basic YWRtaW46czNjcmV0 では成功します。 401 をデバッグする場合は、サーバーが Authorization ヘッダーを正しく解析しているかどうかを確認してください。
スキームは HTTP 標準では大文字と小文字を区別しませんが、多くの実装では大文字と小文字が区別されます。 API ドキュメントを確認してください。二重エンコードも別の障害モードです。すでに Base64 エンコードされている文字列を Base64 エンコードすると、出力は異なる文字列になります。 YWRtaW46czNjcmV0 をエンコードすると、WVdkbWFXNDZjek5qY3JldA== (まったく異なります) が生成されます。一部のシステムでは、誤ってエンコードを 2 回適用してしまう可能性があります。1 回目は認証情報のセットアップ時、もう 1 回目はヘッダーの構築時です。シェル コマンドからの改行は、Base64 の前後の空白として拒否されるのではなく、資格情報の一部としてエンコードできるため、特に見落とされやすくなります。結果のヘッダーは余分なバイトを含むパスワードにきれいにデコードされ、サーバー側の認証失敗のように見える 401 が生成されます。
この内容の対象外 — ダイジェスト スキームとベアラー スキーム、およびブラウザーの資格情報プロンプト
デコーダは Base64 の単一レイヤを想定しているため、二重エンコーディングは不一致を引き起こします。これが、資格情報の値を (プレーンテキストではなく) Base64 形式でログに記録する場合に混乱を招く可能性がある理由です。誰かが一度デコードを適用すると、ユーザー名とパスワードが表示されます。 2 回適用すると、難読化が表示されます。ダイジェスト認証 (RFC 7616) とベアラー認証 (OAuth トークン用) は異なるスキームを使用し、それぞれが異なる資格情報形式を持ちます。
ダイジェストでは、サーバーが nonce を送信し、クライアントがハッシュを計算し、ヘッダーにパスワードではなくハッシュとユーザー名を含める必要があります。通常、ベアラーは JSON Web トークン (JWT) であり、Base64url でエンコードされていますが、ユーザー名のプレフィックスは付いていません。基本認証は両方よりも簡単ですが、認証情報がヘッダーで読み取れるため、TLS を使用しないと完全に安全ではありません。ダイジェストとベアラーは同じ Authorization ヘッダー フィールドを使用しますが、その値にまったく異なる意味を割り当てます。ブラウザの資格情報プロンプトは、Basic に加えてユーザー インターフェイスとキャッシュ動作を追加します。この記事では、これらの認証システムを比較するのではなく、基本資格情報ペイロードの構築と検査に止まります。
要点: 基本認証は Base64 であり、保護ではありません — Base64 エンコーダーとデコーダーを使用して、認証情報をどこにも送信せずにローカルでヘッダー値を確認できる仕組み
API が複数の認証スキームをサポートしている場合は、利用可能な最も安全な認証スキームを選択します。 Base64 エンコーダとデコーダは、基本認証エラーのデバッグに役立ちます。資格情報文字列 (ユーザー名、コロン、パスワード) を貼り付けると、ツールはすぐに Base64 値を生成します。結果を送信ヘッダーと比較すると、不一致がわかります。逆に、ネットワーク ログからヘッダー値を貼り付け、Basic プレフィックスを削除し、デコードしてサーバーが何を見たかを確認します。
学習のために、admin:s3cret を貼り付けて出力を観察し、パスワードを変更して Base64 がどのように変化するかを確認します。ヘッダーの構築方法を理解すると、デコードに RFC 形式の知識が必要な理由と、コロンが Base64 ではなく構造要素である理由が明確になります。ローカル チェックでは、運用環境からコピーされたライブ パスワードではなく、作成された資格情報を使用する必要があります。ペアをエンコードし、出力を入力パネルに戻してデコードします。一致する句読点と正確な末尾文字は、ヘッダーがどこかに送信される前に表現のラウンドトリップを証明します。