x-www-form-urlencoded prohibition

[Markus Demleitner]

Hi Paul, dear P3T,

On Thu, May 23, 2024 at 06:20:22AM +0000, Paul Harrison via grid wrote:
> In the recent P3T session, someone (I think Alberto Micol) pointed
> out that the proposed deprecation of x-www-form-urlencoded POSTs
> was a big change - and I agree it is probably the most disruptive
> change to protocols that is being suggested - the OpenAPI

Absolutely, and I think this is the one thing we simply cannot do
without breaking everything we have so far.  Which is something I
would *really* like to avoid.

> with this view, and clearly the time to push back against
> Javascript and JSON has long passed - so again it seems fine to
> emphasise JSON as a serialisation format going forward.

Well... I'm still using the web with javascript off by default, and
you'd be surprised how much in the sane part of the web still works
ok in that way.  This is, security-wise, a much larger deal than
CSRF.

But sure: We need to accomodate in-browser clients in some way, and
perhaps better than we do now.  Let's just see to it that that does
not make out-of-browser clients -- among which there certainly are
many, many of high scientific relevance, and which are those that
much better respect user freedoms than in-browser clients --
significantly harder to write or, for that matter, hack.  User
freedom includes being able to conjure up a few lines of tcl/tk
(picked for the simple reason that that's what the prolific DS9 still
is written in) to do interesting things if that's what the user
prefers.

> disallow the “simple” request types generated from <form> such as
> x-www-form-urlencoded  because the “pre-flight checks” are not
> performed - however, we learned above that, in the IVOA service
> context, even when the pre-flight checks are done, there is no way
> that CORS can be used to restrict where the services are invoked
> from, so there is no CSRF mitigation from that alone - additional

So... Russ, could you again specify as concretely as possible which
sorts of attacks you want to thwart and how outlawing form-posting
would mitigate them?  Based on that, I suppose we have a better
chance of working out whether something as extreme as outlawing the
basis of essentially all our protocols actually is proportional to
the reduced attack surface -- or whether perhaps the (relatively few)
services that actually use credentials worth stealing may perhaps get
away with less extreme measures while maintaining a comparable level
of protection against credential theft.

Thanks,

         Markus