On Fri, Oct 25, 2019 at 08:08:45 +0200, pelzflorian (Florian Pelz) wrote:
> On Thu, Oct 24, 2019 at 09:39:04PM -0400, Mike Gerwitz wrote:
>> 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.
>> 
>
> So you would use both a cookie to retain login state and then only for
> sensitive requests additionally use nonces to prevent CSRF.  Would you
> use POST for all (sensitive) requests after login?

GET requests are supposed to retrieve information, not modify it, and
should be indempotent.  Since they should have no meaningful
side-effects, CSRF shouldn't have any meaningful action to
exploit.  Whether or not that's true in practice of course depends on
how the site was developed.  If a GET request does have some meaningful
side-effect (e.g. maybe it logs the action and that event can influence
some other part of the system), then it may need to be mitigated by
including a nonce.

GET requests shouldn't contain sensitive data because they will appear
in browser history; server logs; referral headers; etc.

> I had not even thought of SSO.  Do we want that?  Can we hope for
> using that?

I don't know, in the context of Guile; I haven't fully followed the
conversation; you just happened to say something that I wanted to chime
in on. :)  I was providing a general example in my experience as a
professional web developer.  There are other reasons as well.

>> 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.
>> 
>
> I read Amirouche’s owasp link which describes checking the referer
> only as an additional “Defense in Depth” security measure in the hope
> of preventing what it calls login CSRF, i.e. giving someone a login
> from someone else without them noticing (if I understand correctly).
> A cookie would prevent that anyway, I suppose.

It's a potentially valid defense-in-depth strategy, but isn't sufficient
on its own.  I personally don't see much value in it.  If a
properly-implemented nonce-based mitigation strategy fails, then the
attacker is likely in a situation where the referrer is no longer a
barrier (e.g. they have access to the page and can inject scripts or
just hijack the session).  Mitigating session hijacking is extremely
difficult in this scenario---you can't perform IP-based checks because
users often change IPs (e.g. on mobile networks, VPN, Tor, etc).  You
can't rely on any information sent by the client because it can be
spoofed by the attacker.

-- 
Mike Gerwitz