HTTP 的安全性

HTTP 用于在 Internet 上进行通信，因此用户、信息提供者和应用程序开发人员应注意 HTTP/1.1 中安全性的局限性。 本部分没有提供此处提到的问题的明确解决方案。 它提供了一些建议，以降低安全风险。

个人信息

在 HTTP 中，客户端通常可以访问大量个人信息，例如：用户名、电子邮件地址、密码、位置、加密密钥等。 我们应该小心，以防止通过 HTTP 协议将客户端的这些个人信息无意中泄漏给其他来源。

1. 滥用服务器日志信息

在这种情况下，所有用户的个人数据都应以加密形式存储在服务器上。

2. 敏感信息的传输

HTTP 无法规范所传输数据的类型。 HTTP 无法事先确定任何请求上下文中信息的任何特定部分的敏感性。

泄露服务器的任何特定软件版本可能会使服务器机器更容易受到针对包含安全漏洞的软件的攻击。

充当网络防火墙门户的代理应特别注意标头信息的传输，这些信息用于识别防火墙后面的主机。

3. 在 URI 中编码敏感信息

链接的来源可能是私人信息，因此强烈建议用户能够选择是否发送 referer 字段。

如果我们引用的页面是使用源协议传输的，则客户端不应在 HTTP 请求中包含 Referer 字段。

4. 与 Accept 标头相关的隐私问题

Accept 请求标头可以向所有被访问的服务器泄露客户端的信息。

基于文件和路径名的攻击

HTTP 源服务器的实现应小心限制 HTTP 请求返回的文档，仅限于服务器管理员打算使用的文档。

例如， Microsoft Windows、UNIX 和其他操作系统使用“--”作为路径组件，它显示当前目录上方的目录级别。 在这种类型的系统上，如果 HTTP 服务器会以其他方式禁止访问通过 HTTP 服务器访问的资源，则 HTTP 服务器必须禁止在 Request-URI 中使用任何此类构造。

DNS 欺骗

HTTP 客户端严重依赖 DNS（域名服务），因此通常容易受到基于 IP 地址和 DNS 名称故意错误关联的安全攻击。 因此，客户端在假定 IP 地址和 DNS 名称关联的持续有效性时应小心谨慎。

如果 HTTP 客户端缓存主机名查找的结果以提高性能，则它们必须遵守 DNS 报告的 TTL 信息。 当先前访问的服务器的 IP 地址更改时，如果 HTTP 客户端不遵守此规则，则可能会被欺骗。

Location 标头和欺骗

如果单个服务器支持多个组织，并且任何组织互不信任，则它必须检查响应中的 Location 值和 Content-Location 标头，这些标头是在所述组织的控制下生成的。 这些组织用于确保它们不会尝试使它们无权访问的资源无效。

身份验证凭据和空闲客户端

用户代理和现有的 HTTP 客户端通常无限期地保留身份验证信息。 HTTP/1.1 没有为服务器提供任何指示客户端丢弃这些缓存凭据的方法。

为了解决这个问题，我们可以鼓励使用空闲超时、密码保护和其他方法来减少此问题固有的安全问题。