You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Harrison & Wells <ra...@gmail.com> on 2018/02/14 11:51:23 UTC
How to proceed on the CSP issue.
Sorry to disturb you.
I read the Contributing.md
<https://github.com/apache/tomcat/blob/trunk/CONTRIBUTING.md> on your
github mirror and even found the beginner issues
<https://bz.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&keywords=Beginner&keywords_type=allwords&list_id=160824&product=Tomcat%207&product=Tomcat%208&product=Tomcat%209&query_format=advanced>
.
Except there are only three of them, out of which one is already solved,
one is a case of XML validation (not a bug, technically) and one can be
solved using a filter.
<https://bz.apache.org/bugzilla/show_bug.cgi?id=58837>
So I decided I could go with the filter one but man, CSP is complex and I
don't think one could just do a general 'default-src' because even that can
be pretty tight.
So it is a bit unclear.
Thanks for reading.
I'd appreciate any help in getting started.
Re: How to proceed on the CSP issue.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Rahul,
On 2/21/18 9:55 AM, Rahul Chhabra wrote:
>
> On Sat, Feb 17, 2018 at 4:30 AM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
> Mark,
>
> On 2/14/18 7:39 AM, Mark Thomas wrote:
>>>> On 14/02/18 11:51, Harrison & Wells wrote:
>>>>> Sorry to disturb you.
>>>>
>>>> Not at all.
>>>>
>>>>> I read the Contributing.md
>>>>> <https://github.com/apache/tomcat/blob/trunk/CONTRIBUTING.md> on
>>>>> your github mirror and even found the beginner issues
>>>>> <https://bz.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status
> =ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&keywords=Beginner&keyw
> ords_type=allwords&list_id=160824&product=Tomcat%207&product=Tomcat%208&
> product=Tomcat%209&query_format=advanced>
>>>>>
>>>>>
> .
>>>>> Except there are only three of them, out of which one is already
>>>>> solved, one is a case of XML validation (not a bug, technically)
>>>>> and one can be solved using a filter.
>>>>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=58837> So I
>>>>> decided I could go with the filter one but man, CSP is complex
>>>>> and I don't think one could just do a general 'default-src'
>>>>> because even that can be pretty tight. So it is a bit unclear.
>>>>> Thanks for reading. I'd appreciate any help in getting started.
>>>>
>>>> I agree with you completely regarding the complexity of CSP. I'm
>>>> not convinced that a CSP specific filter is possible.
>
> I guess is just depends upon one's perspective and requirements. For
> our CSP, we just said "we need a sane policy like [no scripts from
> other domains]" and that applies everywhere. That can be some with a
> dead-simply Filter that just regurgitates the same CSP for every request
> .
>
> But if you want a Filter that tries to guess what the policy of a
> particular page should be, well, then you are indeed going to build a
> PHD-worthy Filter.
>
>>>> Igal's suggestion in comment #6 is probably the way to go. A
>>>> generic HTTP header filter. I'd look at httpd's mod_headers module
>>>> for inspiration for the sort of features a generic HTTP header
>>>> filter should provide.
>
> Or just use the rewrite filter Tomcat already provides, if the
> requirements are simple enough.
>
>>>> I don't think the first iteration needs to completely cover all of
>>>> the mod_headers functionality (adding headers to the response is
>>>> probably enough at this point) but having the eventual
>>>> functionality in mind will ensure that configuration parameters
>>>> (likely filter parameters in this case) are chosen appropriately.
>
> The only other thing I can think of that a CSP filter could provide
> would be the "signing" capabilities.
>
> CSP can say "it's okay to run a script as long as the hash of the
> script is #foo". That means that the script-hasher and the CSP header
> have to agree. So perhaps the Filter could maintain an LRU list of
> hashes produced elsewhere (and possible run through the Filter). I
> think this is a big rathole that ... probably nobody should bother to
> go down.
>
> One can also use a nonce. Technically, the nonce should be one-time
> use (it's called a nonce ffs!), but since you have to actually use it
> twice for it to be useful, I think it's okay for e.g. a Filter to emit
> the same nonce multiple times, for a short period of time.
> Rahul wrote:
> Obviously, *guessing *a policy is beyond mortal comprehension.
>
> We could take the value as an init parameter.
> Then whenever the filter is applied, it just puts that CSP.
> <init-parameters>
> <init-parameter>
> <name>default-src</name>
> <value>'none'</value>
> </init-parameter>
> </init-parameters>
>
> That's one way to make a CSP filter and preserve your sanity
Yes, that's basically what I had in mind. This should be able to be done
with Tomcat's RewriteValve -- configuration only and no additional code.
So I'm not entirely sure what a CSP-specific Filter/Valve could hope to
achieve.
-chris
Re: How to proceed on the CSP issue.
Posted by Rahul Chhabra <ra...@gmail.com>.
Obviously, *guessing *a policy is beyond mortal comprehension.
We could take the value as an init parameter.
Then whenever the filter is applied, it just puts that CSP.
<init-parameters>
<init-parameter>
<name>default-src</name>
<value>'none'</value>
</init-parameter>
</init-parameters>
That's one way to make a CSP filter and preserve your sanity
On Sat, Feb 17, 2018 at 4:30 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark,
>
> On 2/14/18 7:39 AM, Mark Thomas wrote:
> > On 14/02/18 11:51, Harrison & Wells wrote:
> >> Sorry to disturb you.
> >
> > Not at all.
> >
> >> I read the Contributing.md
> >> <https://github.com/apache/tomcat/blob/trunk/CONTRIBUTING.md> on
> >> your github mirror and even found the beginner issues
> >> <https://bz.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status
> =ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&keywords=Beginner&keyw
> ords_type=allwords&list_id=160824&product=Tomcat%207&product=Tomcat%208&
> product=Tomcat%209&query_format=advanced>
> >>
> >>
> .
> >> Except there are only three of them, out of which one is already
> >> solved, one is a case of XML validation (not a bug, technically)
> >> and one can be solved using a filter.
> >> <https://bz.apache.org/bugzilla/show_bug.cgi?id=58837> So I
> >> decided I could go with the filter one but man, CSP is complex
> >> and I don't think one could just do a general 'default-src'
> >> because even that can be pretty tight. So it is a bit unclear.
> >> Thanks for reading. I'd appreciate any help in getting started.
> >
> > I agree with you completely regarding the complexity of CSP. I'm
> > not convinced that a CSP specific filter is possible.
>
> I guess is just depends upon one's perspective and requirements. For
> our CSP, we just said "we need a sane policy like [no scripts from
> other domains]" and that applies everywhere. That can be some with a
> dead-simply Filter that just regurgitates the same CSP for every request
> .
>
> But if you want a Filter that tries to guess what the policy of a
> particular page should be, well, then you are indeed going to build a
> PHD-worthy Filter.
>
> > Igal's suggestion in comment #6 is probably the way to go. A
> > generic HTTP header filter. I'd look at httpd's mod_headers module
> > for inspiration for the sort of features a generic HTTP header
> > filter should provide.
>
> Or just use the rewrite filter Tomcat already provides, if the
> requirements are simple enough.
>
> > I don't think the first iteration needs to completely cover all of
> > the mod_headers functionality (adding headers to the response is
> > probably enough at this point) but having the eventual
> > functionality in mind will ensure that configuration parameters
> > (likely filter parameters in this case) are chosen appropriately.
>
> The only other thing I can think of that a CSP filter could provide
> would be the "signing" capabilities.
>
> CSP can say "it's okay to run a script as long as the hash of the
> script is #foo". That means that the script-hasher and the CSP header
> have to agree. So perhaps the Filter could maintain an LRU list of
> hashes produced elsewhere (and possible run through the Filter). I
> think this is a big rathole that ... probably nobody should bother to
> go down.
>
> One can also use a nonce. Technically, the nonce should be one-time
> use (it's called a nonce ffs!), but since you have to actually use it
> twice for it to be useful, I think it's okay for e.g. a Filter to emit
> the same nonce multiple times, for a short period of time.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqHYoEdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjK/g/9GOCZ2W7c7R0gE2YV
> lE5TN89zuPhOjkDu07yJ1xhIOR2nl7t/cHY3KNIZsXw/r0nPrIbC+/ZbZ1PeaqJR
> VVGZe4FDobEYUZH+TaDUtWuiVwHRmxqoAnFJqlPDTF2n5pa5dwjHt65C2C76g4eE
> wf2UNxxWUovlnvQCwZ6/gdb2aokkxZDqszU+nxWPhQRcUh5pgP127TWwaPHyJCf+
> T6zIqal5jQYFZV9GsW90Xv736jZDgdWM3oKOmra1dl6qjv9Ii/2bTDfVo9r25M0t
> wmoayvUBn0zBkk/IP4N254vQJ3Og1bAPKB7m6DO+4P4ElptVn1Tz81/M9Wpeg90z
> ITzT7WpX78OC8wkcguWpbKocw9cf6vxT+c+Nq5lBn/hJ5yfQ+f4/JYTIT2V1iOx/
> 7sU7dywr3CxABxPheZa/aW+scJCKhRBDncL63U1l9RJuR+nC4V8MKpVmBhcslClh
> V3AmjW+3MIDSGRFd+1e7X2ve61EQHzRnzUx/66JE7Wv+sIjMc3tiOU63lsj/6HSi
> DedbA95GIJC8hYCj+ZP29HevXq+DKBOkKfIxBsy90+unoWa3UTZ61kg53X8h8CLx
> poRBX7mXSxZuYAnEcITwvQgvKLcMMGeBFMhIt4qfGtjXMN8RZS18OMXwG5Os/rVK
> iF81wnQcC6Ste5e9c9uoaJt6GjY=
> =wBml
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: How to proceed on the CSP issue.
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 2/14/18 7:39 AM, Mark Thomas wrote:
> On 14/02/18 11:51, Harrison & Wells wrote:
>> Sorry to disturb you.
>
> Not at all.
>
>> I read the Contributing.md
>> <https://github.com/apache/tomcat/blob/trunk/CONTRIBUTING.md> on
>> your github mirror and even found the beginner issues
>> <https://bz.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status
=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&keywords=Beginner&keyw
ords_type=allwords&list_id=160824&product=Tomcat%207&product=Tomcat%208&
product=Tomcat%209&query_format=advanced>
>>
>>
.
>> Except there are only three of them, out of which one is already
>> solved, one is a case of XML validation (not a bug, technically)
>> and one can be solved using a filter.
>> <https://bz.apache.org/bugzilla/show_bug.cgi?id=58837> So I
>> decided I could go with the filter one but man, CSP is complex
>> and I don't think one could just do a general 'default-src'
>> because even that can be pretty tight. So it is a bit unclear.
>> Thanks for reading. I'd appreciate any help in getting started.
>
> I agree with you completely regarding the complexity of CSP. I'm
> not convinced that a CSP specific filter is possible.
I guess is just depends upon one's perspective and requirements. For
our CSP, we just said "we need a sane policy like [no scripts from
other domains]" and that applies everywhere. That can be some with a
dead-simply Filter that just regurgitates the same CSP for every request
.
But if you want a Filter that tries to guess what the policy of a
particular page should be, well, then you are indeed going to build a
PHD-worthy Filter.
> Igal's suggestion in comment #6 is probably the way to go. A
> generic HTTP header filter. I'd look at httpd's mod_headers module
> for inspiration for the sort of features a generic HTTP header
> filter should provide.
Or just use the rewrite filter Tomcat already provides, if the
requirements are simple enough.
> I don't think the first iteration needs to completely cover all of
> the mod_headers functionality (adding headers to the response is
> probably enough at this point) but having the eventual
> functionality in mind will ensure that configuration parameters
> (likely filter parameters in this case) are chosen appropriately.
The only other thing I can think of that a CSP filter could provide
would be the "signing" capabilities.
CSP can say "it's okay to run a script as long as the hash of the
script is #foo". That means that the script-hasher and the CSP header
have to agree. So perhaps the Filter could maintain an LRU list of
hashes produced elsewhere (and possible run through the Filter). I
think this is a big rathole that ... probably nobody should bother to
go down.
One can also use a nonce. Technically, the nonce should be one-time
use (it's called a nonce ffs!), but since you have to actually use it
twice for it to be useful, I think it's okay for e.g. a Filter to emit
the same nonce multiple times, for a short period of time.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqHYoEdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjK/g/9GOCZ2W7c7R0gE2YV
lE5TN89zuPhOjkDu07yJ1xhIOR2nl7t/cHY3KNIZsXw/r0nPrIbC+/ZbZ1PeaqJR
VVGZe4FDobEYUZH+TaDUtWuiVwHRmxqoAnFJqlPDTF2n5pa5dwjHt65C2C76g4eE
wf2UNxxWUovlnvQCwZ6/gdb2aokkxZDqszU+nxWPhQRcUh5pgP127TWwaPHyJCf+
T6zIqal5jQYFZV9GsW90Xv736jZDgdWM3oKOmra1dl6qjv9Ii/2bTDfVo9r25M0t
wmoayvUBn0zBkk/IP4N254vQJ3Og1bAPKB7m6DO+4P4ElptVn1Tz81/M9Wpeg90z
ITzT7WpX78OC8wkcguWpbKocw9cf6vxT+c+Nq5lBn/hJ5yfQ+f4/JYTIT2V1iOx/
7sU7dywr3CxABxPheZa/aW+scJCKhRBDncL63U1l9RJuR+nC4V8MKpVmBhcslClh
V3AmjW+3MIDSGRFd+1e7X2ve61EQHzRnzUx/66JE7Wv+sIjMc3tiOU63lsj/6HSi
DedbA95GIJC8hYCj+ZP29HevXq+DKBOkKfIxBsy90+unoWa3UTZ61kg53X8h8CLx
poRBX7mXSxZuYAnEcITwvQgvKLcMMGeBFMhIt4qfGtjXMN8RZS18OMXwG5Os/rVK
iF81wnQcC6Ste5e9c9uoaJt6GjY=
=wBml
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: How to proceed on the CSP issue.
Posted by Rémy Maucherat <re...@apache.org>.
On Wed, Feb 14, 2018 at 1:39 PM, Mark Thomas <ma...@apache.org> wrote:
> httpd's mod_headers module
>
> Since I did the rewrite valve then, I had a plan at some point to do it,
but it looked like quite a bit of effort for less gain (than the rewrite
valve). So no mod_headers valve, my bad :)
Rémy
Re: How to proceed on the CSP issue.
Posted by Mark Thomas <ma...@apache.org>.
On 14/02/18 11:51, Harrison & Wells wrote:
> Sorry to disturb you.
Not at all.
> I read the Contributing.md
> <https://github.com/apache/tomcat/blob/trunk/CONTRIBUTING.md> on your
> github mirror and even found the beginner issues
> <https://bz.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&keywords=Beginner&keywords_type=allwords&list_id=160824&product=Tomcat%207&product=Tomcat%208&product=Tomcat%209&query_format=advanced>
> .
> Except there are only three of them, out of which one is already solved,
> one is a case of XML validation (not a bug, technically) and one can be
> solved using a filter.
> <https://bz.apache.org/bugzilla/show_bug.cgi?id=58837>
> So I decided I could go with the filter one but man, CSP is complex and I
> don't think one could just do a general 'default-src' because even that can
> be pretty tight.
> So it is a bit unclear.
> Thanks for reading.
> I'd appreciate any help in getting started.
I agree with you completely regarding the complexity of CSP. I'm not
convinced that a CSP specific filter is possible.
Igal's suggestion in comment #6 is probably the way to go. A generic
HTTP header filter. I'd look at httpd's mod_headers module for
inspiration for the sort of features a generic HTTP header filter should
provide.
I don't think the first iteration needs to completely cover all of the
mod_headers functionality (adding headers to the response is probably
enough at this point) but having the eventual functionality in mind will
ensure that configuration parameters (likely filter parameters in this
case) are chosen appropriately.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org