RefTagger and modern security headers
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' <a href="https://cdnjs.cloudflare.com">https://cdnjs.cloudflare.com</a>
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:
- 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.
- Ideally doesn't redirect through FaithLife authentication in the background, making it faster to load.
- 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!
Comments
-
Nathan said:
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.
0 -
Nathen,
Were you able to get this sorted out. I've got the same CSP issues.
Thank you!
Karl
0 -
Please disregard.
0 -
Please disregard.
0 -
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-inlinesource 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';">0 -
Hi Bradley,
Have you had time to look at this issue.
Much appreciated, blessings,
Karl
0 -
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.
0 -
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
0 -
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
0 -
Karl Shifflett said:
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 said: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!
0 -
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
0 -
Hi Mike,
Found one more issue, should be an easy fix.
I'm getting these issues from Lighthouse.
Links to cross-origin destinations are unsafeAdd `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
0 -
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
0 -
Karl Shifflett said:
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 said: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 said: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.
0 -
David,
A+ Thank you very much. Great working with you and Faithlife.
Blessings,
Karl
0 -
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
0 -
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
0 -
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
0 -
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
0 -
I didn't find `var refTagger =` in the source of your page.
Reftagger needs to be loaded as shown by the instructions at https://faithlife.com/products/reftagger. The script snippet we provide appears to be missing.
0 -
It's there. Look at the very last line in view source. The below image shows the end of the tag where the reftagger.js is loaded.
You can also view the source, search for reftagger and it will show you the SCRIPT tag that's loading it.
Chrome tools also show it loading. Call me if you want. Greatly appreciate the help.
Karl
260-504-1715
0 -
Give me a minute and I'll update the site and not minify the reftagger.js.
0 -
The site is updated to no minify reftagger.js.
You can do a view source, go to the end of the last line. Then click on the reftagger.js and it will open the JavaScript file that is not minimized.
0 -
This page has a lot of Bible references: https://bfc-in.github.io/national-statement-of-faith/
0 -
This page has many Bible references https://bfc-in.github.io/national-statement-of-faith/
Karl
0 -
This is what I'm seeing in Chrome Developer tools right now.
Assume you are seeing the same. The image is cut off because the edit only allows an image 500px width.
Blessings and thank you!
Karl
0 -
Hi Karl. I took a look at your issue and believe I can reproduce it. It appears using "const" instead of "var" for the refTagger variable causes the issue. Try changing "const refTagger" to be "var refTagger" and let me know if it starts working for you.
0 -
Victor,
Bingo!!!! Fixed. Thank you so much. Suggest adding a comment to the file that is generated for customers to not use 'const.'
If you send me your email to kdawg1406@gmail.com, I'll send you an Amazon gift card immediately.
If Faithlife does not permit this, then know your hard work and the hard work of your teammates as made my day, week, month, year.
With massive respect and gratitude,
Karl
0 -
SOLVED by Victor at Faithlife
I had changed var refTagger = to const refTagger = which broke the downstream JavaScript. Lesson learned.
Many thanks and massive gratitude for the professional technical programming skills and perseverance of the FaithLife team.
Thank you so very much,
Karl Shifflett
var refTagger = {settings: {bibleVersion: "KJV",libronixBibleVersion: "DEFAULT",addLogosLink: false,appendIconToLibLinks: false,libronixLinkIcon: "light",noSearchClassNames: ["commentList"],useTooltip: true,noSearchTagNames: ["h1", "h2", "h3", "h4", "h5", "h6"],linksOpenNewWindow: true,convertHyperlinks: false,caseInsensitive: true,tagChapters: false}};0 -
Update on CSP support in Reftagger:
We've just published a small update to Reftagger that provides a couple new options when dealing with a content security policy. These options are outlined in detail here: Using Reftagger with a Content Security Policy | Faithlife Reftagger
To summarize the three options:
1. Use a nonce. Reftagger now supports a nonce attribute in the script block. This handles the issue of the inline style block Reftagger generates. If generating a nonce is difficult or not feasible, see option 2.
2. Use the external CSS file. Reftagger now generates an optional, external CSS file that can be used instead of inline styles. This will disable the customStyle setting, so any custom styles would need to manually be translated to your own CSS classes to override the default Reftagger ones. Unfortunately the RefTagger.js and RefTagger.css files are not yet being served from a CDN. I would like to see that improvement made in the future.
3. Use unsafe-inline for inline styles. This was the only previous approach available. It's not the most desired option, but is available as a last resort.
Hopefully this is useful. These were the best changes we could make without a substantial rewrite of the plugin while retaining backwards compatibility. Reftagger was written when CSP was on few people's radar, but we'll be better able to tackle this and other suggestions if/when a new version of Reftagger is developed.
If there are any issues, let us know.
0 -
Outstanding!!! Thank you!
0 -
I used Option 2. Simple works great. See no issues at all. Thank you again.
0 -
RefTagger, a script enhancing biblical references on websites, should align with modern security practices by ensuring compatibility with Content Security Policy (CSP) headers. By prioritizing secure integration, websites can seamlessly incorporate RefTagger while maintaining robust protection against potential security threats, contributing to a safer browsing experience.
0
