Re: mailmam, web bridge, forum, p2p

[Mike Gerwitz <mtg@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2237 bytes --]

On Thu, Oct 24, 2019 at 14:30:23 +0200, pelzflorian (Florian Pelz) wrote:
> Ordinary HTTP cookies are bad practice for session tokens because of
> CSRF.  If you want a normal link to another page on your site but
> retain the login session, you should not use cookies for that.
> Session tokens must therefore be supplied in HTTP parameters (GET or
> POST).  So when a logged in user makes a request, all hyperlinks in
> the HTML response (except logout) need to have their HTML code
> rewritten by the dynamic web server to contain the session token in
> the GET parameters.  Similarly, all POST forms should contain the
> session token as a parameter value.  Thus the session token is only
> supplied in GET or POST requests from the same site and same session
> and no CSRF is possible anymore.  Since the URL used in a GET request
> will be exposed to the user, the session token should be invalidated
> after verification and the response should contain a new session token
> in its HTML code for hyperlinks and forms.  The downside is that URLs
> are less pretty but meh…

CSRF mitigation and session tokens are separate concerns.  You can mix
them, but that leads to complexity.  The typical mitigation is to just
to use nonces for sensitive requests (e.g. place the nonce in a hidden
form field to be posted with the form itself).  If you're using nonces,
there's nothing wrong with cookies.

Passing session tokens via GET requests is a bad idea, because that
leaks the token.  You can change the session token after every single
request, but that leads to a host of other issues: you can't have
multiple tabs open to the same site, you have to deal with synchronizing
the new token potentially across multiple systems which complicates load
balancing and SSO, etc.

Checking the referrer isn't a good security measure.  For example, if
the legitimate referrer were vulnerable to XSS, open redirects, or a
host of other vulnerabilities, then an attacker could circumvent it by
having the CSRF attack originate from that website.

-- 
Mike Gerwitz
Free Software Hacker+Activist | GNU Maintainer & Volunteer
GPG: D6E9 B930 028A 6C38 F43B  2388 FEF6 3574 5E6F 6D05
https://mikegerwitz.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]