From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mike Gerwitz Newsgroups: gmane.lisp.guile.user Subject: Re: mailmam, web bridge, forum, p2p Date: Sat, 26 Oct 2019 00:31:34 -0400 Message-ID: <87y2x83z6h.fsf@gnu.org> References: <20191023064813.6igo2qi2cwtcz5bz@pelzflorian.localdomain> <20191023113724.bf055453852ec206af8d7bef@gmail.com> <20191023112544.5s65wrzbexnlsj22@pelzflorian.localdomain> <20191023123343.wanooc44orpyo7tk@pelzflorian.localdomain> <20191024123023.rvedpc5uqrm5ku6v@pelzflorian.localdomain> <20191025060845.iu7cr5bwcjdsprhn@pelzflorian.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="106799"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Guile User To: "pelzflorian \(Florian Pelz\)" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Oct 26 06:32:30 2019 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iODkb-000RfN-Pk for guile-user@m.gmane.org; Sat, 26 Oct 2019 06:32:29 +0200 Original-Received: from localhost ([::1]:38228 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iODka-0002rl-DK for guile-user@m.gmane.org; Sat, 26 Oct 2019 00:32:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37861) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iODk3-0002aI-DC for guile-user@gnu.org; Sat, 26 Oct 2019 00:31:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36514) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iODk1-0000eN-PM; Sat, 26 Oct 2019 00:31:53 -0400 Original-Received: from localhost ([::1]:33284 helo=mikegerwitz-pc.gerwitz.local) by fencepost.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1iODk0-0005ta-SV; Sat, 26 Oct 2019 00:31:53 -0400 OpenPGP: id=D6E9B930028A6C38F43B2388FEF635745E6F6D05 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:15842 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. >>=20 >> 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. >>=20 > > 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. >>=20 > > I read Amirouche=E2=80=99s owasp link which describes checking the referer > only as an additional =E2=80=9CDefense in Depth=E2=80=9D 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. =2D-=20 Mike Gerwitz --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJds8wmAAoJEIyRe39dxRuiozQP/2S0S2JseXULKTgN1T/5zR9w JA9m18VPnetWHPf9pkBunOxIhepF5aAolseKzs3HfJI8nn1JGjVPvhyotcWVko1S w5YFXhYysRNgIQBMkQHmTI0h9FYOl5O/mlakQzkKD7fu6mFP0MLXjpH+DBSod2eH 4RDJSCtNC+V1Lz5flfTuF7AEjjCTc1TV9F7wM51zY/SkwJLr2WP2NO1rsgzu8Teo bIFBFx1y6hqeV6NTVmdLGYvkmGPQGatGn5s13S+azxQuAeLVf5PRUEsgkjh9S+k/ GJU3XCy4xKqECca90gmGt/UIJUHhJMylKu4o3eYOfVyaJC4O4xVDqXGzJUOwRka0 UUHsWdJAlWDjzzjd25A5dbnW+gBecEtDQXfsnuSy0GhM7w6Ur6Mx7gGedKFwrMAq x6CsBFHaCAXuM4BZJ00i+cHqNHDmUiCj7kzDbIzupsbgMOnQyzV8wGOcNsLpEnci gsyUFV9wnZTc8d6LdpFo4L/pnVFaAmJrJ1RzR7Pcjk76V/wWvMQbCggjt06ZF5Ux uifhhmvs0AobOpCOXvJ0Js8eZlG3bUkCp0YDNUF/T3/D+cCNjbpsG3ey7ctmC5sI iNcOTMbcMPgP5OdOBMDANIArBkENll1UJtczg7S07QlMhBDRlnQfuWx7ya9Vl+tG aiEAuXpypEc/QOtk3Fac =HTKs -----END PGP SIGNATURE----- --=-=-=--