RefTagger and modern security headers

Page 1 of 2 (33 items) 1 2 Next >
This post has 32 Replies | 3 Followers

Posts 2
Nathan | Forum Activity | Posted: Tue, Mar 30 2021 1:54 PM

I'm building out a new Bible website and have successfully integrated RefTagger. I've then set about enabling a range of security headers, one of which is the Content Security Policy.

At the moment this is set up as:

script-src 'self' https://cdnjs.cloudflare.com https://reftaggercdn.global.ssl.fastly.net https://auth.faithlife.com https://biblia.com;

In this configuration, 'self' means that scripts served from the same scheme and domain are safe and will be executed. In addition, I've got some Bootstrap and JQuery scripts on Cloudflare that are safe. However, when I come to add the refTagger CDN I'm getting the main script plus then login redirects through FaithLife before actually loading the content from Biblia. This seems very chatty, I'm not really sure that the auth redirect is intended so that's the first thing to flag.

Second thing to flag is the style-src, which I've currently got set as:

style-src: 'self' https://cdnjs.cloudflare.com

This is intended to ensure styles only load from the same website or CloudFlare (Bootstrap again). As RefTagger is setting styles via script, it won't load the styles at all.

CSP is a great security feature because it ensures that if a site is compromised through XSS then it still can't be used to exfiltrate sensitive information like cookies. An attacker can't stealth-post privileged information in the browser off to another website, either directly in script or by loading CSS assets with additional GET parameters for example.

The fix is for me to use the 'unsafe-inline' directive which basically tells the browser "never mind, people can put whatever they want inline". In other words, turn this incredibly powerful security feature off.

I doubt there are currently a lot of people experiencing this issue, but I would like to request consideration of a vNext iteration of the RefTagger library that has better CSP support, specifically:

  1. Uses a single CDN domain for the refTagger script. Tagger only seems to load a first verse anyway most of the time - why not just dump every verse out in JSON onto the CDN and skip loading from Biblia at all? Might take weight off your web front ends too.
  2. Ideally doesn't redirect through FaithLife authentication in the background, making it faster to load.
  3. Pulls the styles into a separate CSS file on the same CDN, and use CSS classes in RefTagger markup.

This would be a little more flexible in terms of styling and make it compatible with CSP. Then you could recommend the right security headers, e.g:

style-src: 'self' https://cdn.faithlife.com

Again, I imagine I'm one of the first people hitting this problem but as the standards are more widely adopted it'd be great to have a version of RefTagger designed to play nicely in a wider security ecosystem.

If you also Open Source the JS side then you might even get some community contributions that add this for you!

Posts 9181
LogosEmployee
Bradley Grainger (Faithlife) | Forum Activity | Replied: Tue, Mar 30 2021 11:40 PM

Nathan:
In this configuration, 'self' means that scripts served from the same scheme and domain are safe and will be executed. In addition, I've got some Bootstrap and JQuery scripts on Cloudflare that are safe. However, when I come to add the refTagger CDN I'm getting the main script plus then login redirects through FaithLife before actually loading the content from Biblia. This seems very chatty, I'm not really sure that the auth redirect is intended so that's the first thing to flag.

This was a bug that just got shipped to the site. It's fixed now, so you should only need 'https://reftaggercdn.global.ssl.fastly.net' in your script-src, not the other two domains.

Posts 50
Karl Shifflett | Forum Activity | Replied: Sat, May 22 2021 11:09 AM

Nathen,

Were you able to get this sorted out.  I've got the same CSP issues.

Thank you!

Karl

Posts 50
Karl Shifflett | Forum Activity | Replied: Sat, May 22 2021 11:11 AM

Please disregard.

Posts 50
Karl Shifflett | Forum Activity | Replied: Sat, May 22 2021 11:20 AM

Please disregard.

Posts 50

Bradly,

I've attached a small zip file with my index.html and a small external js file that contains Reftagger's js.  CSP requires js to be loaded and not inlined as suggested by the installation instructions.

The below image shows the CSP I had to implement to get reftagger to play nice with CSP.

Notice I had to add two domains and also had to open style-src wide open, essentially bypassing all security for styles on the site.

This CPS doc https://content-security-policy.com/examples/allow-inline-style/ states "The unsafe-inline source list keyword can be used to allow inline styles, but this also removes much of the security protection that you gain when you enable CSP."

This doc on unsafe-inline basically tells developers do not use it.  https://content-security-policy.com/unsafe-inline/

I hope you can get this down to a single domain and provide a workflow for not having to open up style-src to attacks.

When I run Chrome Lighthouse I get dinged for several reasons, the biggest issue is your requests are HTTP: and not HTTPS:  See the below Lighthouse report image.  Can you fix this too?

