guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mailmam, web bridge, forum, p2p (was: Diversification)


From: pelzflorian (Florian Pelz)
Subject: Re: mailmam, web bridge, forum, p2p (was: Diversification)
Date: Fri, 25 Oct 2019 08:08:45 +0200
User-agent: NeoMutt/20180716

On Fri, Oct 25, 2019 at 07:42:41AM +0800, Nala Ginrut wrote:
> Yes, you need to login if you change IP, but the last IP keeps session.

Does checking the IP enhance security in any way?  There are some
(few) reasons IPs may change.

> BTW, encoding token in URL is bad for SEO.
> 

That is interesting, I did not think of that.  Then again, browsing
the mailing list would be possible without login, i.e. without token,
so URLs would be clean for a search engine crawler.  I do not know if
crawlers should ever have a session on other Artanis sites.


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?

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


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

Regards,
Florian



reply via email to

[Prev in Thread] Current Thread [Next in Thread]