Ok, a few more tweaks on PaceSecurityConsiderations, Most importantly,
expanding the discussion of Replay and Spoofing attacks.
#pragma section-numbers off
== Abstract ==
For Draft-09...
The spec's current Security Considerations are lacking in detail and scope.
== Status ==
In Progress. '''Updated'''
== Rationale ==
The spec's current Security Considerations are lacking in detail and scope
== Proposal ==
{{{
12. Security Considerations
12.1 Authentication
Implementors are advised to use client authentication mechanisms to
prevent posting or editing by unknown or unauthorized sources. The type
of authentication used is a local decision made by the server.
Accordingly, clients are likely to face authentication schemes that vary
across implementations.
It is suggested but not required that servers utilizing authentication
mechanisms involving the clear-text transmission of a password (e.g.
HTTP Basic Authentication) secure the connection using, for example, a
Transport Layer Security (TLS) connection.
Because this protocol uses HTTP response status codes as the primary
means of reporting the result of a request, servers are advised to
respond to unauthorized or unauthenticated requests using an appropriate
4xx HTTP response code (e.g. 401 "Unauthorized" or 403 "Forbidden").
12.2 Denial of Service
Atom Publishing server implementations are susceptible to various forms
of denial of service attacks. For instance, a malicious client could
attack a server by posting extremely large resources, by rapidly
submitting multiple, illegitimate creation or modification requests to a
collection or entry, or by making multiple pipelined requests on
multiple connections.
12.3 Replay Attacks
Atom Publishing server implementations are susceptible to replay
attacks. Specifically,this specification does not define a means of
detecting duplicate requests. Accidentally sent duplicate requests are
indistinguishable from intentional and malicious replay attacks.
12.4 Spoofing Attacks
Atom Publishing implementations are susceptible to a variety of spoofing
attacks.
For instance, a malicious client could POST an entry to a collection
fraudulently using some other individuals name, email address and URI in
the atom:author element. To prevent such an attack, servers could
consider verifying, augmenting and possibly overriding the content of a
POSTed entries atom:author element. For instance, the atom:author could
be extended to specify the IP address from which the request originated,
or the authenticated identity of the individual that sent the request.
Additionally, collections that choose to accept the value of a newly
POSTed entries atom:id element without modification, and which allow
multiple members within the collection to share identical atom:id
values, are at risk of falling victim to the type of spoofing attack
described in section 8.4 of [RFC4287]. Specifically, Atom processors
could suppress display of duplicate entries by displaying only one entry
from a set of entries with identical atom:id values.
12.5 Privacy Concerns and Access Control
Because collections might be editable by multiple clients, privacy
concerns could arise when clients are granted full read and edit access
to all of a collections member entries and metadata. To reduce the risk
of inadvertent release or modification of private information via
collection feeds, entry documents and linked media resources, servers
are encouraged to utilize access control mechanisms that limit a clients
ability to read and edit the metadata associated with a collection and
it's member resources. This specification does not define a means of
controlling the access to a collection or it's member resources.
12.6 XML External Entities and Links within Atom document
Atom Feed and Entry documents can contain XML External Entities as
defined in section 4.2.2 of [REC-XML]. Atom implementations are not
required to load external entities. However, implementations that choose
to support external entities within Atom documents need to be aware of
the risks inherent in doing so. Specifically, external entities are
subject to all of the same security concerns as HTTP GET operations and
run the risk of signficantly altering the semantics of the Atom document.
Likewise, servers should consider resources linked to by atom:link and
atom:content elements as being inherently untrustworthy and subject to
all of the same security risks as HTTP GET operations.
12.7 Digital Signatures and Encryption
Atom Entry Documents sent to a server might contain XML Digital
Signatures [W3C.REC-xmldsig-core-20020212] and might be encrypted using
XML Encryption [W3C.REC-xmlenc-core-20021210] as specified in section 5
of [RFC4287].
A server receiving an entry containing an XML Digital Signature is not
required to preserve the integrity of that signature. That is, the
server may modify the entry in such a way that the signature is broken
or it may choose to remove the signature from the entry. The server can
choose to add its own XML Digital Signature to the entry.
12.8. Unsafe Media Posts
Server implementations that allow clients to post non-Atom resources to
a collection to create media-link entries need to be aware of the
potential threat of allowing clients to send arbitrary and inherently
unsafe resource representations. For example, a collection that allows
executable binary or script resources to be posted could be used by an
attacker to distribute a virus to subscribers of that collection's Atom
feed. To reduce the likelihood of such attacks, implementions are
encouraged to enforce limits on the types of media resources that can be
posted to a collection.
12.9. URIs and IRIs
Atom Publishing Protocol implementations handle URIs and IRIs. See
Section 7 of [RFC3986] and Section 8 of [RFC3987].
}}}
== Impacts ==
== Notes ==
Some portions inspired/copied from http://www.ietf.org/rfc/rfc2518.txt
(WebDAV)
----
CategoryProposals
