From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "pelzflorian (Florian Pelz)" Newsgroups: gmane.lisp.guile.user Subject: Re: mailmam, web bridge, forum, p2p Date: Sat, 26 Oct 2019 11:35:06 +0200 Message-ID: <20191026093506.qbox46mcjt747pxo@pelzflorian.localdomain> 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> <87y2x83z6h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="211816"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: NeoMutt/20180716 Cc: Guile User To: Mike Gerwitz Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Oct 26 11:35:33 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 1iOITs-000sxU-GP for guile-user@m.gmane.org; Sat, 26 Oct 2019 11:35:32 +0200 Original-Received: from localhost ([::1]:39432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOITq-0005Wk-UC for guile-user@m.gmane.org; Sat, 26 Oct 2019 05:35:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55812) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOITW-0005Sy-9U for guile-user@gnu.org; Sat, 26 Oct 2019 05:35:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOITU-0007FW-SH for guile-user@gnu.org; Sat, 26 Oct 2019 05:35:10 -0400 Original-Received: from pelzflorian.de ([5.45.111.108]:35496 helo=mail.pelzflorian.de) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iOITU-0007FB-Bv; Sat, 26 Oct 2019 05:35:08 -0400 Original-Received: from pelzflorian.localdomain (unknown [5.45.111.108]) by mail.pelzflorian.de (Postfix) with ESMTPSA id ED7503604DA; Sat, 26 Oct 2019 11:35:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=pelzflorian.de; s=mail; t=1572082507; bh=mLtSDxXZxymDzVR0V2hoqHdXQ2VcBSW3KWfMb6BfkYQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=jUSXIWIALMfIM9RDeAcottrhh6+rjZZqXYzlTDYW1RvL8IaIf7Rd242Qp7TSHc3aF 9hGCggR988oZLPYR6cPNGjQFWEuRAi6HW/GwvKz0wjdKqiCX9xJZGylfIoVJMvjFVi YzMz5n+Xoh/MkxZjjW2OGUfugJPMpjL5iEMFg1xY= Content-Disposition: inline In-Reply-To: <87y2x83z6h.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 5.45.111.108 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:15847 Archived-At: 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) wrot= e: > > So you would use both a cookie to retain login state and then only fo= r > > sensitive requests additionally use nonces to prevent CSRF. Would yo= u > > use POST for all (sensitive) requests after login? >=20 > 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. >=20 Probably for a mailing list interface, there should not be such a log ann= yway. 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, i= f > >> 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 re= ferer > > only as an additional =E2=80=9CDefense in Depth=E2=80=9D security mea= sure 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. >=20 > It's a potentially valid defense-in-depth strategy, but isn't sufficien= t > 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=E2=80=99s 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