tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
From: Ingo Schwarze <schwarze@usta.de>
To: "Anthony J. Bentley" <anthony@anjbe.name>
Cc: tech@mandoc.bsd.lv
Subject: Re: Content-Security-Policy for man.cgi
Date: Sun, 10 Nov 2019 18:47:55 +0100	[thread overview]
Message-ID: <20191110174755.GA11024@athene.usta.de> (raw)
In-Reply-To: <74937-1573390969.518612@LNmC.KNpy.68m_>

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:
> "<link rel=stylesheet href=http://some.other.example.com/...>").

Oh, <link>...  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

  reply	other threads:[~2019-11-10 17:47 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
2019-11-10 17:47     ` Ingo Schwarze [this message]
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=20191110174755.GA11024@athene.usta.de \
    --to=schwarze@usta.de \
    --cc=anthony@anjbe.name \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).