From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by mandoc.bsd.lv (OpenSMTPD) with ESMTP id 716157be for ; Sun, 10 Nov 2019 12:47:58 -0500 (EST) Received: from hekate.asta.kit.edu ([141.3.145.153] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1iTrJc-0001mH-CU; Sun, 10 Nov 2019 18:47:57 +0100 Received: from donnerwolke.asta.kit.edu ([141.3.145.61] helo=donnerwolke.usta.de) by hekate.usta.de with esmtp (Exim 4.92.2) (envelope-from ) id 1iTrJc-0001jc-19; Sun, 10 Nov 2019 18:47:56 +0100 Received: from athene.asta.kit.edu ([141.3.145.60] helo=athene.usta.de) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1iTrJb-0004WE-U6; Sun, 10 Nov 2019 18:47:55 +0100 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 32cf76d5; Sun, 10 Nov 2019 18:47:55 +0100 (CET) Date: Sun, 10 Nov 2019 18:47:55 +0100 From: Ingo Schwarze To: "Anthony J. Bentley" Cc: tech@mandoc.bsd.lv Subject: Re: Content-Security-Policy for man.cgi Message-ID: <20191110174755.GA11024@athene.usta.de> References: <37020-1573376361.432557@hhtH.9ww_.rVWG> <20191110102234.GC53073@athene.usta.de> <74937-1573390969.518612@LNmC.KNpy.68m_> X-Mailinglist: mandoc-tech Reply-To: tech@mandoc.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74937-1573390969.518612@LNmC.KNpy.68m_> User-Agent: Mutt/1.12.2 (2019-09-21) Hi Anthony, Anthony J. Bentley wrote on Sun, Nov 10, 2019 at 06:02:49AM -0700: > Ingo Schwarze writes: >> Do you know a place where that stuff is explained in a more >> accessible reference-manual style? > https://content-security-policy.com/ perhaps? Thanks, i think now i have a partial understanding of what it does. >>> Since man.openbsd.org hosts manuals from many sources, and there's >>> always danger of a bug in mandoc that allows dangerous HTML content >>> through, a policy of "default-src 'none'; style-src 'self'" would be >>> appropriate: this allows external stylesheets loaded from a URL on >>> the same domain, but prohibits external links >> You mean, prohibits embedding content (not sure whether that is the >> correct term) from other sites? Linking *to* other sites still >> appears to be permitted... > Sorry, that was jargon. I was referring to link elements here (as in: > ""). Oh, ... I see. >> I do understand why inline CSS is bad style and can harm accessibility >> and prevent formatting that is well adapted to the currently used >> browsing device - but i fail to understand why a *security* >> policy would worry about inline CSS. Isn't "inline" by definition >> the most secure source of content conceivable? > In short, because modern CSS is so featureful that it is a vector for > XSS as much as JavaScript. I don't have any examples off the top of my > head but I'm sure that's not such an unbelievable statement. The idea didn't occur to me, but now that you say it, it does sound plausible. >>> scripts are not allowed at all. (mandoc(1) no longer generates >>> inline styles at all, right?) >> In a very small number of places, it still does: > It might be worth replacing these with stylesheet references for the > sake of having a CSP strict enough to prevent malicious inline CSS in > the manual body. But if not, we'll have to broaden the policy. Even a > broad CSS policy is better because we still completely block JavaScript. I think completely getting rid of style= isn't that hard, but i won't work too much on mandoc during a ports hackathon - so i have taken a TODO note for now (see below). >> By the way, could you check whether the CSP in >> >> https://mandoc.bsd.lv/cgi-bin/cvsweb/cvsweb.cgi?cvsroot=cvsweb#rev4.10 >> >> makes any sense? > Seems conceptually fine, though again "style-src 'self'" is strictly > better than "style-src 'unsafe-inline'" (but CVSWeb is not really > designed for that). Eventually, it might be useful to clean up that aspect of cvsweb, just like many other aspects need cleaning up. But that one seems relatively far away indeed. > You'll notice that in the log you linked, images are blocked because > they're from cvsweb.bsd.lv, not mandoc.bsd.lv, Oops. That was unintentional. Ultimately, i hope to move all of cvsweb.bsd.lv (including the running CGI) to cvsweb.bsd.lv, but that still requires some preparations. > and don't count as 'self'. Fixed with the appropriate httpd.conf(5) rules for now, thanks for the report. Yours, Ingo Log Message: ----------- want to get rid of the last style= attributes, suggested by bentley@ Modified Files: -------------- mandoc: TODO Revision Data ------------- Index: TODO =================================================================== RCS file: /home/cvs/mandoc/mandoc/TODO,v retrieving revision 1.296 retrieving revision 1.297 diff -LTODO -LTODO -u -p -r1.296 -r1.297 --- TODO +++ TODO @@ -382,6 +382,11 @@ are mere guesses, and some may be wrong. --- HTML issues -------------------------------------------------------- +- get rid of the last handful of style= attributes such that + Content-Security-Policy: can be enabled without unsafe-inline + suggested by bentley@ Nov 10, 2019 at 06:02:49AM -0700 + loc * exist * algo * size * imp ** + - .Bf at the beginning of a paragraph inserts a bogus 1ex horizontal space, see for example random(3). Introduced in http://mdocml.bsd.lv/cgi-bin/cvsweb/mdoc_html.c.diff?r1=1.91&r2=1.92 -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv