On 17 Jan 2020, at 03:58, Benjamin Kaduk <ka...@mit.edu> wrote: > > On Thu, Jan 16, 2020 at 04:31:30PM +0000, Neil Madden wrote: >> The mitigations of 10.4.1 are related, but the section heading is about >> (D)DoS attacks. I think this heading needs to be reworded to apply to SSRF >> attacks too or else add another section with similar mitigations. >> >> Mitigation (a) is a bit vague as to what an "unexpected location" is. >> Perhaps specific wording that it should be a URI that has been >> pre-registered for the client (and validated at that time) or is otherwise >> known to be safe (e.g., is a URI scheme controlled by the AS itself as with >> PAR). > > pedantic nit: "URI scheme" is probably not what we want, as the authority > component of the URI (per RFC 3986) seems more likely to match "controlled > by the AS itself"
Well that's what actually I wanted to prevent. The authority component may refer to services *owned by* the AS (e.g. related microservices) but the authority component of a URI is not under the control of the AS - anybody can put whatever they like in there either from guessing likely hostnames or looking them up in things like certificate transparency logs. Compare that to something like x-request-id:<random-uuid> where the AS has complete control over the address space. As Nat requested, I'll try and come up with some wording in a pull request that captures the issue in a more general way. -- Neil _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
