tech@mandoc.bsd.lv
 help / color / Atom feed
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
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

  reply index

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 \
    /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

tech@mandoc.bsd.lv

Archives are clonable: git clone --mirror http://inbox.vuxu.org/mandoc-tech

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.mandoc.tech


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git