Re: mailmam, web bridge, forum, p2p

["pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de>]

On Sat, Oct 26, 2019 at 12:31:34AM -0400, Mike Gerwitz wrote:
> On Fri, Oct 25, 2019 at 08:08:45 +0200, pelzflorian (Florian Pelz) wrote:
> > 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.

You are right.  That makes sense.  We need not abstain from cookies
and with cookies we can have GET requests retain session state and
then for anything sensitive use a nonce, whether GET or POST,
i.e. write code for links to include a nonce and verify nonces.
Thank you!



> 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.
> 

Probably for a mailing list interface, there should not be such a log annyway.
We will have to remember session cookies are fine, so we can have all
the nice things like multiple tabs, but making a sensitive request
means using a nonce



> >> 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.
>

As I understand it, checking the referer should defend against the
attacker sending a user a link where the user is logged in as someone
else.  Cookies prevent that anyway, so if we avoid XSS (which is easy
in Scheme’s SHTML) and do not let others host web workers on the same
domain and such things, no further measures are needed, I think.  In
particular, IP checking would not be needed, but I will think about
that again once I actually have studied Artanis.

Regards,
Florian