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
