HTTP超文本传输协议-HTTP/1.1[15.安全考虑]

15.安全考虑 这一部分是用来提醒程序开发人员,信息提供者,和HTTP/1.1中的安全限制的用户这篇 文档所叙述的事情.虽然这个讨论为减少安全风险确实提供了一些建议,但是它并不包括所透露问题的最终解决方案.	15 Security Considerations This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks.
15.1 个人信息 HTTP的客户机经常对大量的个人信息是敏感的(例如用户的名字,域,邮件地址,口令,密匙等.),并且应当(SHOULD)非常小心地防止这些信息无意 识地通过HTTP泄露到其他的主机.我们非常强烈地建议应该提供给用户一个方便的界面来控制这种信息的分发,并且设计者和使用者在这方面应该特别注意.历 史告诉我们在这方面的错误经常引起严重的安全和/或者机要问题并导致出现对使用者的公司非常不利的公开的情况.	15.1 Personal Information HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, encryption keys, etc.), and SHOULD be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers and implementors be particularly careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate highly adverse publicity for the implementor's company.
15.1.1服务器日志信息的滥用 服务器是处在存储个人数据的位置上,这些数据是关于用户的请求的,这些请求可以识别他们的阅读习惯或者感兴趣的主题.自然这种信息明显是机要的并且在某些 国家对它的处理是受限制的.使用HTTP协议提供数据的人们有责任确保这样的材料不会在没有得到任何公开结果确认的人允许的情况下被散布出去.	15.1.1 Abuse of Server Log Information A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries. People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without the permission of any individuals that are identifiable by the published results.
15.1.2敏感信息的传输 就像任何种类的数据传输协议一样,HTTP不能控制被传输数据的内容,也没有任何一种区分的方法来决定在任何给定请求的上下文中某个特别的信息片段的敏感 性.因此,应用程序应该(SHOULD)提供给发布信息的人尽可能多的对这个信息的控制能力.四个报头域是值得在这段文字中特别提到 的:Server,Via,Referer和From. 暴露服务器详细的软件版本信息可能会导致服务器因为已知有安全漏洞的软件而变得更易受到攻击.开发人员应该(SHOULD)使Server报头域是一个可 配置的选项. 作为通过一个网络防火墙的入口的代理服务器应该(SHOULD)对关于确认防火墙后面的主机的报头信息的传输采取特别的防范.特别的,它们应当移走或者用 清洁的版本代替,Via域在放火墙后面产生. Referer报头允许学习的阅读模式并且可以进行反向连接.虽然它非常有用,但是如果用户的资料没有从Referer包括的信息中分离出来的话它的能力 就可能会被滥用.甚至当信息已经被移开,Referer报头还是可能指示出一个不适于公开的私人文档的URI. 在From域发送的信息可能和用户的个人利益或者他们站点的安全政策相抵触,因此用户如果不能使之失效,对其授权,和修改域的内容的话,它就不应该 (SHOULD NOT)被传输.用户必须(MUST)能够按用户的选择或者应用程序的缺省配置设置这个域的内容. 虽然并不是必须的,我们建议向用户提供一个可以选择允许或者禁止From和Referer信息的发送的方便捆绑界面. 用户代理(14.43节)或者服务器(14.38节)的报头域有时候会被用来判断某个特定的客户机或者服务器有一个可以被利用的特别的安全漏洞.不幸的是 同样的信息经常被用作其它有价值的目的因为HTTP现在没有更好的机制.	15.1.2 Transfer of Sensitive Information Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any a priori method of determining the sensitivity of any particular piece of information within the context of any given request. Therefore, applications SHOULD supply as much control over this information as possible to the provider of that information. Four header fields are worth special mention in this context: Server, Via, Referer and From. Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Implementors SHOULD make the Server header field a configurable option. Proxies which serve as a portal through a network firewall SHOULD take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, they SHOULD remove, or replace with sanitized versions, any Via fields generated behind the firewall. The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can be abused if user details are not separated from the information contained in the Referer. Even when the personal information has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate. The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and hence it SHOULD NOT be transmitted without the user being able to disable, enable, and modify the contents of the field. The user MUST be able to set the contents of this field within a user preference or application defaults configuration. We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information. The User-Agent (section 14.43) or Server (section 14.38) header fields can sometimes be used to determine that a specific client or server have a particular security hole which might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has no better mechanism.
15.1.3 URI中敏感信息的编码 因为一个连接的源地址可能是机要的信息或者可能会暴露另外一个机要的信息源,所以强烈推荐用户能够选择是否发送Referer域.例如,一个浏览器的用户 能够有一个捆绑的选择是公开/匿名浏览,这将会分别允许/禁止Referer和From信息的发送. 如果目标页使用安全的协议传输的话,在一个(不安全)HTTP请求中客户机不应该(SHOULD NOT)包括一个Referer报头域. 使用HTTP协议的服务提供者不应该(SHOULD NOT)使用基于使敏感数据屈服的形式的GET命令,因为这将导致在Request-URI中编码这个数据.许多现有的服务器,代理服务器,和用户代理将 把请求URI日志记录在某个第三方可以看见的地方.服务器可以用基于屈服形式的POST代替.	15.1.3 Encoding Sensitive Information in URI's Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information. Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead
15.1.4连接到Accept报头的机要问题 接受request-header可能暴露关于用户可以进入的所有服务器的信息.特别的Accept-language报头可能暴露用户个人的民族,因为 对特殊语言的理解对特殊的同文化的民族的成员经常有很强的相关性.提供在每个请求中配置发送的Accept-language报头的选项的用户代理被坚定 的鼓励让配置过程包括让用户明白有关机要泄露的信息. 对于用户代理来说一种限制机要泄露的方法是在缺省的情况下忽略发送Accept-language包头,并且如果通过寻找任何由服务器发出的变化的 response-header域,发现这样的发送能够提高服务的质量,就询问用户是否向服务器发送Accept-language报头. 在每个request中发送的为用户精心制作的accept报头域,特别如果这些包括质量价值,能够被服务器用作相关地可信赖的和长久的用户标识符.这样 的用户标识符将会允许内容提供者进行单击轨迹跟踪以及允许合作的内容提供者匹配交叉服务器单击轨迹或者形成单个用户的屈从.注意对于许多并不在代理服务器 后面的用户,运行用户代理的主机的网络地址也将作为长久用户的标识符.在代理服务器被用作增强保密的环境里,用户代理在提供给终端用户accept报头配 置选项上应该是保守的.作为一个保密的极端措施,代理服务器应该在转发请求信息的时候过滤accept报头.提供高度报头配置能力的一般用途的用户代理应 该(SHOULD)警告用户可能涉及的机要泄漏.	15.1.4 Privacy Issues Connected to Accept Headers Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header in particular can reveal information the user would consider to be of a private nature, because the understanding of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration process include a message which makes the user aware of the loss of privacy involved. An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default, and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service. Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability SHOULD warn users about the loss of privacy which can be involved.
15.2 基于文件和路径名称的攻击 实现HTTP的原服务器应该(SHOULD)小心地限制由HTTP请求返回的文档仅仅是那些服务器管理员授权设置的.如果HTTP服务器直接把HTTP URIs翻译成文件的系统名称,服务器必须(MUST)特别注意不要提供没有授权发布给HTTP客户的文件.例如UNIX,微软Windows,和其它操 作系统使用".."作为指示当前目录的上一层的路径的一部分.在这样一个系统中,如果不允许通过HTTP服务器访问那些除授权允许访问以外的资源的 话,HTTP服务器就必须(MUST)禁止在Request-URI中任何这样的结构.同样的,必须(MUST)保护认为仅仅涉及服务器内部的文件(例如 访问控制文件,配置文件,和剧本代码)不要被不适当的获取,因为它们可能包含敏感信息.经验表明在HTTP服务器这样的使用中次要的bug已经转变为威胁 安全的风险.	15.2 Attacks Based On File and Path Names Implementations of HTTP origin servers SHOULD be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators. If an HTTP server translates HTTP URIs directly into file system calls, the server MUST take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On such a system, an HTTP server MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access control files, configuration files, and script code) MUST be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor bugs in such HTTP server implementations have turned into security risks.
15.3 DNS欺骗 客户使用HTTP严重依赖于域名服务,因此一般倾向基于故意不相关的IP地址和DNS名称的安全攻击.客户需要在假定一个IP号/DNS名称关联继续合法 时谨慎. 特别的,HTTP客户对于一个IP号/DNS名称关联的确认应该(SHOULD)依靠对它们名字的解析,而不是存在高速缓存中以前主机名解析查找的结果. 在适当的时候并且他们应该(SHOULD)被设置成这样做的时候,许多论坛已经能够在本地用高速缓存存储主机名.只有当域名服务器报告的TTL(现在时 刻)信息使高速缓存里的信息很可能仍然是有用的时候,对这些高速缓存的查询才是适当的. 如果HTTP客户为了达到提高性能的目的把查询到的主机名结果存在高速缓存中,他们必须(MUST)遵守域名服务器报告的TTL信息. 如果HTTP客户不遵守这个规则,在一个以前访问过的服务器的IP地址改变的时候他们就会被欺骗.在网络重新编号被认为变得日益普遍的时候,这种形式的攻 击的可能性将会增大.遵守这个必要条件将会因此减少这种潜在的安全隐患. 这个必要条件也改进了客户机对使用同样域名的镜像服务器的平衡加载行为并且减少了用户访问使用这种策略的站点经历失败的可能性.	15.3 DNS Spoofing Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. Clients need to be cautious in assuming the continuing validity of an IP number/DNS name association. In particular, HTTP clients SHOULD rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous host name lookups. Many platforms already can cache host name lookups locally when appropriate, and they SHOULD be configured to do so. It is proper for these lookups to be cached, however, only when the TTL (Time To Live) information reported by the name server makes it likely that the cached information will remain useful. If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS. If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes. As network renumbering is expected to become increasingly common [24], the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability. This requirement also improves the load-balancing behavior of clients for replicated servers using the same DNS name and reduces the likelihood of a user's experiencing failure in accessing sites which use that strategy.
15.4 Location(位置) 报头和欺骗 如果单个的服务器支持互不信任的多个组织,那么它必须(MUST)检查在自称的某个组织控制下产生的应答信息中Location和Content- Location报头的值以确认他们没有企图使他们没有权限的资源无效.	15.4 Location Headers and Spoofing If a single server supports multiple organizations that do not trust one another, then it MUST check the values of Location and Content- Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority.
15.5 内容倾向问题(Content-Disposition Issues) RFC 1806 [35],在HTTP中经常使用的Content-Disposition(见19.5.1节)报头就源于此,有许多非常认真的安全考虑. Content-Disposition并不是HTTP标准版本中的一部分,但自从它被广泛应用以来,我们正在证明它对使用者的价值和风险.详细资料见 RFC 2183 [49](对RFC 1806的升级).	15.5 Content-Disposition Issues RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details.
15.6 鉴定证书和空闲的客户机 现有的HTTP客户机和用户代理有代表性地不确定地保留鉴定信息.HTTP/1.1没有提供一个从服务器到直接的客户机的方法来丢弃这些保存在高速缓存里 的证书.这是一个重大的需要对HTTP做进一步扩展的的缺点.在高速缓存里的证书可能干扰应用程序的安全模式的情况包括但不只限于: --客户机已经空闲了很长时间,然后服务器可能希望引起客户机再一次出示用户的证书. --应用程序包括了一个进程中断的指令(例如在一页上有"logout"或者"commit"的按钮),在此之后应用程序的服务器方面"知道"客户机没有 进一步的理由保留证书. 这是当前分散考虑的情况下.这个问题的各部分有许多的工作区,我们鼓励在屏保程序中使用密码保护,空闲暂停,以及其它在这个问题中减轻固有安全问题的方 法.特别的,在高速缓存中保存证书的用户代理被鼓励提供一个在用户控制下丢弃保存在高速缓存中的证书的可以容易访问的机制.	15.6 Authentication Credentials and Idle Clients Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further extensions to HTTP. Circumstances under which credential caching can interfere with the application's security model include but are not limited to: - Clients which have been idle for an extended period following which the server might wish to cause the client to reprompt the user for credentials. - Applications which include a session termination indication (such as a `logout' or `commit' button on a page) after which the server side of the application `knows' that there is no further reason for the client to retain the credentials. This is currently under separate study. There are a number of work- arounds to parts of this problem, and we encourage the use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.
15.7 代理服务器和高速缓存 HTTP代理是中间人,并且扮演一个"中间者"攻击的目标.代理运行系统的妥协可能导致严重的安全和保密问题.代理有权访问与安全相关的信息,关于个人用 户和组织的私人信息,属于用户和内容提供者的所有权信息.一个不安全的代理,或者一个使用或配置没有注意安全和保密考虑 的代理,可能被用作广泛的潜在攻击的代理. 代理服务器的管理员应当保护代理服务器上运行的系统就像他们保护包括或者传递敏感信息的任何系统一样.特别的,在代理上聚集的日志信息经常包括高度敏感的 个人信息,和/或者关于组织的信息.日志信息应该被小心地保护,并且对发展的和接下来的使用持适当的指导方针.(15.1.1节) 高速缓存代理给其它潜在的攻击提供了机会,因为高速缓存的内容对于恶意利用是一个有吸引力的目标.因为当一个HTTP请求完成以后高速缓存的内容仍然存 在,对高速缓存的攻击能揭示很早以前用户就认为已经从网络上移走的信息.因此,高速缓存的内容应该当作敏感信息保护. 代理服务器的设计者应当考虑他们的设计和编码的制定,以及他们提供给代理服务器操作人员的配置选项(尤其是缺省配置)所牵涉到的保密和安全问题. 代理服务器的用户必须明白他们并不比管理代理服务器的人更值得信任;HTTP自己不能解决这个问题. 在适当的时候明智的使用密码系统可以提供足够的保护免遭广泛的针对安全和保密的攻击.这种密码系统超出了HTTP/1.1规范的范围.	15.7 Proxies and Caching By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise of the systems on which the proxies run can result in serious security and privacy problems. Proxies have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers. A compromised proxy, or a proxy implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks. Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information, and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use developed and followed. (Section 15.1.1). Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents should be protected as sensitive information. Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the configuration options they provide to proxy operators (especially the default configuration). Users of a proxy need to be aware that they are no trustworthier than the people who run the proxy; HTTP itself cannot solve this problem. The judicious use of cryptography, when appropriate, may suffice to protect against a broad range of security and privacy attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.
15.7.1 对代理服务器的拒绝服务攻击 它们是存在的.它们很难防御.研究在继续.当心.	15.7.1 Denial of Service Attacks on Proxies They exist. They are hard to defend against. Research continues. Beware.