From: "Anthony J. Bentley" <anthony@anjbe.name> To: Ingo Schwarze <schwarze@usta.de> Cc: tech@mandoc.bsd.lv Subject: Re: Content-Security-Policy for man.cgi Date: Sun, 10 Nov 2019 06:02:49 -0700 [thread overview] Message-ID: <74937-1573390969.518612@LNmC.KNpy.68m_> (raw) In-Reply-To: <20191110102234.GC53073@athene.usta.de> Hi Ingo, Ingo Schwarze writes: > I tried to read the standard https://www.w3.org/TR/CSP/ > but miserably failed to understand anything because there > is so much indirection: "to do what <other standard> defines > in section 1.17.42.0 to the objects <yet another standard> > defines in section 4.3.2.1, use the methods described in > <some fourth standard> in section 36932451927, but only unless > the conditions explained in sections 666.0b and <aaah!> > apply." And when you follow the pointers, you only find > more indirections to yet more places... :-[ Hm, I guess I'm just used to reading W3C standards at this point. > Do you know a place where that stuff is explained in a more > accessible reference-manual style? https://content-security-policy.com/ perhaps? > > 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: "<link rel=stylesheet href=http://some.other.example.com/...>"). > > and inline CSS; > > 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. > > 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: > > mdoc_html.c, mdoc_it_pre(), LIST_tag, ROFFT_BODY: > print_otag(h, TAG_DD, "s", "width", "auto"); > <dd style="width: auto"> > > mdoc_html.c, mdoc_fn_pre(): > print_otag(h, TAG_VAR, "cs", "Fa", "white-space", "nowrap"); > <var class=Fa" style="white-space: nowrap"> > > tbl_html.c, html_tblopen(): > h->tblt = print_otag(h, TAG_TABLE, "c?ss", "tbl", ... > <tbl class="tbl" border=1 > style="border-style: solid; border-top-style: double"> > > tbl_html.c, print_tbl(): > print_otag(h, TAG_TR, "ss", > "border-left-style", lborder, > "border-bottom-style", bborder); > <tr style="border-left-style: solid; border-bottom-style: double"> > > tbl_html.c, print_tbl(): > print_otag(h, TAG_TD, "??sss", ... > <td colspan=3 rowspan=2 style="vertical-align: top; text-align; > center; border-right-style: solid"> 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 the semicolon in "'self';\r\n" isn't needed, right? It isn't needed. > 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). You'll notice that in the log you linked, images are blocked because they're from cvsweb.bsd.lv, not mandoc.bsd.lv, and don't count as 'self'. -- Anthony J. Bentley -- To unsubscribe send an email to tech+unsubscribe@mandoc.bsd.lv
next prev parent reply other threads:[~2019-11-10 13:02 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-10 8:59 Anthony J. Bentley 2019-11-10 10:22 ` Ingo Schwarze 2019-11-10 13:02 ` Anthony J. Bentley [this message] 2019-11-10 17:47 ` Ingo Schwarze 2019-11-10 20:09 ` Anthony J. Bentley 2019-11-10 20:57 ` Ingo Schwarze
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=74937-1573390969.518612@LNmC.KNpy.68m_ \ --to=anthony@anjbe.name \ --cc=schwarze@usta.de \ --cc=tech@mandoc.bsd.lv \ --subject='Re: Content-Security-Policy for man.cgi' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).