Kluitje riet. De site lijkt een Gemenge https http pagina aan te bieden. Zoiets hoort niet. Geen invloed van een derde?

Of heb je een intercepting virusscanner, die ook https sessies breekt?

De site is niet perfect. Als ik HSTS disable in MSIE lukt het me om op ten minste 2 plaatsen http content op te halen.

In de cookie-vraag popup wordt geladen:
http://www.moneyou.nl/~/media/MoneYou%20NL/Klantenservice/privacy-en-cookies-melding.png
Middels een redirect door de site wordt dat https, maar een aanvaller met netwerktoegang kan je hier alles voorschotelen wat hij wil.

In de pagina https://www.moneyou.nl/hypotheek/mijn-hypotheek verwijst "hier" in de zin "Helaas kun je dan alleen je Mijn Hypotheekomgeving openen door hier een nieuw account aan te maken" naar:
http://www.moneyou.nl/hypotheek/mijn-hypotheek-aanmelden.aspx
en dat is natuurlijk uitermate slordig.

Echter, doordat de site HSTS (http Strict Transport Security) headers meestuurt, zullen moderne webbrowsers zich niet van de wijs laten brengen en geen http content van deze site laden nadat jouw browser een https pagina "heeft gezien" met zo'n header.

Aangezien je met verschillende browsers en besturingssystemen hebt getest begrijp ik niet wat er aan de hand is, tenzij je met heel oude versies van die browsers werkt.

Zie je wel een EV certificaat als je https://www.moneyou.nl/ opent?

Op mijn Ubuntu-pc draait geen virusscanner, dus dat is het niet.

Bedankt voor je uitgebreide reactie. Helaas ben ik slechts een leek (wel verstandig genoeg om beveiligingswaarschuwingen serieus te nemen), dus ik weet niet zeker of ik alles goed begrijp. Mag ik jouw reactie als volgt samenvatten? Fouten in het ontwerp van de website die een risico kunnen opleveren tenzij je met een goed bijgewerkte browsers werkt?

In mijn geval wordt in ieder geval de Ubuntu-pc met alle software doorlopend bijgewerkt. Ik gebruik daar Firefox versie 51.0.1 (64-bits).

Wat betreft jouw laatste vraag: als ik https://www.moneyou.nl/ open, zie ik een groen slotje. Daarop kan ik doorklikken t/m de certificaatweergave: geverifieerd voor SSL-clientcertificaat en SSL-servercertificaat, uitgegeven door Symantec (Symantec Class 3 EV SSL CA - G3) met een looptijd van 06-05-16 tot 15-05-18.
Zodra ik vandaar doorklik om in te loggen op Mijn Hypotheek, veranderd het slotje van groen in een grijs slotje met een oranje driehoek.

Inmiddels heb ik het volgende ontdekt: De waarschuwing verschijnt steeds de 1e keer per sessie als de cookie waarschuwing verschijnt. Als ik de website verlaat en vervolgens weer terugkeer (zonder de browser te sluiten) blijft het slotje groen.
Is het dan veilig om in te loggen?

Dit is de fout: Zie hier: https://observatory.mozilla.org/analyze.html?host=www.moneyou.nl

Je kan niet achterover leunen en denken dat symantec alles wel veilig houdt, je zult ook wel zelf wat goed moeten configureren. Issue hier: https://sritest.io/#report/2f28c203-af61-4630-b589-cb07150cdb321

1 kwetsbare jQuery bibliotheek om af te serveren: http://retire.insecurity.today/#!/scan/f289cd9adda31bf79156ccb64397169ffa56928ebe818b1ae0829d754bf93436
(zelde script als bij de sri test issue). Maar ik zie dit externe script bij heel veel websites zonder sri hash gegenereerd.

Het www sub domein is 'not public' en DNS geeft "bad zone", verder zie:

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/ pas na ingeven van https://moneyou.nl.

Zie ook de 'unknown' aanduidingen hier: http://toolbar.netcraft.com/site_report?url=https://www.moneyou.nl

