Consider allowing cookies after a 302 redirection

[rodarima]

Currently Dillo only accepts cookies for the same organization that caused the
initial request.

For example, if loading a page from server foo.org causes loading another
resource from bar.org, bar.org is not allowed to set any cookie.

This is a good protection against tracking using third party
cookies.

The problem with this approach is that the OAuth mechanism used by Mastodon, and
in particular used by Brutaldon causes a single request that begins from a POST
to the brutaldon.org server to continue in a fosstodon.org server.

Therefore, the fosstodon.org server cannot store cookies and the OAuth login
doesn't work.

We could allow cookies when the whole page location is changed to another page,
not a resource. This would continue to block third party resources while
allowing OAuth to work.

It would of course only work if the fosstodon.org domain is allowed to set
cookies in cookiesrc.

The side effect of not being able to use OAuth is that users may attempt to use
other methods, like logging in directly into Brutaldon by sending the user and
pass to the brutaldon.org server. This requires trusting the Brutaldon instance,
as the OAuth mechanism never discloses the credentials with it, and has a finer
grained access control to the protected resource.

The OAuth 2.0 mechanism is described in
RFC-6749, but the specification
leaves out the usage of cookies to the implementation:

3.1. Authorization Endpoint

The authorization endpoint is used to interact with the resource
owner and obtain an authorization grant. The authorization server
MUST first verify the identity of the resource owner. The way in
which the authorization server authenticates the resource owner
(e.g., username and password login, session cookies) is beyond the
scope of this specification.

Similarly for CSRF protection:

10.12. Cross-Site Request Forgery

Cross-site request forgery (CSRF) is an exploit in which an attacker
causes the user-agent of a victim end-user to follow a malicious URI
(e.g., provided to the user-agent as a misleading link, image, or
redirection) to a trusting server (usually established via the
presence of a valid session cookie).

A CSRF attack against the client's redirection URI allows an attacker
to inject its own authorization code or access token, which can
result in the client using an access token associated with the
attacker's protected resources rather than the victim's (e.g., save
the victim's bank account information to a protected resource
controlled by the attacker).

The client MUST implement CSRF protection for its redirection URI.
This is typically accomplished by requiring any request sent to the
redirection URI endpoint to include a value that binds the request to
the user-agent's authenticated state (e.g., a hash of the session
cookie used to authenticate the user-agent). The client SHOULD
utilize the "state" request parameter to deliver this value to the
authorization server when making an authorization request.

See: mastodon/mastodon#31466