Nathan had some well-thought-out suggestions, such as providing the styles so we could load them locally to avoid the injecting of styles.

Final question:  what is the call to log doing?  Are you tracking my users?  I need to know because our site privacy policy must call out all 3rd party interactions.

Thank you for your time and for helping us sort this out.

Best regards,

Karl

The image got cut off, here is the HTML for the CSP

<meta http-equiv="Content-Security-Policy" content="default-src 'self' http://api.reftagger.com http://reftaggercdn.global.ssl.fastly.net;           img-src 'self' http://api.reftagger.com data:;           style-src 'self' 'unsafe-inline';">

2021-05-22 14-58-10

2021-05-22 15-07-20

 
Posts 50
Karl Shifflett | Forum Activity | Replied: Wed, May 26 2021 9:59 AM

Hi Bradley,

Have you had time to look at this issue.

Much appreciated, blessings,

Karl

Posts 399
LogosEmployee

Hi Karl,

We looked into this for you today.

Regarding your issues with HTTPS and Content Security Policy, RefTagger supports https and it's preferable to always load it that way. 

In your RefTagger script, try changing this line

g.src = '//api.reftagger.com/v2/RefTagger.js';

to this

g.src = 'https://api.reftagger.com/v2/RefTagger.js';

The first way, it's using the http or https from your site. If you're loading your site as http, then the request to RefTagger tries to be http, which is bad. We'll update the snippet on our site to specifically say https:// going forward.

Regarding logging, we are not tracking anything about site visitors, just some basic analytics about how sites are using RefTagger (site urls, what Bible versions are used, number of references parsed, etc). The only way we might (inadvertantly) track something about your visitors would be if you had sensitive visitor data in the site URL.

Let me know if you have further questions.

Posts 50
Karl Shifflett | Forum Activity | Replied: Wed, May 26 2021 4:56 PM

Hi David,

Thank you for your quick response. https:// worked perfectly!  Great idea to make adjustments to the script that creates the user code.

Thank you for the information on logging, nice and clean.

Did you have time to look into the Content Security Policy and us having to open up our security to accommodate the injecting of styles?  See the last line of the policy, 'unsafe-inline'.  Without this, the tagger does not work.  This is very important to anyone using Content Security Policy.

<meta http-equiv="Content-Security-Policy" 

content="default-src 'self' https://api.reftagger.com https://reftaggercdn.global.ssl.fastly.net;           

img-src 'self' http://api.reftagger.com data:;           

style-src 'self' 'unsafe-inline';">

Thank you!  

BTW:  I've been a Logo customer since 1995.  I also met your developers when they came to Microsoft in 2008 or 2009.  I was working at Microsoft then on WPF.   

Love Logos, best Bible software.

Blessings,

Karl

 

Posts 50
Karl Shifflett | Forum Activity | Replied: Wed, May 26 2021 5:14 PM

Hi David,

Two other wrinkles.

1.  In my Content Security Policy http://reftaggercdn.global.ssl.fastly.net as http: otherwise, it does not work.

Does this support https?  

Maybe it does, but the other SCRIPTS are hardcoded to call it use HTTP.

2. When I use HTTPS I get this error in the Chrome console log:

reftagger.js:1 Refused to load the image 'http://api.reftagger.com/v2/social-icons.png' because it violates the following Content Security Policy directive: "img-src 'self' https://api.reftagger.com data:".

I don't think the scripts are properly making their calls to match the protocol it was called from.

Thoughts?

Blessings,

Karl

Posts 399
LogosEmployee
David Schwegler (Faithlife) | Forum Activity | Replied: Thu, May 27 2021 12:30 PM

Karl Shifflett:

I don't think the scripts are properly making their calls to match the protocol it was called from.

That's possible. That being said, have you tried this from a https instance (eg, in production)? I'm guessing you're testing this from a local (http) instance. When I check network requests from a production site, I only see https requests in the network tab of dev tools. So these http url issues may resolve from a https instance.

Karl Shifflett:

unsafe-inline

I believe the alternatives to unsafe-inline would be adding a hash. The problem is that if we do that, anytime we changed the reftagger code, you would have to update your website. We're concerned about the implications of breaking customer sites by doing that. 

Other than that, I don't have immediate answers. We are making an effort to modernize some aspects of RefTagger currently. I'll see if I can at least put explicit https support on our roadmap, though no promises how soon it will happen.

That's cool you mention the Microsoft visit. I was at one of those visits, so we may have met!

Posts 50
Karl Shifflett | Forum Activity | Replied: Thu, May 27 2021 1:35 PM

David,

Yes, I'm developing using http://localhost.

So you're confirming that when I go live (production) I can change all URLs in the Content Security Policy to HTTPS and also use the 'https://api.reftagger.com/v2/RefTagger.js', correct?

