15．安全考虑 （Security Consideration）
这一部分是用来提醒程序开发人员，信息提供者，和用户关于HTTP/1.1安全方面的限制。讨论并不包含对披露问题的明确的解决办法，然而，确对减少安全风险提供了一些建议。

15.1 个人信息 （Personal Information）
HTTP的客户端经常要对大量的个人信息保密（例如用户的名字，域，邮 件地址，口令，密匙等。），并且应当非常小心地防止这些信息无意识地通过HTTP协议泄露到其他的资源。我们非常强烈地建议应该给用户提供一个方便的界面 来控制这种信息的传播，并且设计者和实现者在这方面应该特别注意。历史告诉我们在这方面的错误经常引起严重的安全和/或者隐私问题，并导致对设计或实现者 的公司产生非常不利的影响。

15.1.1服务器日志信息的滥用 （Abuse of Server Log Information）
服务器是用来保存用来指定用户读模型或感兴趣主题的请求的。这些信息通常显然是需保密的，并且它的使用在某些国家被法律保护。利用HTTP协议提供数据的人们必须保证在这些数据被许可的情况下分发。

15.1.2敏感信息的传输 （Transfer of Sensitive Inforamtion）
就像任何数据传输协议一 样，HTTP不能调整数据传输的内容，也没有任何经验方法去决定给定请求背景里特定信息的敏感性。因此，应用程序应该尽可能为此信息提供者提供对此信息的 控制。背景里有四个头域需要提出来，这四个头域是：Server，Via，Referer 和From。

揭露服务器特定软件版本可能会使服务器的机器更容易受到通过软件安全漏洞来进行***。实现者应该使Server头域成为可设置的选项。

用作穿过网络防火墙入口的代理应该特别小心关于指定防火墙后的主机（host）头域信息的传输。特别地，代理应该移除或用杀毒后的版本替换任何产生于防火墙之后的Via头域。

Referer头域允许学习的读模型和反向链接牵引。虽然它非常有用，但也会被滥用如果用户详情没有从包含在Referer头域里信息分离开来。即使当个人信息已经被移除了，那么这个Referer头域也可能指定私有的文档URI，此文档不适合作为共有的。

From头域里的信息可能会和用户的私有兴趣或他们站点的安全策略相冲突，因此这些信息在用户使此头域内容无效、有效和改变的情况下不能被传输。用户必须能在用户的喜爱或应用程序的缺省设置范围内设置此头域的内容。

我们建议，尽管不需要，给用户提供一个方便的触发器来使发送From和Referer头域信息有效或失效。

User-Agent（14.4节）或Server（14.38节）头域有时候能被用来去确定一个特定的客户端或服务器存在安全漏洞。不幸的是，同样的信息经常被用于其它的有价值的目的因为HTTP现在没有更好的机制。

15.1.3 URI中敏感信息的编码（Encoding Sensitive Information in URI’s）
因为一个链接的源可能是私有信息或者可能揭露其它私有信息资源，所以强烈建议用户能选择是否需要发送Referer头域。例如，浏览器客户端可能为了开放/匿名方式会有一个触发开关，此开关可能使Referer头域和From头域信息的发送有效/无效。

客户端不应该包含一个Referer头域在一个非安全HTTP请求里，如果参考页面在一个安全的协议上传输。

利用HTTP协议的服务作者不应该利用基于窗体GET提交敏感数据，因为这个能引起数据在请求URI里被编码。许多已存在的服务，代理，和用户代理将记录请求URI于某些对第三方可见的地方。服务器能利用基于窗体POST提交来取代基于窗体GET提交。

15.1.4连接到Accept头域的隐私问题
Accept请求头域能揭露用户的信息给所有被访问的服务器。Accept- Language头域能揭露用户的私有信息，因为能理解特定语言的人经常被认为就是某个特定种族里的成员。提供选择设置Accept-Language头 域内容于每次请求里的用户代理被强烈鼓励让设置过程包含一个让用户知道隐私丢失的消息。

限制私有信息的方法可能是在缺省情况下让用户代理不发送Accept-Language头域，并且让用户代理询问用户是否发送Accept-Language头域给服务器如果用户代理通过查看任何由服务器产生的Vary响应头域时发现这次发送能提高服务的质量。

请求里的用户配置性的接受头域如果这些接受头域（accept header fileds）包含质量值，那么他们应该被服务器用作相对信赖和长久的用户标识符。这样的用户标识符将会允许内容提供者进行click-trail跟踪以 及允许合作内容提供者匹配跨服务器click-trail或者形成单个用户窗体提交。注意对于许多并不在代理服务器后面的用户，运行用户代理的主机的网络 地址也将作为长久用户的标识符。在代理服务器被用作增强隐私的环境里，用户代理在提供给终端用户接受（accept）头域配置选项上应该是保守的。提供高 度头域配置能力的用户代理应该警告用户隐私可能的丢失。

