Closed matbcvo closed 1 year ago
Web eID extension is injecting JS code into our emails in Mautic software (while editing email content/template).
I assume the same problem existed with the TokenSigning extension (in case you used it before)? The hwcrypto.js JavaScript digital signing library relies on this injection technique to communicate with the extension. The library is in wide use and we unfortunately have to maintain compatibility with it for a couple of years, so we cannot disable it in the near future.
We cannot even disable this extension in the Google Chrome browser, solution would be to uninstall eID software which we do not want, because we need to sign documents too.
To activate the extension automatically, the extension is installed with the Chrome enterprise policy. To remove the policy and activate the extension enable/disable toggle button, remove the corresponding value from the SOFTWARE\Policies\Google\Chrome\ExtensionInstallForcelist
Windows registry key.
See https://github.com/web-eid/web-eid-app/blob/main/install/web-eid.wxs#L160-L162.
Note that the code is only injected if the page does not contain a script tag with the data-name="TokenSigning"
attribute as seen here, so if this attribute is added to any script tag on the corresponding page, the injection does not happen. I understand that you may not want to go this route in this particular case, but I mention it nevertheless just in case.
Another possibility is to use a userscript (with e.g. TamperMonkey, a bookmarklet etc) to remove the injected element.
Finally, I want to thank you for bringing this problem to our attention. We will consider adding an extension configuration page that would allow turning off the injection on certain domains.
I see that you have solved the issue with a Mautic plugin, case closed then!
@mrts any news about configuration page that allows to turn off the injection on certain domains? We can't recommend our clients to use userscript to remove that injected element as they do not know how to do that / what is it. We would prefer that than maintaining Mautic plugin. We have 10+ Mautic instances that our clients are using.
If I've understood the problem, Mautic composes e-mails inside an iframe. I'm guessing, because the iframe content is dynamically updated, it doesn't have an src
value.
@mrts Maybe we should consider injecting the backwards compatibility script only when window.location.href
is set to an https
address?
We are checking for secure context, but I think this also applies to an iframe which doesn't have a source and the parent frame has a secure context.
@matbcvo Could you verify if the iframe where Mautic composes the e-mails is missing the src
attribute?
@taneltm I checked page source and I could not find iframe, seems Mautic does not use that. I'll include page source where you can check it. It even contains multiple "TokenSigning" JS code.
@matbcvo I think Mautic does use iframe, but not always. I don't have much time to investigate this. A proper investigation would probably require me to set up Mautic myself.
But I did go through some of the Mautic code here: https://github.com/mautic/mautic/blob/b56d1fff268e85bee6dcc1043cd274861b7c49c7/app/bundles/CoreBundle/Assets/js/4.builder.js
Mautic.initBuilderIframe
seems to be called.Mautic.closeBuilder
is called, which calls Mautic.sendBuilderContentToTextarea
and that, depending on the Mautic.codeMode
, will eventually set the iframe content to a textarea. I think the value of the textarea is then used as the composed e-mail's HTML code.From the code it's clear that Mautic definitely uses iframes, but because I had limited time, I made quite a lot of assumptions while looking into it.
If it's not too much trouble, could you toggle the "Code mode" when composing an e-mail (I'm assuming that's an option) and see if you can find an iframe then?
Should be easy to find an iframe via DevTools: document.getElementsByTagName('iframe')
@taneltm You're right. Yes, that's "Builder", where we/our customers compose e-mails content.
By checking document.getElementsByTagName('iframe')
with DevTools Console, iframe will appear when I click on Builder button. I couldn't find iframe src
attribute. Also I ran JS code which confirmed that iframe does not have src
attribute.
document.getElementsByTagName('iframe')
HTMLCollection [iframe#builder-template-content, builder-template-content: iframe#builder-template-content]0: iframe#builder-template-content ...
var iframes = document.getElementsByTagName('iframe');
for (var i = 0; i < iframes.length; i++) {
if (iframes[i].hasAttribute('src')) {
console.log('iframe ' + i + ' has a src attribute with value:', iframes[i].getAttribute('src'));
} else {
console.log('iframe ' + i + ' does not have a src attribute.');
}
}
VM249:7 iframe 0 does not have a src attribute.
We don't know what the impact is for other websites, so this is risky. I think the safest option for solving this remains the proposed configuration page that allows to turn off the injection on certain domains. However, we don't have time for this in the near future and this will also be just a short-term investment as the injection code will be removed during 2024. @matbcvo, can you perhaps contribute the configuration page code if you feel this is important? The implementation should be not too difficult, see for example this PR that shows a consent page during installation.
@mrts I doubt there would be an impact for websites which actually need the token signing backwards compatibility in an iFrame.
The sites which need iFrame support will load the iFrame content from a URL. They might have a separate service for authentication which they wish to load inside the iFrame - I do see a point in doing that.
However building an authentication dialog inside an iFrame dynamically with JavaScript from the parent frame seems kinda silly.
That said, the fact remains that we don't know the impact... it's clear that devs do silly things all the time.
@matbcvo Have you tried opening a bug ticket on Mautic's repo? I actually don't think it's a good idea for Mautic to use the iFrame content as a source of truth when composing e-mails.
Web-eID needs to inject code onto a website for for legitimate reasons, but there could be malicious browser extensions which might inject ads, tracking scripts or malware, those would also get injected into e-mails composed by Mautic. That makes it a borderline security issue for Mautic users.
By looking at the code it doesn't seem like a trivial change, but it also doesn't seem too difficult to make Mautic use the iFrame only for displaying the preview and use the textarea/CodeMirror value as the source of truth.
Web eID extension is injecting JS code into our emails in Mautic software (while editing email content/template). This affects our email deliverability as all outgoing emails from Mautic are ending up in receiver's spam folder because of injected JS code from this extension. We cannot even disable this extension in the Google Chrome browser, solution would be to uninstall eID software which we do not want, because we need to sign documents too.
// edit: Currently we made plugin for Mautic that strips this JS code from email before being sent out, so this issue is fixed for us. I still think that this extension shouldn't inject JS everywhere.
From email body: