diff options
Diffstat (limited to '253')
| -rw-r--r-- | 253/index.md | 73 |
1 files changed, 73 insertions, 0 deletions
diff --git a/253/index.md b/253/index.md new file mode 100644 index 0000000..02f9646 --- /dev/null +++ b/253/index.md @@ -0,0 +1,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 |