In de volgende opzichten zit alles daar goed: 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

Nogmaals het probleem is dus een preloader probleem.

Groet,

luntrus

Bij mij ook. Als je de site voor het eerst via https bezoekt en die laadt dan de cookie waarschuwing via het onveilige http dan kan je browser daar inderdaad voor waarschuwen. Je kan overigens zien wat onveilig is door bij de waarschuwing om meer details te vragen.

Verrder noemt Erik een aantal punten op die ook aangeven dat moneyou willekeurig omgaat met http en https.

Of het veilig genoeg is? Laat maar door Moneyou uitleggen waarom hun site veilig is als ze http content gebruiken op hun https site en dit browserwaarschuwingen geeft. Het helpt waarschijnlijk als je aan hun helpdesk vraagt of ze je bericht door willen sturen naar de security officer. Grote kans dat deze site met mixed https/http content niet aan de veiligheidseisen van hun moederbedrijf ABN AMRO.

Dat het de eerste keer wel gebeurt en de tweede keer niet is te verklaren met het feit dat Erik heeft aangetoond dat er zo te zien in het cookiescript van de website iets in http staat geprogrammeeerd: http://www.moneyou.nl/~/media/MoneYou%20NL/Klantenservice/privacy-en-cookies-melding.png
Daar krijg je mee te maken als je het cookiescript doorloopt, en dat is haast wel zeker in geval je geen (geldige) cookies in je browser meer hebt staan. Heb je echter al een geldige cookie, dan krijg je er niet meer mee te maken, en zie je dus ook die foutmelding niet meer.
Dus bij het eerste bezoek doorloop je het cookiescript, maar de tweede keer ziet de server dat je nog een geldige cookie hebt (die er nog in staat van de eerste keer)
Dus dat "inferieure" cookiescript wordt dan overgeslagen, en dientengevolge treedt de fout dan bij de tweede keer niet op.

Na sluiten van de browser verwacht ik dan dat de cookie wordt gewist. Werk je toevallig in privacy mode?

Er zit ook nog http://www.moneyou.nl/static/gfx/logo-moneyou-nl.png in vrijwel elke pagina. (moneYou logo)
Maar he, volgens mij maakt HSTS veel goed.
SSLLABS zeurt er dan ook niet over, en geeft hun website de maximale score: een A+.
Dus in mijn ogen een paar slordigheidjes die verder geen naam mogen hebben. Slechts enige ruimte voor verbetering.
Vraag is alleen wel: waarom zeurt je browser in versie 51.0.1 hier over? Is dat misschien het probleem?
Kijken browsers nog niet nauwkeurig genoeg misschien?

Ik laat alle cookies verwijderen bij het afsluiten van de browser, dus daarmee is verklaard waarom ik iedere eerste keer een waarschuwing zie.

Ik lees Windows 7, is dat niet het probleem dan?

Goed het bericht van de OP lezen en je komt al een eind met de vermoedelijke feiten vaststellen.

Heb je het Windows 7 servicepack geinstalleerd? Lees hier: https://www.security.nl/posting/40106/Microsoft+stopt+ondersteuning+Windows+7

Ja en in zo'n geval krijg je ook problemen met browser meldingen.

Bij Technische details staat in Firefox:

Het is dus zeker dat de browser valt over één of meer stukjes die in htttp over internet gaan i.p.v. https.
Stel je Firefox zo in, dat je geen cookies accepteert, dan krijg je deze fout niet.
Het heeft dus alles met hun cookiescript te maken.

Omdat deze fout dus niet op de main webpagina voorkomt, maar pas als je doorklikt naar "hypotheken",
zal SSLLABS dit niet opmerken, en kan je niet blindelings op die score vertrouwen.
Mij bevalt het niet zo. Vergeet even mijn post van "Vandaag, 15:17 door Anoniem".
Dit ziet er niet goed uit vind ik. Ik denk dat men hier nog maar eens goed naar moet kijken voor alle zekerheid.
Het risico is me te groot. Als de browser deze melding geeft, dan heeft ie ook daadwerkelijk een http-item voor zijn kiezen gehad volgens mij. Je kan het risico niet nemen dat het "waarschijnlijk alleen maar een afbeelding is"
Als ik afbeeldingen tegenhoudt in de browser, dan blijft nl. de melding toch weer komen...

