Insecure connection browser warning for banksite with mixed content.

[polonus]

The browser website has mixed content over a secure connection.
-http://www.moneyou.nl/~/media/MoneYou%20NL/Klantenservice/privacy-en-cookies-melding.png
Via a redirect of the website this becomes https, but an attacker with access to the network can scam whatever he wants. Info credits go to Erik van Straten.

So we dived into that and found a pre-loader problem at the basis of this:
This is the error we detected:

Domain is a subdomain, and can't be preloaded.
HSTS header missing the "preload" attribute.
Re: -https://observatory.mozilla.org/analyze.html?host=-www.moneyou.nl

One cannot lean back and trust symantec to keep you from harm's way,
you should properly configure some things on your own. Issue found: https://sritest.io/#report/2f28c203-af61-4630-b589-cb07150cdb321

1 vulnerable jQuery library to be retired: http://retire.insecurity.today/#!/scan/f289cd9adda31bf79156ccb64397169ffa56928ebe818b1ae0829d754bf93436
(same script as found above at with sri test issue). Detected with a great many sites where the sri hash has not been generated for this external google script.

The www sub domain is 'not public' & DNS produces a "bad zone", then see:

http://www.dnsinspect.com/moneyou.nl/10035351

Bad Request - Invalid Hostname HTTP Error 400. The request hostname is invalid. Site resolves to:
-https://www.moneyou.nl/ this after haven given in: -https://moneyou.nl.

Also re: 'unknown' here: http://toolbar.netcraft.com/site_report?url=https://www.moneyou.nl

When checked this all was found to be OK: Tracing: Pass Custom errors: Pass Stack trace: Pass HTTP to HTTPS: Pass Hash dos patch: Pass ELMAH log: Pass Excessive headers: Pass HTTP only cookies: Pass Secure cookies: Pass Clickjacking: Pass

Again the underlying problem here has been traced to be a preloader problem. Info credits: luntrus

polonus (volunteer website security analyst and website error hunter)

[polonus]

Thanks to my forum friend, Pondus, I am now aware of this: http://urlquery.net/report.php?id=1488380526837

Furthermore I have to report that that glitch was found on a IE browser with Windows7.

I do not know yet whether service pack 1 was installed there.
Support for Windows7 will be discontinued,
and service pack 2 is not likely to arrive.

User deletes all cookies on closing the browser, that may also be an explanation for that behavior.

polonus (volunteer website security analyst and website error-hunter)

[polonus]

Could well be the issue is with an inferior cookie-script. Seems the pre-loader is not being loaded intentiously.
Also see this script that is overwriting other script handlers: - http://Moneyou.nl/static/js/functions.js?v=1-4-1-0310117

polonus

[polonus]

And what is going on, codewise, here?

When we scan the following URL on that website: URL: hxtp://Moneyou.nl/static/js/functions.js?v=1-4-1-0310117
We find the following mentioned inside the code source:

