UserPreferences

PaceSecurityConsiderations


Abstract

For Draft-09...

The spec's current Security Considerations are lacking in detail and scope.

Status

Open

Rationale

The spec's current Security Considerations are lacking in detail and scope

Proposal

12. Securing the Atom Publishing Protocol

The Atom Publishing Protocol is based on HTTP. Authentication requirements for HTTP 
are covered in Section 11 of [RFC2616]. 

The use of client authentication mechanisms to prevent posting or editing by 
unknown or unauthorized clients is RECOMMENDED but not required.  When authentication 
is not used, clients and servers are vulnerable to trivial spoofing, denial of 
service and defacement attacks, however, in some contexts, this is an acceptable risk.

At a minimum, clients and servers implementations MUST be capable of using HTTP 
Basic Authentication [RFC2617] in conjunction with a TLS connection [RFC4346] as 
specified by [RFC2818].  The type of authentication actually deployed, however, 
is a local decision made by the server operator.  Accordingly, clients are likely 
to face authentication schemes that vary across server deployments. 

It is important to note that the choice of authentication mechanism actually 
deployed by a server can impact a clients ability to interoperate with that 
server. However, it is also recognized that authentication schemes do evolve 
over time and that better, more secure schemes may emerge. The minimum level 
of security referenced above (Basic Auth with TLS) is considered good practice 
for Internet applications at the time of publication of this specification and 
sufficient for establishing a baseline for interoperability. Implementers should, 
in general, investigate and use alternative mechanisms regarded as equivalently 
good or better at the time of deployment. It is RECOMMENDED that clients be 
implemented in such a way that allows new authentication schemes to be deployed 
and used.

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") in accordance with RFC 2617.

13. Security Considerations

As an HTTP-based protocol, APP is subject to the security considerations found 
in [RFC2616] Section 15.

13.1 Denial of Service

Atom Publishing server implementations need to take adequate precautions to ensure 
malicious clients cannot consume excessive server resources (CPU, memory, disk, etc).
For instance, a malicious client could POST an entry using excessively large XML entity 
references (e.g. the "billion laughs attack") or could attempt to rapidly submit 
multiple, illegitimate creation or modification requests.  Implementors can mitigate 
such issues, in part, by requiring client authentication, by enforcing quotas and throttles,
or by applying heuristics to determine whether requests are legitimate.

13.2 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.
Implementors can mitigate such issues, in part, by securing connections using TLS and by 
applying heuristics to determine whether or not a request is a duplicate of a request previously 
received.

13.3 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 or changed to reflect the authenticated identity (if any) 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. A common approach to mitigate this problem is for the server to create a new 
atom:id value for each successfully created collection member.

13.4 XML External Entities and Links within Atom documents

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.

13.5 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].  

Servers are allowed to modify received resource representations in ways that 
cause signatures covering the representation to become invalid.

13.6.  URIs and IRIs

Atom Publishing Protocol implementations handle URIs and IRIs. See Section 7 of [RFC3986] and
Section 8 of [RFC3987].

13.7.  Encoding Sensitive Information in URI's

Implementations needs to be careful about encoding sensitive information in URIs as 
discussed in [RFC2616] Section 15.1.3. For instance, a common practice in some weblog 
software packages is to incorporate a modified form of an entries title into the permanent 
URI assigned to an entry. As an alternative, implementations are encouraged to consider 
generating URIs for resources based either on unique identifiers generated independently 
of the resource content or based on contextual information external to the content of the 
resource (e.g. the date and time that the request was processed, a unique identifier 
assigned to the resource, or the value of the Segment [Slug]* request header).

* This last bit is obviously dependent on whether or not we adopt the Slug/Segment header.

Impacts

Notes

Some portions inspired/copied from http://www.ietf.org/rfc/rfc2518.txt (WebDAV) and the latest CalDav draft


CategoryProposals