https网址中的用户名和密码

jef*_*unt 55 security https url-parameters

考虑URL: https:// foo:password@example.com

上面示例中的用户名/密码部分是否符合此问题中定义的"URL参数" ?

Hol*_*ust 100

将用户名和密码放在主机前面时,此数据不会以相同方式发送到服务器.而是根据使用的身份验证模式将其转换为请求标头.大多数情况下,这将是我在下面描述的Basic Auth.Digest Auth是一种类似(但使用频率较低)的认证方案,现在提供了类似的安全功能.

使用Basic Auth,来自问题的HTTP请求将如下所示:

GET / HTTP/1.1
Host: example.com
Authorization: Basic Zm9vOnBhc3N3b3Jk
Run Code Online (Sandbox Code Playgroud)

您在此处看到的类似字符串的哈希是由浏览器创建的:base64_encode(username + ":" + password).

对于HTTPS传输的外部人员,此信息是隐藏的(与HTTP级别的其他信息一样).您应该注意登录客户端和所有中间服务器.用户名通常显示在服务器日志中,但密码不会.但这并不能保证.当您使用例如在客户端上调用该URL时curl,用户名和密码将在进程列表中清晰可见,并且可能会显示在bash历史记录文件中.

当您使用ayush的方法时,用户名和密码将始终显示在Web服务器,应用程序服务器,缓存等的服务器日志中,除非您专门配置服务器以不记录它.这仅适用于能够读取未加密的http数据的服务器,例如您的应用程序服务器.

基本身份验证由浏览器标准化并通过显示此小用户名/密码弹出窗口来实现.当您将用户名/密码输入通过GET或POST发送的HTML表单时,您必须自己实现所有登录/注销逻辑(这可能是一个优势).但是你永远不应该通过GET参数传输用户名和密码.如果必须,请改用POST.默认情况下,可以防止记录此数据.

当使用用户/密码输入表单和当前常用的后续基于cookie的会话实现身份验证机制时,您必须确保密码是通过POST请求传输的,或者仅通过上述标准化身份验证方案之一传输.

总结我可以说,通过HTTPS传输数据是安全的,只要你注意密码不会出现在意想不到的地方.但该建议适用于任何密码的任何转移.

  • 顺便说一下,除了基本认证方案之外,您是否介意进一步详细阐述其他认证方案? (3认同)