/** * original by NetSociety, changed by Mirabeau to fix the fact that this script overwrites other click handlers * Depends on jQuery/$, GA (_gaq) and sitestat (ns-_onclick) functions * Initialisation moved to regular page init that already existed

Can the inferiority of the mixed cookie  script content be worsened by the changed script outcome  via the changed NetSociety script,which will overwrite that click handler?

href="/klantenservice/privacy-en-cookies" onClick="ns_onclick(this,'','click.hypotheekrenteoverzichtrentetarieven.topmenu.privacyencookies','clickin',false);return false">Privacy en cookies</a>

Anyone having an idea here?

polonus

[polonus]

From an anonymous reaction to my question above, someone commented:

When you look at the page with developer tools installed in the browser, we could sketch the following scenario when one would click  "hypotheken".

One of the actions performed comes from a third party know as: -tdn.r42tag.com. This website will serve up 1 javascript (.js) script into the browser that is not completely correct.
The javascript file is neatly being transported via https itself, but when the browser then starts to execute that js. script, it meets the following programing function: -http://www.moneyou.nl/~/media/MoneYou%20NL/Klantenservice/privacy-en-cookies-melding.png?(and some additional "blabladibla")
So: an image in http, caused by a third party script by a third party with which MoneYou is cooperating apparently. Could it be too far fetched to take this to be a complete cookiescript?

The browser then correctly turns this into https (because of HSTSheader), so it won't do any harm this time.
But the browser in the mean time may have alerted a "mixed content" error.
This is sloppy behavior. MoneYou may chase potential customers away that way, those ones that prefer rather not to meet with an alert for  "mixed content"in their browsers.
Because the average browser user cannot establish for 100% what the cause of this alert could be (benign, suspicious or malicious).
(= a warning will upset browser users). That is why we pay attention to this glitch here.

You can check whether it is in fact -tdn.r42tag.com material causing this alert by adding "tdn dot r42tag dot com" to your hosts-file, or block it through a FW rule or via an adblocker of sorts. When being blocked, you won't get the alert inside the browser.

Blocking images only however will not solve this problem for you as the script is still being "smuggled"into the browser. The browser will execute this by default, because once Firefox developers remarked that when visiting a certain website, you trusts it sort of, else you won't go there in the first place. 

Finally there are obsolete program instructions detected in the code here: -https://modules.moneyou.nl/all.min.js?7.48.0.3

Thanks anonymous for your reaction. 

Additionaly I come to add the following considerations:

From the cookies report for that third party script link domain: https://webcookies.org/cookies/tdn.r42tag.com/2125935
and where it could be less secure:

Missing: X-Frame-Options
This headers prevents the page from being displayed in FRAME or IFRAME, mitigating ClickJacking attacks and is recommended for most websites with a login form or transactional features » More... The header is not set See who sets it...
Missing: Content-Security-Policy
Allows fine-grained control over what content is allowed to be loaded on this website. It's a powerful security feature that is strongly recommended. » More... This website does not use CSP, try using CspBuilder » See who does...
Missing: X-Content-Type-Options
Disables naive file type guessing in browsers, preventing some malicous content download attacks. It should be always set on API (JSON, XML) responses and is recommended on all other responses as well

Getting content right on a website is not an easy task and sometimes we have to lift our fingers from the keyboard turning second glance into the code used.

polonus (volunteer website security analyst and website error-hunter)

[polonus]

So it is a good thing to break all links to this content delivery service dot eu sub-domain, even while it does not return any content now:
https://aw-snap.info/file-viewer/?protocol=not-secure&tgt=tdn.r42tag.com&ref_sel=GSP2&ua_sel=ff&fs=1

I would like to block the tag managing third party request inside the browser right away. (uMatrix of NoScript and RequestPolicy).

While they are on TUCOWS's dynect dot net (well name servers are) and that is known for running spam mailer services, I cannot grasp completely why the site owner or CEO there would allow such a snooper in the first place and why moneyou would cooperate with them... The main domain however belongs to a Dutch Amsterdam firm at the Meeuwenlaan, seel: https://www.whois.com/whois/r42tag.cok)so that may be the Dutch connection  (old boy's network).

But I cannot get any more info on that sub-domain, whois says: Can't get information on non-local domain TDN dot R42TAG dot COM.

No content being returned  -https://aw-snap.info/file-viewer/?protocol=not-secure&tgt=tdn.r42tag.com&ref_sel=GSP2&ua_sel=ff&fs=1  -> HTTP/1.1 404 Not Found

Was this a short termed suspicious tag managing campain running there? IP address is a Verizon one in USA named, MCI Communication Services (a tracker of sorts?): https://db-ip.com/72.21.92.108 EDGECAST (Are they on the look out for Dutch private financial data for whatever reason (spam)?) Well enough 'phishy ends"for me to not allow this content delivery service on a any page in my browser:  http://toolbar.netcraft.com/site_report?url=tdn.r42tag.com

To read why this tagging should be blocked if you prefer your financial privacy (mind the TAX office has it all anyway to the last dime,
and we do not know with what parties they all share the data they sit on with?)
Additionally found retirable code: http://retire.insecurity.today/#!/scan/f32609ff1c561e98f19494c669b1a5c9cd5ea5f45d4f86f37f6d25454a9bed77
and site also uses google-analytics.

On the concept of tagmanager in general and the anonymous feedback:
(source) https://www.google.com/intl/nl/tagmanager/faq.html  and anonymous feedback
(credits for above info explicitly mentioned by me here  )

polonus

[polonus]

Just considering some feedback about the so-called pre-load problem, it seems that it is not as vital a security problem as it seems.
When the site gets loaded into the browser for the first time, a pre-load list of HSTS is being loaded, so one has the advanced security of HSTS from the word go. Only with the initial visit the browser will turn http quickly into https. After that initial visit there is no problem any more. In the case of  -MoneYou the time lapse for a new initial visit is 47347200 seconds = 548 days = approx.. 1½ years.

The actual list for Google Chrome can be found here: https://cs.chromium.org/#chromium/src/net/http/transport_security_state_static.json

Listing there may also mean a cost verses profit decision by security managment, one has to pay considerably for the additional certificate. So these costs should outweigh the risk of eventual fraud and abuse  to make it worth while for that financial institution to come and implement this.

Existing EV-list and some security alert messages inside the browser could also be ample proof one has landed on the proper rightful site (despite of the "mixed content", what in case of banking sites should as much be avoided or else properly addressed).

polonus (volunteer website security analyst and website error-hunter)

[polonus]

To block so-called e-mail trackers from your browser get the blocklist here:

https://github.com/JannikArndt/EMailTrackerBlocker

Mind that list is far from complete. f you get an e-mail by someone who might have an interest in wheter you read it (i.e. marketing-people, companies, shops), look at the source (*) and try to find something like the above code. It is usually at the very end of the mail. Create an issue with the url and have it add to the JannikArndt's Github list!

How can I see the e-mail source?

macOS Mail: View > Message > Raw Source
Outlook: Right-click anywhere in the message and select View Source
Thunderbird: Select View > Message Source (or hit Ctrl+U)
GMail: Open message > Click on the down arrow next to the reply arrow > Show original

polonus