Wakkere melding Mans! Goed opgelet. :-)

Kluitje, Riet, 100%

https://www.moneyou.nl/hypotheek/mijn-dossier is gewoon niet op orde, ook Safari op de mac geeft netjes aan dat er spullen worden geladen die niet geladen moeten worden op die manier.

Tip: Bel hun klantenservice, vraag om de afdeling internet security (of hoe ze het daar noemen; even volharden daarin!), vertel dit (luister goed naar de mensen die je ineens brand hoort roepen) en je probleem is heel snel opgelost.

Denk dat je snel een lekkere fles thuis krijgt als dank.

Laat je hier weer even horen hoe het afloopt?

p.s. En als ze moeilijk gaan lopen doen dat je dit toch even online deelde: eigen schuld dikke bult, hadden ze eerste keer de juiste actie moeten uitzetten.

Uhm, nee, dat is de fout niet. En die preload doen ze waarschijnlijk expres niet.

Ik heb al langere tijd problemen met Windows Update bij Windows 7, dus die gebruik ik feitelijk niet meer.
Maar de website van MoneYou roept dezelfde reacties op bij mijn volledig bijgewerkte Ubuntu 16.04. Ook onder Windows 10 reageert Firefox op dezelfde wijze. Edge reageert iets anders: hier verdwijnt het slotje helemaal zodra de cookie-melding in beeld komt.

off-topic
Off-topic, maar ik noem het maar even, voor het geval je het gemist zou hebben en het je probleem zou kunnen oplossen:
https://www.security.nl/posting/467976#posting498228

/end off-topic

Iedereen bedankt voor het meedenken (ook off-topic!).
Ik ga MoneYou hiermee confronteren en houd jullie op de hoogte.

Ben benieuwd of het al is opgelost?

Hum. Topicstarter Mans schreef gisteravond om 22:53 uur pas
"Ik ga MoneYou hiermee confronteren en houd jullie op de hoogte" (zie de post hierboven).
Geef MoneYou en Mans wellicht even een momentje de tijd ;-)

Precies. Meer dan 15 uur geleden dus.
Stel dat je zo lang zou moeten wachte voordat je geld uit de pinautomaat komt ;-)

Is er hier nog iets mee aan de hand, soms?:

Als we dexe URL daar scannen: URL: http://Moneyou.nl/static/js/functions.js?v=1-4-1-0310117
Vinden we in de code het volgende:
Is het inferieure van het cookie script terug te voeren op het gewijzigde NetSociety script, dat de click handler overschrijft?
Kan iemand commentaar geven?

Je kan in je browser de developer hulpmiddelen inschakelen.
Ik kom tot de volgende conclusie voor wat er gebeurt als je op "hypotheken " klikt:

Eén van de acties die er dan gebeuren is afkomstig van een derde partij: tdn.r42tag.com. Je krijgt van die website
één javascript (.js) script in je browser die niet helemaal deugt.
Het javascriptbestand zelf wordt wel keurig over https getransporteerd, maar gaat de browser dit .js script vervolgens uitvoeren, dan komt hij daarin de volgende programmeerinstructie tegen: http://www.moneyou.nl/~/media/MoneYou%20NL/Klantenservice/privacy-en-cookies-melding.png?(met nog wat "blabla")
Jawel: een afbeelding in http dus, veroorzaakt door een script afkomstig van een derde partij waar MoneYou kennelijk mee samenwerkt. Het zou me niet verbazen als het een compleet cookiescript is.

