[benmmurphy]

I think if you are checking the host header on the server there is no problem. But I think if you are not checking the host header then there are some cute DNS rebinding attacks that will let an evil website perform arbitrary actions on behalf of a user if they are tricked into navigating onto the evil website. i've seen this same attack on sites hosted locally where authentication is assumed because only the localhost can connect to the site. DNS rebinding breaks this assumption. i think there is a similar thing going on here.

the good thing is a lot of stuff kind of implicitly checks the host header. like if you are using vhosting (without a default) then you have an implicit host header check even if you didn't set it up explicitly for security.

EDIT: and of course if you are using HTTPS then it should not be an issue because the server will not be able to serve a certificate that matches the hostname.

[iancarroll]

It’s good to protect against DNS rebinding, and the host header or TLS will protect against this, but rebinding isn’t the main source of CSRF issues. You can still blindly perform CSRF attacks via XHR or <form>.

The disadvantage to Tailscale’s implicit authentication is that it can’t take advantage of modern features like SameSite cookies, which can be a strong defense against CSRF. You would need to implement CSRF tokens everywhere, or try to rely on Origin/Referer (which is sketchy).

[benmmurphy]

Blind CSRF should be protected at the application level by CSRF tokens. I don’t think I can come up with a situation where using tail scale auth + CSRF tokens puts you in a worse situation than just using CSRF tokens. Obviously, if you don’t use CSRF tokens you have a problem but you have a problem even if you don’t use this tailscale auth.