-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