De browser maakt er zelf vervolgens keurig https van (vanwege HSTSheader), dus het kan verder geen kwaad deze keer.
Maar ondertussen laat de browser wel even weten dat er sprake was van "mixed content".
En slordig is het wel. MoneYou jaagt er waarschijnlijk een aantal oplettende bezoekers de stuipen mee op het lijf.
Dag potentiële klant! Want die proberen wel een andere aanbieder zonder mixed content waarschuwing in hun browser.
Want het is voor de gemiddelde internetter te lastig om met 100% zekerheid de oorzaak te vinden van deze warschuwing
(= een waarschuwing waarvan je in de war raakt ;-) in je browser. Dat is hier ook wel gebleken.

Je kunt aantonen dat het aan materiaal van tdn.r42tag.com ligt door "tdn.r42tag.com" op te nemen in je hosts-bestand of firewall of adblocker software e.d. Is deze derde partij website geblokt, dan treedt de fout niet op.
En als je in je browser alleen maar alle afbeeldingen blokkeert, dan los je het niet op, omdat de afbeelding als het ware wordt "binnengesmokkeld" met een .js script. De browser ziet immers aanvankelijk alleen een .js script, en die mag gewoon door als je browser tenminste javascript toelaat. (en default is dat tegenwoordig zo, want, zo hebben ze bij Firefox eens zo ongeveer gezegd: als je een bepaalde website bezoekt, dan vertrouw je die toch? Immers anders bezoek je hem niet......ahum)

Tot slot nog even op attent maken dat er een verouderde programmeerinstructie is gevonden in https://modules.moneyou.nl/all.min.js?7.48.0.3

@ anoniem van 16:25
L.S.
Dank voor het duidelijk uitgelegd betoog van wat er aan de hand is. Ieder die er op een bepaalde wijze analyserend er naar kijkt, zoals jij, voegt weer iets toe aan mijn opmerkingsvermogen en begrip van e.e.a..
Dank voor het delen van die kennis. Zo groeien we met elkaar en de opmerking van firefox developers daar vind ik echt beneden de maat. Vertrouw niets aleer je zelf heb vastgesteld of het veilig of onveilig is en niet in de blind dus. No way!
van: anoniem van 11:29 van 3-3-2017.

Verhelderend draadje wordt dit dus over https/http mixed content en waarom een blokkeren met een goed adblocker om die privacy invasieve externe derde partij code zoveel mogelijk te blokkeren altijd een goed advies is.

Tenminste als de bank websitein kwestie ze niet als essentieel ziet voor het functioneren van de website (tracking),
ABN bijvoorbeeld heeft hier een handje van en functioneeert derhalve niet goed op bepaalde browser clients.

OK, als toegift hier ook nog het cookies rapport voor dat third party domein: https://webcookies.org/cookies/tdn.r42tag.com/2125935

Op de site die we behandelen is het dus onachtzaam en kanhet gevaarlijk zijn, zoals we hier kunnen lezen:

luntrus

