#pragma section-numbers off
== Abstract ==
The spec's current Security Considerations are lacking in detail and
scope. This begins to fill in some details but is (like
PaceMediaEntries) intended to be iterative as opposed to being a
completed proposal.
== Status ==
In Progress
== Rationale ==
The spec's current Security Considerations are lacking in detail and scope
== Proposal ==
{{{
14. Security Considerations
14.1 Authentication
Implementations SHOULD 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
multiple implementations.
Servers utilizing authentication MUST reject unauthorized or
unauthenticated requests using the HTTP 401 "Unauthorized" response
message. Per [RFC2616], 401 Unauthorized responses MUST include a
WWW-Authenticate header identifying the authentication scheme that is to
be used.
Servers utilizing authentication mechanisms that involve the clear-text
transmission of a password (e.g. HTTP Basic Authentication) MUST secure
the connection using, for example, a Transport Layer Security (TLS)
connection.
14.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 files, by rapidly submitting
multiple, illegitimate creation or modification requests to a collection
or entry, or by making multiple pipelined requests on multiple connections.
14.3 Privacy Concerns
Because collections may be editable by multiple clients, privacy
concerns may 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.
14.4 XML External Entities and Links within Atom document
Atom Feed and Entry documents MAY utilize XML External Entities as
defined in section 4.2.2 of [REC-XML]. However, because the Atom
Syndication Format does not require DTD validation, Atom implementations
are not required to support external entities. 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.
14.5 Digital Signatures and Encryption
When a client sends an XML Encrypted Atom entry document to a server
using either a POST or PUT HTTP request, and the Content-Type header of
the HTTP request message specifies the "application/atom+xml"
media-type, the server SHOULD treat the request the same as it would
treat a non-encrypted Atom entry document, assuming that it is capable
of decrypting the entry. If, however, the Content-Type header of the
request specifies any other media-type (e.g. "application/xml"), the
server SHOULD treat the request as it would any other form of media post
(e.g. by creating a media-link entry that references the XML Encrypted
resource).
A server receiving an atom:entry that contains 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 original
signature included with the POST is broken or it may choose to remove
the signature from the entry. The server MAY choose to add its own XML
Digital Signature to the entry.
14.6. 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 media-types. For example, a collection allowing any arbitrary
media-type 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 should enforce limits on the
types of media resources that may be posted to a collection.
}}}
== Impacts ==
== Notes ==
----
CategoryProposals
