67

次の URL を検討してください: https://foo:password@example.com

この質問で定義されているように、上記の例のユーザー名とパスワードの部分は「URL パラメーター」と見なされますか?

4

1 に答える 1

114

ユーザー名とパスワードをホストの前に置くと、このデータはサーバーに送信されません。代わりに、使用される認証スキーマに応じてリクエスト ヘッダーに変換されます。ほとんどの場合、これは以下で説明するBasic Authになります。類似の (しかしあまり使用されていない) 認証スキームは、現在同等のセキュリティ機能を提供するDigest Authです。

基本認証では、質問からの HTTP リクエストは次のようになります。

GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk

そこに表示されるハッシュのような文字列は、ブラウザによって次のように作成されますbase64_encode(username + ":" + password)。

HTTPS 転送の部外者には、この情報は隠されています (HTTP レベルの他のすべてのものと同様)。ただし、クライアントとすべての中間サーバーでのログ記録に注意する必要があります。通常、ユーザー名はサーバー ログに表示されますが、パスワードは表示されません。ただし、これは保証されません。たとえば を使用してクライアントでその URL を呼び出すとcurl、ユーザー名とパスワードがプロセス リストに明確に表示され、bash 履歴ファイルに表示される場合があります。

http://example.com/login.php?username=me&password=secureのように GET リクエストでパスワードを送信すると、ユーザー名とパスワードは常にWeb サーバー、アプリケーション サーバー、キャッシュなどのサーバー ログに表示されます。ログに記録しないようにサーバーを特別に構成しない限り。ただし、これは、アプリケーションサーバーやロードバランサー、CDN、プロキシなどのミドルボックスなど、暗号化されていない http データを読み取ることができるサーバーにのみ適用されます。

基本認証は標準化されており、既に見たことがあるかもしれないこの小さなユーザー名/パスワード ポップアップを表示することで、ブラウザーによって実装されます。ユーザー名/パスワードを GET または POST 経由で送信される HTML フォームに入れる場合、すべてのログイン/ログアウト ロジックを自分で実装する必要があります (これは利点であり、追加された "これを再度安全に実装しなければならないというコスト)。ただし、GET パラメータでユーザー名とパスワードを転送することは絶対にしないでください。必要な場合は、代わりに POST を使用してください。は、デフォルトでこのデータのロギングを防止します。

現在一般的に使用されているように、ユーザー/パスワード入力フォームとそれに続く Cookie ベースのセッションを使用して認証メカニズムを実装する場合、パスワードが POST 要求で転送されるか、上記の標準化された認証方式のいずれかのみで転送されることを確認する必要があります。

結論として、パスワードが予期しない場所に表示されないように注意する限り、HTTPS 経由でデータを転送することは安全である可能性が高いと言えます。しかし、そのアドバイスは、あらゆるパスワードのあらゆる転送に適用されます。

于 2011-02-12T23:25:39.310 に答える