Merk wel op dat niemand naar "tdn.r42tag.com" kan gaan browsen, en dus ook niemand daar ergens op klikt.
Eerder lijkt me het een geval van een content delivery service voor MoneYou,
en waarschijnlijk pikken ze bij tdn.r42tag.com zelf ook ergens een graantje mee.
Bijvoorbeeld is het hierdoor dus ook bij tdn.r42tag.com bekend dat je de MoneYou website hebt bezocht
en dat je dus waarschijnlijk financiële interesses hebt.
Ik heb wel een sterk vermoeden dat tdn betekent: "trusted delivery network" of "tag delivery network".
En dat het net zoiets is als bijv. Googletagmanager:
(bron: https://www.google.com/intl/nl/tagmanager/faq.html)

Ja in zulke topic discussies moet je alle links, die je geeft, maar meteen liever breken met hxtp of -http of name dot name dot eu.

Het behoeft dan geen rakettechnologie om de URL/uri te herstellen, maar je voorkomt wel dat de onnozelaar er per ongeluk op klikt en narigheid hiervan ondervindt.

Ja ik zou het in de browser als third party link direct blokkeren. Goed als je dat met een goede blokker in je browser kan doen (uMatrix of NoScript of RequestPolicy).

Omdat ze op dynect dot net zitten (de naam-servers) en daar spam mailer diensten draaien, is het mij niet helemaal duidelijk wat zo'n snooper daar nou doet en waarom de CEO van moneyou ermee in zee gaat.. Het hoofddomein behoort wel toe aan een Amsterdams bedrijf aan de Meeuwensingel: https://www.whois.com/whois/r42tag.com

Maar ik krijg geen info over het sub-domein: Can't get information on non-local domain TDN dot R42TAG dot COM

Er komt hier geen content (meer) terug: -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 het misschien een kortdurende verdachte campagne die daar liep? Het IP adres komt bij Verizon in de States vandaan, MCI Communication Services (een tracker): https://db-ip.com/72.21.92.108 EDGECAST (Zijn die op zoek naar Nederlandse hypotheekdata misschien voor welke redenen dan ook?).

Genoeg 'phishy ends"voor mij om het niet in de browser toe te willen laten.

Hoi Luntrus, ik heb een tijdje moeten nadenken wat hiermee bedoeld kan zijn, en het enige waar ik op kom is de
HSTS preload list. Dit is een lijst van websites met HSTS, en de bedoeling is dat de browser deze onmiddellijk kent,
zodat je ook bij het allereerste bezoek van een bepaalde website al kunt profiteren van de HSTS veiligheid.
Van een website die niet in deze lijst staat, moet de browser namelijk bij het eerste bezoek van een bezochte website nog ontdekken dat deze website met HSTS werkt. Dat allereerste bezoek is dus minder veilig, met name als je zo'n website de allereerste keer met http benadert i.p.v https. De browser weet immers dan nog niet dat op de website HSTS actief is, dus de browser zal eerst niet automatisch van jouw http even HTTPS maken. Maar na het eerste bezoek is dit geen probleem meer. Tenzij er meer tijd verstrijkt tot het volgende bezoek van die website dan de tijdsduur van de website aangeeft. (meestal een jaar) Bij MoneYou is deze tijdsduur 47347200 seconden = 548 dagen = ca. 1½ jaar. Geen abnormale waarde. Je zou ook kunnen zeggen: MoneYou verwacht ten minste 1 x per 1½ jaar een bezoekje naar hun website... Doe je dat niet, dan is na 1½ jaar je browser vergeten dat het een HSTS website is.
Maar een preload blijft er altijd instaan, meteen vanaf de installatie van je browser.
Bij chrome zit het er meteen al in, en Firefox gaat dacht ik tijdens de installatie een website opzoeken om de preload lijst op te halen.

Nu is het niet eerlijk om alleen de MoneYou website ermee te confronteren dat ze niet in de preload lijst staan.
Kijk maar eens in de actuele preload lijst, te vinden op: https://cs.chromium.org/#chromium/src/net/http/transport_security_state_static.json
hoeveel Nederlandse bankdomeinen (en eindigend op ".nl") zijn daarin zijn opgenomen?.... ;-)
Ik weet niet of het onbekendheid is of een "kosten/baten" overweging of nog iets anders.
Bijvoorbeeld als een entry in de preload list meer kost dan in de praktijk de kosten aan fraude vanwege dit probleem?...
Er moet bijvoorbeeld ook weer een ander certificaat aangeschaft worden.
Daarbij: aan EV -certificaten kan je ook al best goed zien dat je op de juiste website zit (groene kleur),
en er zijn andere controle systemen gekomen zoals "Certificate Tranparency".
Aan beide doet de MoneYou website mee zo te zien.
Beetje gezeur lijkt mij dan ook die preload-manco.

@ anoniem van 16:41 van 5-3-2017

Hierop gaan afrekenen? Natuurlijk niet. Dat is helemaal de bedoeling niet van de uitdieping van dit topic. We rekenen niemand ergens op af. Verre van dat, we gaan gewoon door met de bewustmaking van het probleem of het voorbijgaan aan het probleem, als het dat geen echt probleem blijkt. Jij hebt ons allen hierbij enorm geholpen met je duidelijke afwegingen.