One possible solution to the unsafe-inline hash changing is to version the endpoint that gets this style.  Then you would break anyone since they would be pointing to the previous hash and style.

I'm not really sure what is going on with the styling, maybe there is a way to not have to do this, problem solved.

LOL - small world, possibly meeting at Microsoft and now online.

Also, in 1995, I visited the Logos HQ before I moved to Russia for a year.  They took care of me, got me all set before my move.  Back then, the Internet in Siberia was very limited;  9600 baud modems and poor phone line wiring!  So I had to install everything I needed on my computer.

Thank you for your steadfastness in sticking with this.  

How will I, and other customers get notified when you get a solution to the styles?

Blessings,

Karl

Posts 50
Karl Shifflett | Forum Activity | Replied: Thu, May 27 2021 3:03 PM

Hi Mike,

Found one more issue, should be an easy fix.

I'm getting these issues from Lighthouse.

Links to cross-origin destinations are unsafe Add `rel="noopener"` or `rel="noreferrer"` to any external links to improve performance and prevent security vulnerabilities. Learn more.

Can you please add the 'rel=noopener' to the links you dynamically add to our pages?  This will correct this issue.

Blessings,

Karl

2021-05-27 18-00-08

Posts 50
Karl Shifflett | Forum Activity | Replied: Fri, May 28 2021 5:13 PM

David,

I've got my site on HTTPS, it's working perfectly now!

The only outstanding issue is the Content Security Policy and style-src.

Greatly appreciate you all looking into this,

Blessings,

Karl

Posts 399
LogosEmployee

Karl Shifflett:

One possible solution to the unsafe-inline hash changing is to version the endpoint that gets this style.  Then you would break anyone since they would be pointing to the previous hash and style.

I'm not really sure what is going on with the styling, maybe there is a way to not have to do this, problem solved.

How will I, and other customers get notified when you get a solution to the styles?

Someone from the team should follow-up in this thread at that time, so you should recieve a notification.

Karl Shifflett:

Can you please add the 'rel=noopener' to the links you dynamically add to our pages?  This will correct this issue.

I've made a note of this.

Karl Shifflett:

David,

I've got my site on HTTPS, it's working perfectly now!

The only outstanding issue is the Content Security Policy and style-src.

Greatly appreciate you all looking into this,

Blessings,

Karl

Good to hear. Happy to help.

Posts 50
Karl Shifflett | Forum Activity | Replied: Tue, Jun 1 2021 5:46 PM

David,

A+  Thank you very much.  Great working with you and Faithlife.

Blessings,

Karl

Posts 50
Karl Shifflett | Forum Activity | Replied: Sat, Jun 5 2021 3:51 PM

Faithlife,

I'm working on a new website and can't get RefTagger to work. I tried all of the recommendations under "Why isn't RefTagger working?" and reftagger still isn't working. 

I moved the RefTagger.js to load at the bottom of the HTML document, just before the BODY tag ends.  No help.

I verified that RefTagger.js is loading, I put a breakpoint on the last line of the supplied script, the browser tools stop at the breakpoint on load, I continue but still not working.

I even tried removing the Content Security Policy, still no help.

I'm not getting any errors in the developer tools console.

Any suggestions?

What else could cause this problem.  I've never had this happen before. 

Thank you!

Karl Shifflett

Posts 50
Karl Shifflett | Forum Activity | Replied: Sat, Jun 5 2021 4:38 PM

I have verified that https://api.reftagger.com/v2/reftagger.js is loading in the browser.  But after that, no further requests are made back to Faithlife.

Thank you for any assistance.  This site is the same as my other one.  Both have the same minimal ( modernizr-custom-min.js ) JavaScript loaded.

Really not complex either.

Karl

Posts 50
Karl Shifflett | Forum Activity | Replied: Sun, Jun 6 2021 6:56 AM

I was able to load the reftagger.js directly into my browser instead of loading from https://api.reftagger.com/v2/reftagger.js

This allowed me to use the developer tools to debug while running.

The script never logs errors into the console, but, still, no Bible references are tagged.

Can you send me the un-minified version of the reftagger?  I can then load this and try and understand what is happening.

I could also upload my website so you could have a look and see why it is not tagging.

Please advise on what you recommend or need me to do.  

Thank you very much, I really don't want to launch this site publically unless RefTagger is working.

Best,

Karl

Posts 50
Karl Shifflett | Forum Activity | Replied: Mon, Jun 7 2021 1:56 AM

I have deployed my site that RefTagger is not working on to a public staging server https://bfc-in.github.io/

I can very easily swap out the RefTagger JavaScript or load from another source that you use for debugging, not sure.

Please advice.  I really can't launch this site without RefTagger.

Blessings and thank you for your time and assistance,

Karl

Page 1 of 2 (33 items) 1 2 Next > | RSS