security: posting to unprepared resources

[chrysn]

the 20160926 version does acknowledge that having a server tell one where to post to does pose a security risk in the loopback note in 3.2, but does refer to that in the security considerations section.

furthermore, it is my impression that the loopback criterion is insufficient: resources exclusively protected by origin policies could be present anywhere inside a link-local, vpn or firewalled network. have other means of protection been explored? first thing that comes to my mind would be a pre-flight OPTIONS that checks for an "i'm an inbox" indicator, especially given that for anything but application/ld+json payload, such a pre-flight request is mandatory anyway.

[cwebber]

Handling the "protecting things behind a firewall" is definitely hard. I don't understand what the "pre-flight OPTIONS" means? Or in what way application/ld+json currently makes it mandatory. Could you clarify?

[cwebber]

Oh I see, anything that isn't application/ld+json requires OPTIONS with Accept-Post. I wasn't aware of that (or not paying attention), but I've only been looking at the json-ld side of things.

Pre-flight OPTIONS is a nice idea, though it does require a whole extra round trip for many transactions, and either doing that every time or caching it. I guess LDP seems to already require that so maybe that isn't a problem. It would be introducing a new round-trip if we were going to follow that lead in ActivityPub. Maybe it's worth it, I don't know yet.

(Note that a number of SocialWG members have expressed allergies to non-GET/POST HTTP methods, and I have a feeling that allergy may resurface here.)

[rhiaro]

I think for this attack, the attacker must know something about the internal (behind firewall) system of the user they are targeting, in order to send the right payload to the right endpoint that they know will be processed in such a way that will cause harm.

I think I can do the same thing if I publish a webform which has an action="internal thing" and persuade Bob McTarget to submit the form whilst behind his firewall, and it sends a json payload that I know will be processed in some damaging way by the "internal thing" endpoint.

I don't think LDN enables anything worse than that, at least. It sounds like it would have to be a very targeted attack, and LDN doesn't make anything new possible that wasn't already, right?

[chrysn]

fwiw, i was more thinking along the lines of CORS than form submissions (hence the pre-flight idea). admittedly, that's more about holding credentials than being local.

[sandhawke]

@chrysn can you sketch out what the actual attack would look like? I'm not seeing anything beyond what @rhiaro is saying, which doesn't seem worth worrying about (since it's the same vulnerability every browser has, by design).

[chrysn]

if the scenario described by @rhiaro is acceptable, and as long as no credentials are involved, i think that the only thing that remains to be considered is that the loopback exceptions should be mentioned in the security issues section, maybe along with a note on why they are sufficient (a la "The possibility that an attacker could send POSTs to unprotected non-LDN resources in the local network has been considered, but such setups are already prone to form submissions from browsers").

[rhiaro]

So the Security Considerations section is non-normative guidance, and the loopback part is a normative requirement. I've added a note to the top of the non-normative section to point this out. Does that help?

[rhiaro]

Closing, but if you feel this needs further discussion, please go ahead and re-open!