help / color / mirror / Atom feed
From: "Anthony J. Bentley" <>
To: Ingo Schwarze <>
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: <>

Hi Ingo,

Ingo Schwarze writes:
> I tried to read the standard
> but miserably failed to understand anything because there
> is so much indirection: "to do what <other standard> defines
> in section to the objects <yet another standard>
> defines in section, 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? perhaps?

> > Since 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=>").

> > 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
> 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, not, and
don't count as 'self'.

Anthony J. Bentley
 To unsubscribe send an email to

  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:

* 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_ \ \ \ \
    --subject='Re: Content-Security-Policy for man.cgi' \

* 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).