Misschien gaat men de policies van de preload listing aanpassen aan de praktijk en dan moet het weglopen van potentiële klanten, vanwege een onbegrepen browser alert, als er geen onveiligheid mee gemoeid is, uiteindelijk wel de doorslag geven. Marketing besluiten gaan niet altijd voor security en tag-managment ook niet, maar men moet niet gaan muggenziften als het niet per se hoeft.

Hoe zou jij als houder van de preload list dit probleem communiceren naar de security officers van de desbetreffende domeinhouders? Heeft de locale IT daar weet van en kunnen ze, zoals jij hier, de consequenties van hun beslissingen precies inschatten? De eindgebruiker kan dat natuurlijk niet. Nog hulde aan topic-starter, Mans, om de zaak in de eerste plaats aan te kaarten. Men mag zulke oplettende browser gebruikers wel heel erg dankbaar zijn, dat ze hier mee komen.

Goede betrouwbare feedback is de kurk waar de beveiligingswereld op drijft, zullen we maar zeggen.

We moeten per slot van rekening een afweging kunnen maken tussen mogelijke onveiligheid en echte beveiligingsproblemen.

Ten slotte mixed content moet men m.i. op bepaalde sites, zoals banksites etc.zoveel mogelijk vermijden. Policies moeten als dit kan geconfigureerd worden als 'best practices' en dan worden gehandhaafd, maar daar moet dan ook een handleiding voor worden gegeven en best practices moeten in dat geval bekend zijn en er moet ruimte zijn om die in te vullen afhankelijk van de gegeven (afwijkende) omstandigheden.

Nogmaals heel veel dank voor je bijdragen en het duidelijk krijgen van de vraagstellingen.

luntrus

Bedankt voor je reactie! Inhoudelijk akkoord. Behalve confronteren is iets anders dan afrekenen,
en opmerking: de houder van de browser HSTS preload list is in handen van Google. ;-)

Het heeft even geduurd, maar ik heb eindelijk een reactie van MoneYou:

"De cookiemelding (kleipop met een koekje) werd aangeroepen in http, en niet in https. De browser (afhankelijk van beveiligingsinstellingen) kan dan inderdaad aangeven dat de website niet veilig is omdat er een http wordt weergegeven in plaats van https.
Daarentegen is de website wel goed beveiligd. Naar aanleiding van uw melding is wel het aanroepen van de cookiemelding aangepast, en zal u dus ook geen beveiligingsmelding meer ontvangen en u zou zonder problemen moeten kunnen inloggen."

Ik krijg inderdaad nu alleen maar een groen slotje te zien.

Iedereen bedankt voor het meedenken!

Ha die Mans,

Schouderklopje, man, dat heb je nu wel verdiend van ons allemaal hier.

Door je reactie een probleem voor jezelf en dat van anderen opgelost!

Tevens heb je gezorgd voor het verder vergroten van het inzicht in deze materie
via het starten van en de verdere reacties in deze draad.

Je bent dus iemand die op digitaal vlak de eigen verantwoordelijkheid niet schuwt.
Hulde daarvoor. We hebben meer van zulk soort alerte gebruikers op het Internet nodig.

met vriendelijke groet,

luntrus (website foutenjager)

@Mans: dank voor de update, en goed dat ze uiteindelijk hebben geluisterd en de site is verbeterd!

Overigens begrijpt degene die jou het antwoord stuurde kennelijk niet dat een slotje betekent dat de verbinding beveiligd is, met de beveiliging van de website heeft dit niks te maken. En van "kleipop met een koekje" had ik nog nooit gehoord...

Ja het lijkt wel een antwoord van de "juffrouw van de receptie"...(ironie)

Niet veel mis met de inlog site: https://www.ssllabs.com/ssltest/analyze.html?d=secure.moneyou.nl