15.2 基于文件和路径名称的***
HTTP的源服务器的实现应该小心地限制HTTP请求返回的文档给那些由管理员授权的人。如果 HTTP服务器要把HTTP URIs翻译成文件系统的调用，那么服务器必须小心去对待提供给HTTP客户端的文件传输。例如，UNIX，微软Windows，和其他操作系统都利 用”..”去指示当前的父目录。对于这一个系统，如果HTTP服务器允许访问一个资源，但这些资源通过HTTP服务器不能访问，那么一个HTTP服务器必 须不允许任何这样的构造存在于请求URI。同样的，用作服务器内部文件的引用的文件（如访问控制文件，配置文件，脚本代码）必须受到保护不让不合适的获 取，因为他们可能包含敏感的信息。经验告诉我们一个在HTTP服务器实现里的一个小小的错误会带来安全风险。

15.3 DNS欺骗
使用HTTP的客户端严重依赖于域名服务，因此这会导致基于IP和DNS名称的不关联的***。客户端需要小心关注IP地址/DNS名称关联的持久合法性。

特别地，HTTP客户端为了确认IP地址/DNS名称关联性，应该依赖于客户端自己的的名称解析器，而不是缓存以前主机（host）名称查找 （host name lookups）结果。许多平台已经能本地的去缓存主机名称查找（host name lookups）当在合适的时候，并且他们应该被配置成能这样做。然而，只有当被名称服务器报告的TTL（Time To Live）信息使被缓存的信息仍然有用时，缓存查找（lookups）才是合适的。

如果HTTP客户端为了提高性能去缓存主机名称查找（host name lookups）的结果，那么他必须观察被DNS报告的TTL信息。

如果HTTP客户端不能看到这条规则，那么他们就会被欺骗当以前访问的IP地址改变时。因为网络地址的改变变得很平常，所以这种形式的***在不断增加。看到这个规则能减少潜在的安全***的可能性。

此要求照样能提供客户端负载平衡行为因为重复的服务器能利用同一个DNS名称，此要求能降低用户在访问利用策略（strategy）的站点中的体验失败。

15.4 Location头域和欺骗
如果单个的服务器支持互不信任的多个组织，那么它必须检查自称的某个组织控制下产生响应里Location和Content-Location头域值，以确认这些组织没有企图使它们没有权限的资源无效。

15.5 Content-Disposition的问题
RFC 1806 [35]，在HTTP中经常使用的Content-Disposition（见19.5.1节）头域就源于此文档，有许多非常认真的安全考虑在此文档里说 明。Content-Disposition并不是HTTP标准版本中的一部分，但自从它被广泛应用以来，我们正在证明它对使用者的价值和风险。详细资料 见RFC 2183 [49]（对RFC 1806的升级）。

15.6 授权证书和空闲客户端
现有的HTTP客户端和用户代理通常会不确定地保留授权信息。HTTP/1.1并没有为服务器提供一个方法 让服务器去指导客户端丢弃这些缓存的证书（credentials）。这是一个重大缺陷，此缺陷需要扩展HTTP协议来解决。在某些情况下，证书的缓存能 干涉应用程序的安全模型，此情况包含但不局限于：

Ø         这样的客户端。此客户端已经空闲时间超长并且服务器可能希望再次让客户端出示证书。

Ø         这样的应用程序。此应用程序包括了一个会话中断指令（例如在一页上有"logout"或者"commit"的按钮），依据此指令应用程序的服务器端“知道”没有更多的理由为客户端保留证书。

这是作为当前单独研究的。有很多解决这个问题的社区，并且我们鼓励在屏幕保护程序，空闲超时，和其他能减轻安全问题的方法里利用密码保护。特别地，能缓存证书的用户代理被鼓励去提供一个容易地访问控制机制让在用户的控制下去丢弃缓存的证书。

15.7 代理和缓存 （Proxies and Caching）
本质上说，HTTP代理是中间人（men-in-the- middle），并且存在中间人***（man-in-the-middle attacks）危险。代理运行在其上系统的折中能导致严重的安全和隐私问题。代理拥有对相关安全信息、用户和组织的个人信息、和属于用户和内容提供者的 专有信息的访问权限。一个妥协的代理，或一个没有考虑安全性和隐私性的代理可能会被用做进行***的代理。

代理操作者应该保护代理运行其上的系统，正如他们保护任何包含或传输敏感信息的系统一样。特别的，代理上收集的日志信息经常包含较高的个人敏感信息，和/或关于组织的信息。日志信息应该被小心的保护，并且要合适地开发利用。（见15.1.1）节。

代理的设计者应当考虑到设计和编码判定所涉及到的隐私和安全问题，以及他们提供给代理操作人员配置选项（尤其是缺省配置）所牵涉到的隐私和安全问题。

代理的用户需要知道他们自己不比运行代理的操作员更值得信赖；HTTP协议自身不能解决这个问题。

当合适的时候，对密码学的正确应用，可能会保护广泛的安全和隐私***。密码学的讨论不在本协议文档的范围内。

15.7.1关于代理的服务***的拒绝
 代理是存在的。代理很难被保护。关于此研究正在进行。