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