web-dev-qa-db-ja.com

https URLのユーザー名とパスワード

URLを考慮してください： https：// foo：[email protected]

this question ？で定義されているように、上記の例のユーザー名/パスワードの部分は「URLパラメーター」として資格がありますか？

securityhttpsurl-parameters
55
jefflunt

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

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

_GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk
_

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

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

ayushによるアプローチ を使用すると、ユーザー名とパスワードはalwaysWebサーバー、アプリケーションサーバーのサーバーログに表示されます、キャッシュ、...特にログを記録しないようにサーバーを構成しない限り。これは、アプリケーションサーバーのように、暗号化されていないHTTPデータを読み取ることができるサーバーにのみ適用されます。

基本認証は、この小さなユーザー名/パスワードのポップアップを表示することにより、ブラウザによって標準化および実装されます。ユーザー名/パスワートをGETまたはPOSTを介して送信されるHTMLフォームに配置する場合、すべてのログイン/ログアウトロジックを自分で実装する必要があります（これが有利な場合があります）。ただし、GETパラメーターを使用してユーザー名とパスワードをnever転送する必要があります。必要な場合は、代わりにPOSTを使用します。これにより、デフォルトでこのデータのロギングが防止されます。

現在一般的に使用されているユーザー/パスワード入力フォームと後続のCookieベースのセッションで認証メカニズムを実装する場合、パスワードがPOSTリクエストで転送されることを確認するか、上記の標準化された認証スキームの1つのみ。

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

100
Holger Just