1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
Title: Consider allowing cookies after a 302 redirection
Author: rodarima
Created: Tue, 20 Aug 2024 13:08:11 +0000
State: open
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](https://en.wikipedia.org/wiki/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](https://datatracker.ietf.org/doc/html/rfc6749), 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: https://github.com/mastodon/mastodon/issues/31466
|