Jawel, maar met het cookie transport kan het beter, zie hier: https://observatory.mozilla.org/analyze.html?host=secure.moneyou.nl
D-status hier: https://securityheaders.io/?followRedirects=on&hide=on&q=https://secure.moneyou.nl
Onveilige redirects op het hoofddomein: https://hstspreload.org/?domain=moneyou.nl

Ook moet er een kwetsbare bibliotheek dient te worden afgevoerd: https://secure.moneyou.nl
Detected libraries:
jquery - 1.4.2 : (active1) https://secure.moneyou.nl/cwsoft/resources/scripts/CWThalerB2O.js?ver=1484028474455
Info: Severity: medium
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-4969
http://research.insecurelabs.org/jquery/test/
Info: Severity: medium
http://bugs.jquery.com/ticket/11290
http://research.insecurelabs.org/jquery/test/
Info: Severity: medium
https://github.com/jquery/jquery/issues/2432
http://blog.jquery.com/2016/01/08/jquery-2-2-and-1-12-released/
(active) - the library was also found to be active by running code

En oh, oh, kijk eens hier: http://www.domxssscanner.com/scan?url=https%3A%2F%2Fsecure.moneyou.nl%2Fcwsoft%2Fresources%2Fscripts%2FCWThalerB2O.js%3Fver%3D1484028474455

Number of sources found: 250
Number of sinks found: 103

http://research.insecurelabs.org/jquery/test/


luntrus (website foutenjager)

De "kleipop met een koekje" is volgens mij de afbeelding die gepaard gaat met de cookiemelding.

Zie ook post 04-03-2017, 16:25:

Fijn dat het nu is opgelost!

Aanvullend nog een leuke beta scannertje voorgesteld voor een ieder hier.
Gescanned werd de af te voeren jQuery bibliotheek op deze site -> https://secure.moneyou.nl/cwsoft/resources/scripts/CWThalerB2O.js?ver=1484028474455

Hier de DOM scan van e.e.a.: https://urlscan.io/result/9b8dca5d-1738-45bc-b09a-5f4be9f248d5/dom/
en deze aangaande de jsonview: https://urlscan.io/result/9b8dca5d-1738-45bc-b09a-5f4be9f248d5/jsonview/

Voor degenen hier, die deze scanner in beta nog niet kenden is het een leuke URL scanner voo reven een snelle verkenning.
Beperkt, iets andere optiek, maar wel grappig en nuttig tegelijk.

enjoy,

luntrus

Jongens, jongens toch.
Er is helemaal niets opgelost.
Als r42tag.com nu OK is, wie zegt dan dat het dat morgen ook is?
Het bedrijf of domein kan verkocht of gehackt worden of gepatriot(h)act!
Ik ben het hier en daar tegengekomen en heb het altijd geblokkeerd.
Dat maakte voor het gebruik van de websites verder niets uit.
DCOMbobulatie is de enige echt goede remedie voor de meeste malware ellende.
Heel lastig maar voor scripts heel makkelijk

B.V. FireFox en NoScript

Sta standaard helemaal niets toe.
Werkt het niet?
Sta het huisscript (met dezelfde URL) van de website toe.
Meestal werkt het dan wel of goed genoeg.
Zo niet dan is dat een overtreding van de nettiquette en reden tot klagen of weglopen.

Wat het r42tag dot com domein betreft, dat valt m.i. beter te blacklisten: https://www.mcafee.com/threat-intelligence/domain/default.aspx?domain=r42tag.com &
re: https://www.dns.ninja/?dns=tdn.r42tag.com

Aan de andere kant draait het op de ns1.argewebhosting.eu webserver als ns3.argewebhosting.nl reversed address bij XS4ALL. Dat moet toch een zeker vertrouwen kunnen inboezemen. Ze makenin elk geval reclame met de minste downtime. (ha, ha). Je moet naturrlijk niet overal direct expired domains gaan zien of sedo parking ad-serving....

Maar een beetje argwaan kan nooit kwaad, voorzichtigheid is de moeder van de porseleinkast.

luntrus