当您将用户名和密码放在主机前面时,这些数据不会以此方式发送到服务器。相反,它会根据所使用的身份验证模式转换为请求头。大多数情况下,这将是我下面描述的基本身份验证。类似的(但显着不常用)身份验证方案是摘要身份验证,现在提供了可比较的安全功能。对于基本身份验证,来自问题的HTTP请求将看起来像这样:GET / HTTP/1.1 Host: example.com Authorization: Basic Zm9vOnBhc3N3b3Jk 你在那里看到的类似哈希值的字符串是由浏览器这样创建的:base64_encode(username + ":" + password)。对于HTTPS传输的外部人员来说,这些信息是隐藏的(就像HTTP级别上的其他所有内容一样)。但是,您应该注意客户端和所有中间服务器的登录。用户名通常会显示在服务器日志中,但密码不会。虽然不能保证这一点。当您在客户端使用例如curl调用该URL时,用户名和密码将在进程列表中清晰可见,并可能出现在bash历史文件中。当您通过GET请求发送密码,例如http://example.com/login.php?username=me&password=secure,除非您明确配置服务器不记录它,否则用户名和密码将始终出现在您的Web服务器、应用程序服务器、缓存等服务器日志中。这仅适用于能够读取未加密HTTP数据的服务器,例如您的应用程序服务器或任何中间框架,如负载均衡器、CDN、代理等。基本身份验证已经被标准化并由浏览器实现,它会显示一个小的用户名/密码弹出窗口,您可能已经见过了。当您将用户名/密码放入通过GET或POST发送的HTML表单中时,您必须自己实现所有的登录/注销逻辑(这可能是一个优势,并允许您更好地控制登录/注销流程,但需要再次安全地实现)。但是,您永远不应该通过GET参数传输用户名和密码。如果必须使用POST。这默认情况下防止记录此数据。当使用用户/密码输入表单和随后的基于cookie的会话实现身份验证机制时,您必须确保密码仅通过POST请求或上述标准化身份验证方案之一进行传输。总之,我可以说,通过HTTPS以这种方式传输数据很可能是安全的,只要您确保密码不会出现在意外的位置。但是,这个建议适用于任何方式的任何密码传输。
curl
参数)时,所有本地进程都可以看到系统进程列表中的URL并收集它们(例如通过ps aux
)。如果您运行不受信任的代码(或者有可能通过代码注入),这将是一个问题。只有在凭据以URL方式传递(或作为curl
的附加标头)时才会出现此问题,而不是将它们传递给然后管道到curl中。通常,其他问题比这个问题更重要。 - Holger Just