Security Considerations / RFC 2068
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 Authentication of Clients
The Basic authentication scheme is not a secure method of user
authentication, nor does it in any way protect the entity, which is
transmitted in clear text across the physical network used as the
carrier. HTTP does not prevent additional authentication schemes and
encryption mechanisms from being employed to increase security or the
addition of enhancements (such as schemes to use one-time passwords)
to Basic authentication.
The most serious flaw in Basic authentication is that it results in
the essentially clear text transmission of the user's password over
the physical network. It is this problem which Digest Authentication
attempts to address.
Because Basic authentication involves the clear text transmission of
passwords it SHOULD never be used (without enhancements) to protect
sensitive or valuable information.
A common use of Basic authentication is for identification purposes
-- requiring the user to provide a user name and password as a means
of identification, for example, for purposes of gathering accurate
usage statistics on a server. When used in this way it is tempting to
think that there is no danger in its use if illicit access to the
protected documents is not a major concern. This is only correct if
the server issues both user name and password to the users and in
particular does not allow the user to choose his or her own password.
The danger arises because naive users frequently reuse a single
password to avoid the task of maintaining multiple passwords.
If a server permits users to select their own passwords, then the
threat is not only illicit access to documents on the server but also
illicit access to the accounts of all users who have chosen to use
their account password. If users are allowed to choose their own
password that also means the server must maintain files containing
the (presumably encrypted) passwords. Many of these may be the
account passwords of users perhaps at distant sites. The owner or
administrator of such a system could conceivably incur liability if
this information is not maintained in a secure fashion.
Basic Authentication is also vulnerable to spoofing by counterfeit
servers. If a user can be led to believe that he is connecting to a
host containing information protected by basic authentication when in
fact he is connecting to a hostile server or gateway then the
attacker can request a password, store it for later use, and feign an
error. This type of attack is not possible with Digest Authentication
[32]. Server implementers SHOULD guard against the possibility of
this sort of counterfeiting by gateways or CGI scripts. In particular
it is very dangerous for a server to simply turn over a connection to
a gateway since that gateway can then use the persistent connection
mechanism to engage in multiple transactions with the client while
impersonating the original server in a way that is not detectable by
the client.
15.2 Offering a Choice of Authentication Schemes
An HTTP/1.1 server may return multiple challenges with a 401
(Authenticate) response, and each challenge may use a different
scheme. The order of the challenges returned to the user agent is in
the order that the server would prefer they be chosen. The server
should order its challenges with the "most secure" authentication
scheme first. A user agent should choose as the challenge to be made
to the user the first one that the user agent understands.
When the server offers choices of authentication schemes using the
WWW-Authenticate header, the "security" of the authentication is only
as malicious user could capture the set of challenges and try to
authenticate him/herself using the weakest of the authentication
schemes. Thus, the ordering serves more to protect the user's
credentials than the server's information.
A possible man-in-the-middle (MITM) attack would be to add a weak
authentication scheme to the set of choices, hoping that the client
will use one that exposes the user's credentials (e.g. password). For
this reason, the client should always use the strongest scheme that
it understands from the choices accepted.
An even better MITM attack would be to remove all offered choices,
and to insert a challenge that requests Basic authentication. For
this reason, user agents that are concerned about this kind of attack
could remember the strongest authentication scheme ever requested by
a server and produce a warning message that requires user
confirmation before using a weaker one. A particularly insidious way
to mount such a MITM attack would be to offer a "free" proxy caching
service to gullible users.
15.3 Abuse of Server Log Information
A server is in the position to save personal data about a user's
requests which may identify their reading patterns or subjects of
interest. This information is clearly confidential in nature and its
handling may 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.4 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 may allow the
server machine to become more vulnerable to attacks against software
that is known to contain security holes. Implementers 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 field 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 field may 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.
15.5 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.6 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 implementers be particularly careful in this area.
History shows that errors in this area are often both serious
security and/or privacy problems, and often generate highly adverse
publicity for the implementer's company.
15.7 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 it should 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 should 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.8 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. These lookups should 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, 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.9 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.