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: Thu, 24 Oct 2019 21:39:04 -0400 Message-ID: <87a79peh8n.fsf@gnu.org> References: <-IsD5PBFie-kW2VJSYNHx00LodtSHflKNWtY2vjNVQDN126iTMsqHrdxl8zeWE8a53TzM_27wskjsrylIh4bN5jIGVNYOBC6zmE3p1RGyBg=@protonmail.com> <20191023064813.6igo2qi2cwtcz5bz@pelzflorian.localdomain> <20191023113724.bf055453852ec206af8d7bef@gmail.com> <20191023112544.5s65wrzbexnlsj22@pelzflorian.localdomain> <20191023123343.wanooc44orpyo7tk@pelzflorian.localdomain> <20191024123023.rvedpc5uqrm5ku6v@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="91876"; 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 Fri Oct 25 03:40: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 1iNoab-000Nkv-Hs for guile-user@m.gmane.org; Fri, 25 Oct 2019 03:40:29 +0200 Original-Received: from localhost ([::1]:54208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNoaa-00036s-BH for guile-user@m.gmane.org; Thu, 24 Oct 2019 21:40:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36041) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNoZo-0002ik-R6 for guile-user@gnu.org; Thu, 24 Oct 2019 21:39:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iNoZo-0008L3-Cm; Thu, 24 Oct 2019 21:39:40 -0400 Original-Received: from localhost ([::1]:54810 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 1iNoZn-0004tE-P4; Thu, 24 Oct 2019 21:39:40 -0400 In-Reply-To: <20191024123023.rvedpc5uqrm5ku6v@pelzflorian.localdomain> (pelzflorian@pelzflorian.de's message of "Thu, 24 Oct 2019 14:30:23 +0200") 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:15836 Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Oct 24, 2019 at 14:30:23 +0200, pelzflorian (Florian Pelz) wrote: > Ordinary HTTP cookies are bad practice for session tokens because of > CSRF. If you want a normal link to another page on your site but > retain the login session, you should not use cookies for that. > Session tokens must therefore be supplied in HTTP parameters (GET or > POST). So when a logged in user makes a request, all hyperlinks in > the HTML response (except logout) need to have their HTML code > rewritten by the dynamic web server to contain the session token in > the GET parameters. Similarly, all POST forms should contain the > session token as a parameter value. Thus the session token is only > supplied in GET or POST requests from the same site and same session > and no CSRF is possible anymore. Since the URL used in a GET request > will be exposed to the user, the session token should be invalidated > after verification and the response should contain a new session token > in its HTML code for hyperlinks and forms. The downside is that URLs > are less pretty but meh=E2=80=A6 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. 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. =2D-=20 Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJdslI4AAoJEIyRe39dxRuii4QP/2jVHNLQeSiN+lXTBAdsh1wH p/fQQ9ny1WytEG83H8DiE0H8NNKIVMjIBFVagQQXzSocyFL7pMNbm7rq1PYlSTuO ZvuMsjerl+g5exV7P2tZOm4Vv2gfWIr7zgF+Bmzw2TV5s6KiGbih+1n5QTe+An0s dDz81yn+sTXx6UihhAeGcLBDWfB9xJqEcb1qks/JE9HGsCmGios8s7e+GF/ikVFO 0rZ0+UFtaNvTOIrBGIrQqcD02TrwZQTVaCwMe9r2GefO+BACfMYbn/5KbG8yaP0w 8OH36QJKanFSC5CXtIWqZlTXEsL0bB/7w1Q4e6oCBCDNxc4AF0rz7vptqLgTTCiP 7eR0Q89rpynGa0nE9nfH/IX2K7fUTUTA575tlSH5WkfFwdrHJ8Ijjnz94j9e+kvi ZOujOrHdB/fT/herhBHn0nzaPVFY/dGs8XIUOpmH+Hc0OcCoOPN1GBIoXhLwSmw+ gcHriri9K9q4g2/s38W8rM8OnPBUEOPvO0qqc2xW0ujZTPhCm6nCrEEtz15JsjJm 1RRs+xenZGz8ys/Wb6TbU7Igsq16GVS766eiAXUsLnbqWwYyxLVqDu6FAPyk0pEd xUevvBGHxTiL9GwXe5GFwMZdN5mAA8xTN2NjudMlpSHUPDDCvr1nn5dSoKH6uKiM BR1HtWwmnv9k4lKXrMoE =cNEg -----END PGP SIGNATURE----- --=-=-=--