On Oct 18, 2017, at 7:04 AM, Richard Hipp <d...@sqlite.org> wrote:
>
> On 10/18/17, Warren Young <war...@etr-usa.com> wrote:
>> On Oct 18, 2017, at 3:44 AM, Warren Young <war...@etr-usa.com> wrote:
>>>
>>> The more web apps that ship with stringent Content-Security-Policy
>>> headers, the fewer arguments we’ll have for allowing JS on web pages.
>
> I'd never heard of Content-Security-Policy before. A quick scan
> suggests that I need to modify Fossil to make use of it.
>
> Target policy: default-src: ‘self'
Eventually, ideally, yes.
At the moment, this might work without causing any errors:
default-src 'self’;
script-src 'self' 'unsafe-inline’;
style-src 'self' 'unsafe-inline’;
The exceptions allow all the inline style=“” attributes and <script> blocks
Fossil UI currently ships.
This would still be a big improvement over the current state, where an attacker
could possibly insert <script src=“http://evil.co/my-bad-script.js”> into a
Fossil page and cause it to be rendered. With the above CSP, the browser won’t
even try to fetch that JS.
If you have any Ajax calls back to the remote fossil executable and they ship
back <style> or <script> blocks, you may need to add ‘unsafe-eval’ as well,
though I’d recommend fixing those cases rather than allowing them via CSP,
because the risks of eval() are infinite in scope, because Turing.
I’m actually in the process of doing this myself on a web app, which is why I
said it’s early for me to be talking about this. I still don’t yet know all of
the things I don’t yet know. What I can say is that it’s a fair bit of work,
but it is worthwhile if you care to prevent XSS attacks.
> I'll have to add a "/fossil.js" resource that contains
> various scripts and insert the JSON data used to drive those scripts
> as <script type='text/json'> elements, apparently.
Precisely.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
