Re: [quicwg/base-drafts] Request forgery attacks (#3995)

[Martin Thomson <[e-mail]>]

@mikkelfj 
> In the issue you mention loopback but then goes on to use a local router address.
> I was thinking loopback was on the clients machine.

Yes, loopback is same host.  But local router addresses (the example was just an address from a private address range), are also potentially vulnerable.

> It is often the case that documentation servers run on localhost to display content, and some applications may be written to either directly use a browser interface, or indirectly via electron, to a locally hosted server.

Yes, but those servers rarely take instructions that have any real consequence, so they don't tend to be exploitable.  That's not uniformly true of course.

> These type of applications are generally not hardened and therefore comparatively easy to exploit. In the worst case, such applications insist on running on port 80 or some other privileged port, thereby having elevated permissions.

Privileged ports can mean that the process serving that port is privileged, yes.  But it doesn't have to mean that.  Of course, if it is, then it can potentially do a lot of harm.

> But, how does this new attack differ from a HTTP redirect from a random web server, where part of the url is designed til trigger a vulnerability?

One thing with HTTP is that we don't really protect against this sort of thing very well.  Mostly because the Internet and Web grew up together and people more or less assumed at first that this sort of thing was OK.  So we generally allow attackers to make requests over HTTP.  But it's only a subset of requests that are designated as "safe".

Later, as we realized that some of the HTTP stuff was dangerous we added CORS.  For those things we believe to be "dangerous", CORS effectively does the same thing that address validation does for QUIC: it checks whether the server is willing to accept a request using a "safe" check (an OPTIONS request which includes minimal attacker controlled content) before it makes any request with any of the "dangerous" content that might be controlled by an attacker.

Of course, we would love not to have to do CORS.  It's a horrible waste when most servers don't suffer from these problems to spend a whole round trip negotiating its use.

The CSRF paper mentioned in the pull request is the one that basically started all of this.  It's fairly accessible if you are interested in learning more.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3995#issuecomment-673381284