KNAB bank laadt via https oa. extern-http in, issue?

[b2vjfvj75gjx7]

Als ik bij [de bank] inlog op mijn zakelijke account (via https, netjes geregeld via een username / wachtwoord / cardreader), worden er vervolgens scripts van deze sites in de back-end ingeladen;

• https://content.knab.nl
• https://pincodekiezen.knab.nl
• https://www.knab.nl
• https://ssl.google-analytics.com
• https://secure.gravatar.com
• https://platform.twitter.com
• https://search.twitter.com
• https://*.visualwebsiteoptimizer.com
• https://cdn.uservoice.com
• https://eultrcqa.morningstar.com
• https://quadia.webtvframework.com
• https://lt.morningstar.com
• https://connect.facebook.net
• https://s-static.ak.facebook.com
• https://www.googletagmanager.com
• https://*.inbenta.com
• https://*.liveperson.net
• https://*.lpsnmedia.net
• https://googleads.g.doubleclick.net
• https://www.googleadservices.com
• https://www.google.com
• https://www.google.nl
• https://c.flx1.com
• https://go.flx1.com
• https://at19.net
• https://www.at19.net
• https://www.facebook.com
• https://secure.adnxs.com
• https://cdn.adnxs.com
• https://api.nanigans.com
• https://eum.knab.nl
• http://cdn.uservoice.com
• http://*.visualwebsiteoptimizer.com
• http://*.liveperson.net
• http://*.lpsnmedia.net

De onderste vier gaan via http en de rest is vooral gericht op Social Media, tracking en site-optimization (UA / UX).

Naar mijn mening is dit onnodig (Facebook inladen in een beveiligde, zakelijke bankomgeving?!) en onveilig (http en sowieso tientallen scripts van externe partijen - er hoeft maar één rotte appel tussen te zitten).

Maak ik mij terecht zorgen, of is dit normaal bij een financiële, beveiligde instelling?

Overigens heb ik het al gemeld bij KNAB, maar de persoon aan de lijn kon er niets van zeggen "want die had de site niet gebouwd".

Ik wilde het laten escaleren naar hoger niveau, maar dat ging niet.

[DiedX]

Ik ben het met je eens dat het wel wát veel is.

[b2vjfvj75gjx7]

DiedX schreef op vrijdag 20 januari 2017 @ 17:59:
Ik ben het met je eens dat het wel wát veel is.

Veel sowieso... 25 tracking-scripts voor een site met de interface van Pipo de Clown...

...maar het gaat mij vooral om het onveilige karakter.

Als Gravatar, AT19 of Morningstar een issue met de server heeft en die serveert een script met malafide code, laadt KNAB dat dus in op je persoonlijke bank-account...

[b2vjfvj75gjx7]

Overigens blokkeer ik alles, maar als je dat doet - werkt het adresboek niet meer

Dus om adressen toe te voegen, moest ik de blokkade pauzeren en toen zag ik die shitload aan externe http binnenkomen....

[Juup]

Het is triviaal om een evil script te injecteren als je deze website via een onbekend WiFi punt oid bezoekt dus dit is wat mij betreft absoluut onacceptabel.

Ook zou het voor mij compleet onacceptabel zijn dat zo'n site iets van facebook of twitter inlaadt.

[b2vjfvj75gjx7]

Juup schreef op vrijdag 20 januari 2017 @ 18:05:
Het is triviaal om een evil script te injecteren als je deze website via een onbekend WiFi punt oid bezoekt dus dit is wat mij betreft absoluut onacceptabel.

Ook zou het voor mij compleet onacceptabel zijn dat zo'n site iets van facebook of twitter inlaadt.

Exact mijn twee punten;

1. HTTP voor een bankomgeving?!
2. WTF doen Facebook en Twitter daar? *)

*) Of moet ik soms Tweeten "ik heb net 3.750 euro betaald aan de Belastingdienst"

351 mensen vinden dit leuk

Dat ze "iets" tracken, okay - maar doe dat intern, niet via Google of andere (schimmige) user-monitoring bedrijven.

Toevallig "zit" ik in het Customer Relation Feedback Management wereldje, en je wil niet weten hoe sommige van die databases / servers / scripts in elkaar zitten... die shit wil je absoluut niet in je bank-omgeving hebben.

[Rukapul]

De bank kan op deze wijze nooit redelijkerwijs garanderen dat de site veilig functioneert. Daarvoor zijn er teveel derde partijen betrokken waarvan een flink aantal aanzienlijk lagere security standaarden hanteren.

Het inladen van non-HTTP content in een banksite kan inderdaad ook niet. In het algemene geval is het op zijn minst deprecated.

[Thralas]

b2vjfvj75gjx7 schreef op vrijdag 20 januari 2017 @ 18:11:
Dat ze "iets" tracken, okay - maar doe dat intern, niet via Google of andere (schimmige) user-monitoring bedrijven.

Toevallig "zit" ik in het Customer Relation Feedback Management wereldje, en je wil niet weten hoe sommige van die databases / servers / scripts in elkaar zitten... die shit wil je absoluut niet in je bank-omgeving hebben.

Dat ben ik met je eens, maar enkel uit principieel oogpunt, het praktijkrisico wordt vaak overschat (je gaat eerder failliet aan Starbucks dan 't risico dat je daar loopt op een man-in-the-middle-attacker).

ING heeft 1 externe include (over https), maar ook dat is er eigenlijk al een teveel.

[b2vjfvj75gjx7]

Rukapul schreef op vrijdag 20 januari 2017 @ 18:13:
De bank kan op deze wijze nooit redelijkerwijs garanderen dat de site veilig functioneert. Daarvoor zijn er teveel derde partijen betrokken waarvan een flink aantal aanzienlijk lagere security standaarden hanteren.

Het inladen van non-HTTP content in een banksite kan inderdaad ook niet. In het algemene geval is het op zijn minst deprecated.

Precies mijn gedachte...

Ik blokkeer die dingen via een blacklist op router-niveau en draait Ghostery in de safe mode.

Maar toen ik een adres (in de bankomgeving) wilde wijzigen, kreeg ik errors in de developers console van mijn browser (die ik standaard open heb staan als ik financiële transacties doe, ter controle van wat er onder water gebeurd).

Hierdoor zag ik via de netwerk-monitor-tool al die scripts en al dat verkeer heen en weer geschoten worden.

Wellicht ben ik te voorzichtig, vandaar deze thread...

[Juup]

Je zou het kunnen melden op
https://www.publeaks.nl/
of
http://www.arnoud.engelfriet.net/
of
http://www.ncsc.nl/

of volgens deze pdf: https://www.veiligbankier...kwetsbaarheden-FIISAC.pdf

Hoe moet ik de melding doen
Heeft u een kwetsbaarheid gevonden, neem dan contact met ons op via e-mail:
<responsibledisclosure@BANK>.
Gebruikt u hiervoor de volgende PGP key: <RD PUBLIC PGP KEY
BANK>.

[André]

Dit is echt ongehoord, dat tools als VWO hier op die pagina's online staan. De persoon die de login van VWO heeft kan in minuten tonnen naar zijn eigen rekening krijgen. Tijdelijk login IDS en saldos loggen, enz. Alles na de login zou nagenoeg tracking vrij moeten zijn. Hooguit een Analytics ding om anoniem gebruik te meten.

[b2vjfvj75gjx7]

Thralas schreef op vrijdag 20 januari 2017 @ 18:18:
[...]


Dat ben ik met je eens, maar enkel uit principieel oogpunt, het praktijkrisico wordt vaak overschat

Ik mag geen namen noemen maar ik weet van één Customer Feedback Management bedrijf, dat die alle feedback van oa. Tele2 en Shell "per ongeluk" opsloegen in een niet beveiligde database, op een server die - letterlijk - in een schoonmaak-hok stond...

Pas na het weekend kwamen ze er achter dat die database "toch best wel flink gevuld was opeens" en ontdekten ze dat alle feedback niet bij de juiste partijen was terecht gekomen, maar per ongeluk naar hun toe was gerouterd...

...stel je voor dat deze data / chat-gesprekken / etc... ook daaraan onderhevig zijn...

[b2vjfvj75gjx7]

Juup schreef op vrijdag 20 januari 2017 @ 18:19:
Je zou het kunnen melden op
https://www.publeaks.nl/
of
http://www.arnoud.engelfriet.net/
of
http://www.ncsc.nl/

of volgens deze pdf: https://www.veiligbankier...kwetsbaarheden-FIISAC.pdf

[...]

Ik heb het aanhangig gemaakt bij de escalatie-manager van [de bank]... dus ik wacht eerst die af...

Deze thread is meer privé bedoelt (voor mijzelf) en gaat over de principiële vraag of het correct is dat ze die dingen inladen...

[b2vjfvj75gjx7]

André schreef op vrijdag 20 januari 2017 @ 18:19:
Dit is echt ongehoord, dat tools als VWO hier op die pagina's online staan. De persoon die de login van VWO heeft kan in minuten tonnen naar zijn eigen rekening krijgen. Tijdelijk login IDS en saldos loggen, enz. Alles na de login zou nagenoeg tracking vrij moeten zijn. Hooguit een Analytics ding om anoniem gebruik te meten.

Welke tool hint je op?

Overigens laden ze ook scripts in van deze partij;

http://quadia.webtvframework.com/intervet/_app/player/?id=28423

Gewoon domme video's... wat doen die partijen in de backend van een (zakelijke) bank-omgeving?

[André]

b2vjfvj75gjx7 schreef op vrijdag 20 januari 2017 @ 18:25:
[...]


Welke tool hint je op?

Overigens laden ze ook scripts in van deze partij;

http://quadia.webtvframework.com/intervet/_app/player/?id=28423

Gewoon domme video's... wat doen die partijen in de backend van een (zakelijke) bank-omgeving?

Ik bedoel de Visual Website Optimizer, maar ook de Google Tag Manager. Iedereen met toegang tot die tools kan eenvoudig alle HTML en JavaScript op alle pagina's aanpassen. Dus ook zaken uitlezen en manipuleren.

[b2vjfvj75gjx7]

André schreef op vrijdag 20 januari 2017 @ 18:28:
[...]
Ik bedoel de Visual Website Optimizer,

Ah, die

Ja, ik gebruik Hotjar (voor klanten, niet voor mezelf...) en die staat er om berucht dat je ALLES kan vastleggen dat de gebruiker doet, dus ook creditcard-nummers, etc...

Je ziet (als Hotjar backend-gebruiker) exact wat de klant (achter de computer) doet, wat hij intikt, waar hij op klikt, hoe lang hij naar iets kijkt, hoe de muis beweegt en waarheen hij scrollt...

Extreem onveilig; alsof je een camera ophangt die gericht staat op een pin-automaat (360 graden video, met 48khz audio-kwaliteit en high-res resolutie)...

[André]

b2vjfvj75gjx7 schreef op vrijdag 20 januari 2017 @ 18:39:
[...]


Ah, die

Ja, ik gebruik Hotjar (voor klanten, niet voor mezelf...) en die staat er om berucht dat je ALLES kan vastleggen dat de gebruiker doet, dus ook creditcard-nummers, etc...

Je ziet (als Hotjar backend-gebruiker) exact wat de klant (achter de computer) doet, wat hij intikt, waar hij op klikt, hoe lang hij naar iets kijkt, hoe de muis beweegt en waarheen hij scrollt...

Extreem onveilig; alsof je een camera ophangt die gericht staat op een pin-automaat (360 graden video, met 48khz audio-kwaliteit en high-res resolutie)...

Klopt, als ik die tool implementeer vraag ik altijd welke velden gemaskeerd moeten worden, dat soort opties zijn gewoon aanwezig, dan zie je bij die velden alleen sterretjes. Maar dat staat los van bank omgevingen, daar moet het gewoon uit.

[André]

Ik heb het even op Twitter geslingerd, heb wel aardig wat volgers uit de Analytics en marketing wereld. Ze hebben ook al gereageerd, zou me niets verbazen als dit heel snel opgelost gaat worden.

[b2vjfvj75gjx7]

- update -

Antwoord van [de bank] (snel zijn ze wel).

De persoon via de mail kan mij eventueel wel uitleggen waar de scripts voor dienen (ja, bedankt - ik weet waarvoor ze dienen...) maar niet exact waarom ze worden ingeladen.

Het is geëscaleerd naar een hoger niveau, na het weekend dus meer.

Maar goed;

Het gaat mij er om of ze weten dat dit onveilig is en on-etisch (Facebook inladen op een pagina met privé gegevens over financiën?).

Los daarvan exporteren ze nu gigantisch veel privé-gegevens naar externe partijen; het is maar de vraag of de Web Bescherming Persoonsgegevens daar happy mee is.

- update 2 -

[de bank] reageert gelukkig wel snel en zeer open, waarvan akte.

Er schijnt ook iets gaande te zijn op Twitter, maar dat gebruik ik niet dus dat laat ik er maar even buiten...

Na het weekend wordt er naar gekeken en ze nemen het zeer serieus.

Overigens gaat het mij niet direct om de onveiligheid (al is dat natuurlijk zeer belangrijk...) maar vooral om het feit dat ze direct scripts van derden injecteren in de DOM, waarmee ze de totale controle over hun back-end verliezen (én dus al je klik-gedrag delen met (Amerikaanse) commerciële toko's).

Laad gewoon Piwik in voor je statistieken (eigen server, eigen beheer) en meer niet, zou ik zeggen...

- update 3 -

Lol, zojuist gebeld door de bank-directeur van [de bank] (tenminste, dat zei hij)

Hij vroeg zich af waarom ik zo weinig inkomsten-belasting had betaald vorig jaar en of Mark Zückerberg daar wel van op de hoogte was... geintje natuurlijk

Maar het issue van de scriptjes was ook op zijn bord terecht gekomen, en belde mij om te melden dat er dit weekend een externe audit wordt gedaan op de situatie.

Waarschijnlijk zijn het "resten" van het vorige platform waarop de site is gebouwd en zijn veel scripts niet bewust actief / nodig meer.

Verdere technische details wist hij zo snel niet, en ik natuurlijk nog veel minder - maar het feit dat ze zo open zijn en adequaat reageren vind ik wel een zeer positief iets, these days.

Een bank die transparant is; ik raad hem (toch) iedereen aan...

[ Voor 58% gewijzigd door b2vjfvj75gjx7 op 20-01-2017 21:33 ]

[André]

Hij reageerde ook op Twitter, goed om te zien dat ze het serieus nemen inderdaad. En er ook open over zijn, in vergelijking met andere banken een dikke plus.

[Basszje]

Dus ze hebben standaard geen audit en geen risico-analyse op hun core business? Je zou dat bij een 'risicovol' en privacygevoelig serieus bedrijf wel anders verwachten. Als dit hun opstelling is, hoe goed is de rest dan geregeld?

[Malt007]

Basszje schreef op zaterdag 21 januari 2017 @ 08:31:
Dus ze hebben standaard geen audit en geen risico-analyse op hun core business? Je zou dat bij een 'risicovol' en privacygevoelig serieus bedrijf wel anders verwachten. Als dit hun opstelling is, hoe goed is de rest dan geregeld?

Er moet ergens op bespaard worden als ze hogere rente geven en lagere kosten rekenen wellicht?

[b2vjfvj75gjx7]

Basszje schreef op zaterdag 21 januari 2017 @ 08:31:
Dus ze hebben standaard geen audit en geen risico-analyse op hun core business?

Dat weet ik niet, en is ook niet zo gecommuniceerd... maar ik mag hopen dat er inderdaad met onregelmatige regelmaat audits worden gedaan; vooral als je zo veel scripts van oncontroleerbare partijen inlaad.

Ik bouw zelf geen banken-sites (duh...) maar zelfs dan accepteer ik geen code van derden in mijn omgeving.

Af en toe een plugin gebruiken, okay - maar ook dan lees ik persoonlijk de code door voor ik hem uitrol op een server (en dan gaat het om "lullige" bedrijvensites, zonder privacy-gevoelige data).

[Johnny]

Je had het probleem ook natuurlijk kunnen melden via de Knab community. Oh nee, toch niet, zelfs als je klant bent moet je inloggen met een Social Media account. Heb je die niet? Maakt niet uit, inloggen werkt toch niet want je wordt doorgestuurd naar http://old.knab.local zodra je op een knop klikt, en die server bestaat natuurlijk niet in je eigen lokale netwerk.

Wel fijn voor Knab dat je dan ook geen lastige vragen kan stellen over waarom je anno 2017 nog steeds niet zelf een spaarrekening kan verwijderen terwijl in 2013 werd beloofd dat alle functionaliteit via de online omgeving beschikbaar zou komen.

[ Voor 16% gewijzigd door Johnny op 21-01-2017 12:59 ]

[DeKever]

Basszje schreef op zaterdag 21 januari 2017 @ 08:31:
Dus ze hebben standaard geen audit en geen risico-analyse op hun core business? Je zou dat bij een 'risicovol' en privacygevoelig serieus bedrijf wel anders verwachten. Als dit hun opstelling is, hoe goed is de rest dan geregeld?

Dit lijkt me iets te voorbarig. Geef ze nog even het voordeel van de twijfel. Hopelijk komen ze met een goede inhoudelijke (re)actie.

[b2vjfvj75gjx7]

Johnny schreef op zaterdag 21 januari 2017 @ 12:56:
Je had het probleem ook natuurlijk kunnen melden via de Knab community. Oh nee, toch niet, zelfs als je klant bent moet je inloggen met een Social Media account. Heb je die niet? Maakt niet uit, inloggen werkt toch niet want je wordt doorgestuurd naar http://old.knab.local zodra je op een knop klikt, en die server bestaat natuurlijk niet in je eigen lokale netwerk.

Wel fijn voor Knab dat je dan ook geen lastige vragen kan stellen over waarom je anno 2017 nog steeds niet zelf een spaarrekening kan verwijderen terwijl in 2013 werd beloofd dat alle functionaliteit via de online omgeving beschikbaar zou komen.

Ik heb het aanvankelijk aangekaart via de chat; hun klantenservice vind ik juist weer perfect - erg snel / adequaat.

En je kan wel je rekening verwijderen Ik had een privé- en zakelijke rekening geopend aanvankelijk. Privé liep ik tegen issues aan buiten hun gebied om en dus heb ik die gewoon opgeheven, met behoud van de zakelijke...

Inloggen via Social Media is inderdaad onzin en één van de redenen waarom er zo extreem veel third-party assets worden binnengeharkt...

De hele UA / UX ziet er wel uit als Pipo de Clown; ik zou bijna zelf een custom-css maken om de back-end te professionaliseren...

- edit -

Lol, ze laden zelfs 2x alle externe scripts in... en als bonus nog een highcharts via http... laat de API van highcharts nu net niet de meest veilige zijn (ik heb er zelf aardig wat mee weten te injecteren via een Cordova app)...



He he, er staan ook verwijzingen naar de test en productie omgeving... op een live server?!

code:

        if      (window.location.hostname.indexOf('.knab.nl') > -1)  { var _env = 'PRODUCTION'; }
        else if (window.location.hostname.indexOf('.a.bankvanmorgen.nl') > -1) { var _env = 'UAT'; }
        else if (window.location.hostname.indexOf('.t.bankvanmorgen.nl') > -1)  { var _env = 'TESTING'; }
        else  { var _env = 'DEVELOPMENT'; }

En niet gevaarlijk, wel potentieel - men gebruikt een .SVG als logotype;

https://www.knab.nl/~/media/knab/shared/knab-logo.svg?la=nl

En laat .SVG nu net een DOM-object zijn waar je javascripting in kan draaien... één keer een malafide .SVG uploaden en je back-end is besmet... ding is gemaakt via de export-plugin van Illustrator, maar de #ID's staan er nog in.

[ Voor 29% gewijzigd door b2vjfvj75gjx7 op 21-01-2017 15:11 ]

[Juup]

b2vjfvj75gjx7 schreef op zaterdag 21 januari 2017 @ 14:57:
https://www.knab.nl/~/media/knab/shared/knab-logo.svg?la=nl

En laat .SVG nu net een DOM-object zijn waar je javascripting in kan draaien... één keer een malafide .SVG uploaden en je back-end is besmet... ding is gemaakt via de export-plugin van Illustrator, maar de #ID's staan er nog in.

Huh? Welke ID's heb je het over en waarom zijn die gevaarlijk?
btw als je al iets kan uploaden naar de backend dan is de scripting binnen svg je minste probleem.

[Compizfox]

Even voor de duidelijkheid: Als de site zelf over HTTPS gaat, worden externe scripts over HTTP niet ingeladen door Firefox omdat het gaat om actieve mixed content. (meer info)

Zover ik weet heeft Chrome een vergelijkbare mixed content policy.

Het is natuurlijk belachelijk dat deze scripts er überhaupt inzitten, maar met een fatsoenlijke browser doen ze het helemaal niet.

[ Voor 8% gewijzigd door Compizfox op 21-01-2017 15:53 ]

[CH4OS]

Compizfox schreef op zaterdag 21 januari 2017 @ 15:52:
Even voor de duidelijkheid: Als de site zelf over HTTPS gaat, worden externe scripts over HTTP niet ingeladen door Firefox omdat het gaat om actieve mixed content. (meer info)

Zover ik weet heeft Chrome een vergelijkbare mixed content policy.

Het is natuurlijk belachelijk dat deze scripts er überhaupt inzitten, maar met een fatsoenlijke browser doen ze het helemaal niet.

Leuk, dat browsers dat dan tenminste nog blokkeren. Feit blijft dat je in een bankieren omgeving van een bank dit gewoon totaal niet wilt, net als de trackers van o.a. Google, Facebook en Twitter niet. Facebook en Twitter zijn niet nodig, voor Google Analytics heb je Piwik bijvoorbeeld als alternatief.

[Compizfox]

CH40S schreef op zaterdag 21 januari 2017 @ 15:56:
[...]
Leuk, dat browsers dat dan tenminste nog blokkeren. Feit blijft dat je in een bankieren omgeving van een bank dit gewoon totaal niet wilt, net als de trackers van o.a. Google, Facebook en Twitter niet. Facebook en Twitter zijn niet nodig, voor Google Analytics heb je Piwik bijvoorbeeld als alternatief.

Het is natuurlijk belachelijk dat deze scripts er überhaupt inzitten

[Johnny]

b2vjfvj75gjx7 schreef op zaterdag 21 januari 2017 @ 14:57:
[...]


Ik heb het aanvankelijk aangekaart via de chat; hun klantenservice vind ik juist weer perfect - erg snel / adequaat.

En je kan wel je rekening verwijderen Ik had een privé- en zakelijke rekening geopend aanvankelijk. Privé liep ik tegen issues aan buiten hun gebied om en dus heb ik die gewoon opgeheven, met behoud van de zakelijke...

Een betaalrekening wellicht wel, maar een "flexibele spaarrekening" (welke geen eigen IBAN heeft) kun je heel eenvoudig aanmaken. Handig als spaarpotje voor een specifiek spaardoel! Als je vervolgens je spaardoel hebt bereikt kan je ze op geen enkele manier verwijderen. Dan moet je bellen, lekker flexibel! Ze zijn gelukkig wel iedere dag bereikbaar, maar het is natuurlijk supersuf voor een internetbank die hip probeert te zijn met een pipo-de-clown huisstijl. Als je het topic ziet waar ik naar linkte zie je dat ze in 2013 al aangaven dat ze dit mogelijk willen maken, de afgelopen jaren is er echter geen enkele uitbreiding geweest in de online dienstverlening. Het lijkt alsof Knab is blijven hangen in 2013.

[b2vjfvj75gjx7]

Juup schreef op zaterdag 21 januari 2017 @ 15:35:
[...]

Huh? Welke ID's heb je het over en waarom zijn die gevaarlijk?
btw als je al iets kan uploaden naar de backend dan is de scripting binnen svg je minste probleem.

SVG is gewoon een extensie bovenop de DOM en staat "berucht" om het feit dat je er codes in kan draaien.

Je hebt gelijk dat als je upload-rechten hebt, je sowieso scripts kan draaien - maar stel je dit scenario voor;

Vormgever maakt logo, heeft een illegale plug-in voor Illustrator om SVG's te exporteren.

Tijdens de export wordt er in de SVG code geïnjecteerd door die malafide plugin.

Het SVG-logo wordt door de "webmaster" netjes geupload, zonder dat hij weet dat er code in de SVG zit.

Elke bezoeker van de site wordt nu getrakteerd op de SVG mét code.

En geloof me; dat is zeer eenvoudig, ik heb zelf veel proof of concepts gemaakt.

Daarom moet je een SVG altijd minifyen / cleanen before upload en de DOM #ID's er uit slopen, nu bevat dat ding veel te veel (meta-) data (tip : open logo in browser / view source...)....

[ Voor 3% gewijzigd door b2vjfvj75gjx7 op 21-01-2017 16:15 ]

[b2vjfvj75gjx7]

Compizfox schreef op zaterdag 21 januari 2017 @ 15:52:
Even voor de duidelijkheid: Als de site zelf over HTTPS gaat, worden externe scripts over HTTP niet ingeladen door Firefox omdat het gaat om actieve mixed content. (meer info)

Zover ik weet heeft Chrome een vergelijkbare mixed content policy.

Het is natuurlijk belachelijk dat deze scripts er überhaupt inzitten, maar met een fatsoenlijke browser doen ze het helemaal niet.

Elke browser doet dat, behalve als je CORS aan hebt staan, maar Cross Domain References zijn per definitie niet toegestaan (oftewel; men laadt scripts in, die vervolgens niet eens uitgevoerd kunnen worden...)....

[Juup]

b2vjfvj75gjx7 schreef op zaterdag 21 januari 2017 @ 16:12:
Daarom moet je een SVG altijd minifyen / cleanen before upload en de DOM #ID's er uit slopen, nu bevat dat ding veel te veel (meta-) data (tip : open logo in browser / view source...)....

Ok welke #ID's staan er in https://www.knab.nl/~/media/knab/shared/knab-logo.svg?la=nl waar jij je zorgen over maakt?

[b2vjfvj75gjx7]

Juup schreef op zaterdag 21 januari 2017 @ 15:35:
[...]

Huh? Welke ID's heb je het over en waarom zijn die gevaarlijk?
btw als je al iets kan uploaden naar de backend dan is de scripting binnen svg je minste probleem.

Working demo

Het logo van KNAB, met code geïnjecteerd (onschuldig in dit geval - maar je kan dus ook een dynamisch javascript in de <head> injecten, die inladen vanaf een externe server - die via AJAX een .php script aanroept, terugkoppelt naar het logo en daar "iets" mee doen...).

[ Voor 4% gewijzigd door b2vjfvj75gjx7 op 21-01-2017 17:17 ]

[thof]

b2vjfvj75gjx7 schreef op zaterdag 21 januari 2017 @ 16:12:
Vormgever maakt logo, heeft een illegale plug-in voor Illustrator om SVG's te exporteren.

Tijdens de export wordt er in de SVG code geïnjecteerd door die malafide plugin.

Het SVG-logo wordt door de "webmaster" netjes geupload, zonder dat hij weet dat er code in de SVG zit.

Volgens mij heb je een heel ander probleem als je een vormgever in dienst hebt die uberhaupt gebruik maakt van illegale plugins,

Overigens snap ik het risico wel. Is met developers van je web applicatie niet anders namelijk, als die een IDE plugin heeft die niet helemaal zuiver is dan loop je tegen het zelfde issue aan (los van een Build/CI/CD straat).

[b2vjfvj75gjx7]

Juup schreef op zaterdag 21 januari 2017 @ 16:38:
[...]

Ok welke #ID's staan er in https://www.knab.nl/~/media/knab/shared/knab-logo.svg?la=nl waar jij je zorgen over maakt?

Zie hierboven... het gaat niet om de #ID's, maar om het feit dat ze de bron van de SVG nooit hebben gechecked en er dús code in kan staan...

Normaal minify je de SVG code - dat is hier niet gebeurt (anders zie je die DOM paden niet).

[orf]

Als een SVG in een <img> tag wordt gebruikt, wordt javascript niet uitgevoerd.

[b2vjfvj75gjx7]

thof schreef op zaterdag 21 januari 2017 @ 17:18:
[...]


Volgens mij heb je een heel ander probleem als je een vormgever in dienst hebt die uberhaupt gebruik maakt van illegale plugins

Klopt, maar daar gaat het niet om

Assumption is the mother of all fuck ups...

Het logo is blijkbaar nooit gechecked en dus kán er code inzitten...

Er van uit gaan dat je ontwerper (bewust of niet) geen illegale plugin heeft, moet je niet als basis nemen;

0% risico - zeker bij een bank.

En je kan natuurlijk ook gewoon legale software hebben en toch malafide code draaien, per ongeluk.

Of je bent ontwerper en je hebt geld nodig...

Logo maken, code er in, via javascript "verbergen" als het logo wordt aangeroepen van het interne domein bij KNAB om zo onder de radar te blijven en pas activeren als het IP van buiten komt...

[b2vjfvj75gjx7]

orf schreef op zaterdag 21 januari 2017 @ 17:20:
Als een SVG in een <img> tag wordt gebruikt, wordt javascript niet uitgevoerd.

Omdat je hem dan moet parsen, bv. via Greensock... ik kan dat zo maken, maar dat kost 5 minuten extra. (en het blijft allemaal javascript / SVG)

code:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="162.5 376.9 279.6 91.1" enable-background="new 162.5 376.9 279.6 91.1"><g fill="#3e4a59"><path d="m268.9 401.1c-9.1 0-14.9 4.7-18.4 10.3h-.3l.1-9.1h-17.6c-1.6 0-3 2-3 3.8v56c0 1.8 1.5 3.7 3.1 3.7h17.5v-31.4c0-9.1 2.5-16.3 11.3-16.3 8.5 0 9.8 6.3 9.8 14.7v29.3c0 2 1.5 3.7 3 3.7h17.6v-37.5c.1-15.4-4.7-27.2-23.1-27.2"/><path d="m404.7 401.1c-8.3 0-14 3-17.4 6.1.1-2.3.1-5.6.1-8.9v-21.4h-17.5c-1.6 0-3 2-3 3.7v81.4c0 2 1.5 3.7 3.1 3.7h16.5l-.1-5.2c4.7 4.5 11.1 6.6 18.2 6.6 18.4 0 30.1-14.4 30.1-33.1-.1-18.6-11.7-32.9-30-32.9m-4.4 48.9c-8.6 0-14.6-6.7-14.6-16.5 0-9.8 5.9-16.5 14.6-16.5 8.6 0 14.4 6.7 14.4 16.5 0 9.8-5.7 16.5-14.4 16.5"/><path d="m226.1 402.2h-21.2c-1.6 0-3.3.9-4.3 2.1l-17.5 18.9v-46.4h-17.6c-1.6 0-3 2-3 3.7v81.5c0 1.8 1.2 3.7 3 3.7h17.6v-19.2l5.7-5.5 14.1 22.3c1.3 1.8 3.1 2.4 5.2 2.4h19.9l-25.1-39.7 23.2-23.8"/><path d="m351.5 408.5c-5-4.7-11.9-7.4-23.7-7.4-10.1 0-18.8 2.8-24.5 5.2-1.5.7-2.1 2.7-1.5 4.2l4.2 10.5c3.3-2.1 11.3-5.7 19.4-5.7 8.3 0 13 3.5 13 10.2v1.4l-16 .6c-11.7.5-24.7 5.3-24.7 19.4 0 14.1 11.9 20.2 23.1 20.2 10.3 0 15.5-5.4 18.2-8.1l.3 4.3c.1 1.2 1.2 2.3 2.8 2.3h17v-35.6c-.1-10.7-2.7-16.9-7.6-21.5m-12.9 39.8c-1.3 2.2-5 5.8-10.5 5.8-5.7 0-9.7-3-9.7-7.8 0-4.7 3.7-7.5 10-7.7l10.2-.6v10.3"/><path d="m436.8 467.9c-3 0-5.3-2.3-5.3-5.3 0-3 2.3-5.3 5.3-5.3s5.3 2.3 5.3 5.3c0 3-2.4 5.3-5.3 5.3m0-9.8c-2.5 0-4.5 2-4.5 4.5 0 2.5 2 4.5 4.5 4.5 2.5 0 4.5-2 4.5-4.5 0-2.5-2-4.5-4.5-4.5m2.6 7.6h-1.5l-1.3-2.5h-.6v2.5h-1.3v-6.2h2.2c1.3 0 2.2.7 2.2 1.9s-.8 1.6-1.3 1.8l1.6 2.5m-2.7-5.1h-.7v1.7h.7c.6 0 1.1-.1 1.1-.8 0-.8-.5-.9-1.1-.9"/></g></svg>

Dit is trouwens de cleaned version van het logo - nog 35% kleiner om te downloaden ook

[ Voor 81% gewijzigd door b2vjfvj75gjx7 op 21-01-2017 17:25 ]

[b2vjfvj75gjx7]

orf schreef op zaterdag 21 januari 2017 @ 17:20:
Als een SVG in een <img> tag wordt gebruikt, wordt javascript niet uitgevoerd.

http://deathgrunt.com/tmp/svg/

...nu werkt het script ook, vanaf een pagina met het logo als image

Overigens zonder Greensock, je kan hem gewoon als object aanroepen...

[orf]

b2vjfvj75gjx7 schreef op zaterdag 21 januari 2017 @ 17:28:
[...]


http://deathgrunt.com/tmp/svg/

...nu werkt het script ook, vanaf een pagina met het logo als image

Overigens zonder Greensock, je kan hem gewoon als object aanroepen...

Eh, dat is een <object> geen <img>.

[b2vjfvj75gjx7]

orf schreef op zaterdag 21 januari 2017 @ 17:29:
[...]


Eh, dat is een <object> geen <img>.

Klopt, dat staat er toch?

IMG kan ook, dan laad je een extra asset in... maar goed; het gaat er niet om dat het kan / of het kan - maar dat ze blijkbaar geen audit doen op de code van de images...

[orf]

b2vjfvj75gjx7 schreef op zaterdag 21 januari 2017 @ 17:32:
[...]


Klopt, dat staat er toch?

IMG kan ook, dan laad je een extra asset in... maar goed; het gaat er niet om dat het kan / of het kan - maar dat ze blijkbaar geen audit doen op de code van de images...

Beetje gek verloop:

A: In een <img> kan geen <script>
B: Jawel
B: Kijk maar: <object>
A: Dat is geen <img>
B: Klopt, dat staat er ook.

Als een logo in een <img> tag gebruikt wordt, dan is er geen veiligheidsrisico op het gebruik van javascript. Natuurlijk kun je dan een andere asset inladen om javascript te gebruiken, maar dat lijkt me nogal logisch.

[b2vjfvj75gjx7]

orf schreef op zaterdag 21 januari 2017 @ 17:35:
[...]


Beetje gek verloop:

A: In een <img> kan geen <script>
B: Jawel
B: Kijk maar: <object>
A: Dat is geen <img>
B: Klopt, dat staat er ook.

Als een logo in een <img> tag gebruikt wordt, dan is er geen veiligheidsrisico op het gebruik van javascript. Natuurlijk kun je dan een andere asset inladen om javascript te gebruiken, maar dat lijkt me nogal logisch.

Het gaat om de theorie bij beveiliging;

Desnoods knal je het logo zonder wrapper in een iFrame...

Maar waar het vooral om gaat;

- Geen audit op assets
- Geen audit op externe / third-party scripts
- Geen audit op cross-protocol traffic
- Geen audit op non-valuable scripting (http)

Of je dan een script actief kan draaien in een plaatje, waarvan niemand ooit de code gecontroleerd heeft, lijkt me minder van belang; je moet gewoon nooit accepteren dat er code op je server staat - die niemand heeft ingezien.

- edit -

Als je javascript uitzet in de backend, weigert de site zelfs dienst...



Dus men verplicht je om javascript te draaien, wil je iets met je geld kunnen doen.

[ Voor 10% gewijzigd door b2vjfvj75gjx7 op 21-01-2017 17:48 ]

[orf]

Dat is me te kort door de bocht. Dat de SVG niet geoptimaliseerd is voor de kleinste bestandsgrootte, zegt helemaal niets over een audit. Het gebruik van SVG's voor logo's is good practice en er is geen extra risico boven PNG, GIF of JPG als een SVG in een <img> tag wordt gebruikt.

Dat er op deze manier om wordt gegaan met externe scripts is een slechte zaak. Dat zou bij een bank niet voor mogen komen en daar zou op ge-audit moeten worden.

Ik kan de website niet bekijken. Waarschijnlijk wordt alles ingeladen via tagmanager. Dat zie ik wel vaker; tagmanager in handen van de afdeling marketing. Dat is onhandig en levert flinke veiligheidsrisico's op.

[b2vjfvj75gjx7]

orf schreef op zaterdag 21 januari 2017 @ 17:49:
Dat is me te kort door de bocht. Dat de SVG niet geoptimaliseerd is voor de kleinste bestandsgrootte, zegt helemaal niets over een audit. Het gebruik van SVG's voor logo's is good practice en er is geen extra risico boven PNG, GIF of JPG als een SVG in een <img> tag wordt gebruikt.

Dat er op deze manier om wordt gegaan met externe scripts is een slechte zaak. Dat zou bij een bank niet voor mogen komen en daar zou op ge-audit moeten worden.

Ik kan de website niet bekijken. Waarschijnlijk wordt alles ingeladen via tagmanager. Dat zie ik wel vaker; tagmanager in handen van de afdeling marketing. Dat is onhandig en levert flinke veiligheidsrisico's op.

Helemaal mee eens.

Maar SVG is en blijft een risico;

- https://bjornjohansen.no/svg-in-wordpress
- https://blog.mozilla.org/...-animation-vulnerability/
- https://acloudtree.com/20...ulnerability-in-plotlyjs/

Niet als je het goed monitort, maar wel als je het zonder te kijken op je server gooit...

- edit -

Tweakers doet het gelukkig wel goed; https://ic.tweakimg.net/images/shield/80.svg

[ view-source ]

[ Voor 5% gewijzigd door b2vjfvj75gjx7 op 21-01-2017 17:59 ]

[mgizmo]

Ja aantal zaken viel mij ook al op (zoals de OTAP url's en veel scripts (ik blokkeer ze in mijn Sophos UTM). Ik ben dan geen programmeur, maar kan het wel gedeeltelijk lezen. Ik kijk vooral met mijn network security achtergrond er naar en dan verbaas ik mij ook hierover.

Dank dat je het zo hoog hebt kunnen krijgen!

[b2vjfvj75gjx7]

mgizmo schreef op zaterdag 21 januari 2017 @ 20:51:
Ja aantal zaken viel mij ook al op (zoals de OTAP url's en veel scripts

OTAP / DTAP (voor de Engelstaligen onder ons) is inderdaad een ding daar.

Natuurlijk kan ik absoluut niet in de broncode kijken, maar als ik "tussen de regels door" lees zit er wel goed wat mis daar;

- http inladen via https
- geen audit op broncode images
- third party scripts inladen in een persoonlijke backend
- otap / dtap merged in de source code
- etc...

Dat doe je gewoon niet, en zeker niet bij een bank...

[mgizmo]

b2vjfvj75gjx7 schreef op zaterdag 21 januari 2017 @ 21:17:
[...]


OTAP / DTAP (voor de Engelstaligen onder ons) is inderdaad een ding daar.

Natuurlijk kan ik absoluut niet in de broncode kijken, maar als ik "tussen de regels door" lees zit er wel goed wat mis daar;

- http inladen via https
- geen audit op broncode images
- third party scripts inladen in een persoonlijke backend
- otap / dtap merged in de source code
- etc...

Dat doe je gewoon niet, en zeker niet bij een bank...

Volledig met je eens. Ik heb in die sector gewerkt (nu even freelance opdracht bij overheid) en ik ken het ook zo niet. Alsof ze geen CERT en CISO's hebben.

[b2vjfvj75gjx7]

orf schreef op zaterdag 21 januari 2017 @ 17:49:
Ik kan de website niet bekijken. Waarschijnlijk wordt alles ingeladen via tagmanager. Dat zie ik wel vaker; tagmanager in handen van de afdeling marketing. Dat is onhandig en levert flinke veiligheidsrisico's op.

Klopt - als ik Fiddler los laat op de site, zie je veel (verborgen) funnels naar Google Tag Manager;

Die beheert dus alle scripts van zowel Google, KNAB als externe partijen.

Als die tag-manager omvalt, hebben ze dus een situatie zo lek als een mandje...

[ Voor 5% gewijzigd door b2vjfvj75gjx7 op 22-01-2017 16:59 ]

[mannowlahn]

b2vjfvj75gjx7 schreef op vrijdag 20 januari 2017 @ 18:22:
[...]


Ik heb het aanhangig gemaakt bij de escalatie-manager van [de bank]... dus ik wacht eerst die af...

Deze thread is meer privé bedoelt (voor mijzelf) en gaat over de principiële vraag of het correct is dat ze die dingen inladen...

Ik denk dat het best wel goed is dat dit hier ook meldt. Want voor mij zou het een reden zijn om die bank niet meer te gebruiken. For fuck sake, social tracking op een bank omgeving? Welke crackhead heeft dat verzonnen?

[Brent]

muffstuff schreef op maandag 23 januari 2017 @ 16:54:
[...]

Ik denk dat het best wel goed is dat dit hier ook meldt. Want voor mij zou het een reden zijn om die bank niet meer te gebruiken. For fuck sake, social tracking op een bank omgeving? Welke crackhead heeft dat verzonnen?

Security-minded webdevs zijn zeldzame beestjes

[mannowlahn]

Brent schreef op maandag 23 januari 2017 @ 16:57:
[...]

Security-minded webdevs zijn zeldzame beestjes

Ik heb nu de rest van dit topic gelezen, maar ik moet eerlijk gezegd mijn mening wel bijstellen.

Dit is niet een kleine bug of fout. Dit is moedwillig compleet een bord voor de kop hebben. Serieus, wie is in godsnaam verantwoordelijk bij KNAB voor de portal? Die persoon zouden ze per direct op non actief moeten stellen. maar ja, banken en verantwoordelijkheid

[Basszje]

Brent schreef op maandag 23 januari 2017 @ 16:57:
[...]

Security-minded webdevs zijn zeldzame beestjes

Meestal is het ' marketing-manager met half idee >> webdev-volk ' als het gaat om wie er wint in de brainstorm-tombolo

[F_J_K]

Alias gemaakt in forum B&V.

En inhoudelijk: ik ben al een tijd tevreden klant van KNAB, maar ben blij dat ik NoScript laat meelopen

[ Voor 59% gewijzigd door F_J_K op 23-01-2017 17:43 ]

[Brent]

F_J_K schreef op maandag 23 januari 2017 @ 17:42:
Alias gemaakt in forum B&V.

En inhoudelijk: ik ben al een tijd tevreden klant van KNAB, maar ben blij dat ik NoScript laat meelopen

Het komt niet eens in me op zonder een banksite te bezoeken.

[Baserk]

Wat een thread zeg, mozes kriebel. Mooi hoor deathgrunt.
Noscript/uMatrix idd.

[b2vjfvj75gjx7]

F_J_K schreef op maandag 23 januari 2017 @ 17:42:
Alias gemaakt in forum B&V.

En inhoudelijk: ik ben al een tijd tevreden klant van KNAB, maar ben blij dat ik NoScript laat meelopen

Zonder Javascript werkt de site van KNAB niet (zie opmerking hierboven; ze gooien dan een modal / overlay over de site met de melding dat je een moderne browser moet zoeken).

Overigens kan je die modal via de console gewoon uit de DOM verwijderen; dan doet de site het half - maar navigatie / zoeken / etc... werkt dan niet (dus je hebt er weinig aan).

Als je vervolgens wel Javascript toelaat, maar trackers blokt (zoals ik doe via Ghostery in anonymous mode) - dan kan je de site wel gebruiken, maar werken rudimentaire zaken als bv. je adresboek niet (adresboek van KNAB, that is).

Om die reden heb ik Ghostery even gepauzeerd, de console aangeslingerd en toen zag ik inderdaad dat er +/- 35 tracking-scripts van third-parties (waaronder via regulier HTTP) werden ingeladen...

Overigens was ik vandaag (dacht ik) wel weer gebeld door KNAB (ik neem aan om een status-update te geven), maar eigenlijk neem ik mijn telefoon nooit op... ik communiceer liever digitaal

(oftewel; ik kan zelf geen status-update posten...).

[ Voor 10% gewijzigd door b2vjfvj75gjx7 op 23-01-2017 19:11 ]

[F_J_K]

b2vjfvj75gjx7 schreef op maandag 23 januari 2017 @ 19:09:
Zonder Javascript werkt de site van KNAB niet (zie opmerking hierboven; ze gooien dan een modal / overlay over de site met de melding dat je een moderne browser moet zoeken).

Als je vervolgens wel Javascript toelaat, maar trackers blokt (zoals ik doe via Ghostery in anonymous mode) - dan kan je de site wel gebruiken, maar werken rudimentaire zaken als bv. je adresboek niet (adresboek van KNAB, that is).

Alle scripts blokkeren is wat overdreven, maar alleen die van KNAB.nl toestaan kan best. Zonder adresboek leven kan wel.

[b2vjfvj75gjx7]

F_J_K schreef op maandag 23 januari 2017 @ 19:12:
[...]

Alle scripts blokkeren is wat overdreven, maar alleen die van KNAB.nl toestaan kan best. Zonder adresboek leven kan wel.

Ik heb ook geen moeite met scripts - ik heb moeite met HTTP scripts op een banksite en third-party trackers, aangeslinderd via de Tag Manager van Google (als iemand daar toegang toe heeft, kan hij dus gewoon <insert here> scripts injecteren in de back-end van KNAB).

Een Tag Manager gebruiken voor een banken-site lijkt mij gewoon bad-practice (en ik ben striptekenaar, geen developer).

GA zou ik nog wel accepteren (al blok ik die), maar screencapture-scripts, tag-managers, facebook, twitter, video-platformen, etc... wil ik niet terugzien in de back-end (plus het gebrek aan audits op de source-code van images, development-comment in de product-versie van de site, etc...).

- edit - Adresboek is juist wel handig... daar gooi ik de Belastingdienst direct in, zodat ik OB en IB blind kan betalen

[ Voor 6% gewijzigd door b2vjfvj75gjx7 op 23-01-2017 19:15 ]

[F_J_K]

HTTP is sowieso een doodzonde, maar ook via HTTPS any 3P-script of -object zou IMHO (maar ik ben Powerpointtijger) niet moeten bij een banksite. Het geeft ingangen die niet nodig zijn. Certificaten en versleuteling zijn geen garanties maar een extra hoepel.

[b2vjfvj75gjx7]

F_J_K schreef op maandag 23 januari 2017 @ 19:21:
Het geeft ingangen die niet nodig zijn.

Dat is exact mijn issue;

Het is niet zo dat de site momenteel extreem onveilig is... maar wel zo dat hij potentieel onveilig kan zijn / worden;

Je laadt 35 scripts in van derden; als één van die externe servers "gehacked" wordt (mode-woord, ik weet het...) dan laad je dus malafide code in je bank-omgeving, zonder dat je het weet.

Google zal zijn security wel op orden hebben (assumption / fuck up - I know), maar bv. die gasten die screen-recording-tools maken (van je financiële gegevens?!) of dat leuke interactieve-video-platform... die zullen minder op security gefocussed zijn.

En die scripts zijn niet nodig voor de core-business; je geld beheren en zaken doen...

Dus ik zou ze weglaten - net als bv. het .SVG bestand van hun logo.

Natuurlijk is .SVG niet zo lek als een mandje, maar het is wel een attack-vector - en daarvan heb je er in je bank-omgeving het liefst zo min mogelijk;

ABN AMRO / ING (waar ik ook rekeningen heb) laden enkel GA in, werken zonder Javascript en zijn toch snel / modern / zakelijk / UA / UX... dus het kan gewoon.

[Freee!!]

Fijn om dit te weten, voorlopig geen rekening bij KNAB.

[mcDavid]

Haha nou had ik toch al weinig behoefte aan een KNAB-rekening gezien ze qua investeringen gewoon het wanbeleid van Aegon volgen, maar dit is ook wel erg knullig inderdaad. Zo'n gigantische attack surface introduceren wil je eigenlijk op geen enkele website, laat staan op een bankwebsite...

[b2vjfvj75gjx7]

Freee!! schreef op maandag 23 januari 2017 @ 19:40:
Fijn om dit te weten, voorlopig geen rekening bij KNAB.

Ze gingen er wel mee aan de slag, dus ik wacht even af

Het is niet zo dat je geld opeens via Nigeria (scam) wordt weggesluisd daar, maar wel zo dat ik me afvroeg of die site code-technisch nu wel zo netjes in elkaar steekt.

Eigenlijk kan je daar pas antwoord op geven, na een onafhankelijke audit - ik ben niet bij machte dat te doen.

[Brent]

Overigens een van de redenen dat ik niets van al die bank-apps moet hebben. Dat kan precies dezelfde javascript inladen maar is een stuk lastiger te achterhalen

[b2vjfvj75gjx7]

Brent schreef op maandag 23 januari 2017 @ 19:51:
Overigens een van de redenen dat ik niets van al die bank-apps moet hebben. Dat kan precies dezelfde javascript inladen maar is een stuk lastiger te achterhalen

Bank-apps gebruik ik per definitie niet, inderdaad... ik wil wel zien wat er "onder water" gebeurt (F12 - console - Fiddler - Whireshark).

Ander voordeel is dat ik W10M heb, daar zijn toch geen (banken-) apps voor - lekker veilig

Modbreak:

Ik heb even wat reacties van je verwijderd omdat je meermaals posts onder elkaar zet. Dat is niet de bedoeling op GoT. Gebruik de wijzig-knop boven de post als je iets wilt toevoegen.

[ Voor 15% gewijzigd door Krisp op 24-01-2017 08:16 ]

[DJMaze]

En er is ook een stiekeme: https://eum.knab.nl/eumco...wser/v1/EUM-AAB-AUA/adrum
Er wordt data gepost naar AppDynamics

[mannowlahn]

b2vjfvj75gjx7 schreef op maandag 23 januari 2017 @ 19:53:
[...]


Bank-apps gebruik ik per definitie niet, inderdaad... ik wil wel zien wat er "onder water" gebeurt (F12 - console - Fiddler - Whireshark).

Ander voordeel is dat ik W10M heb, daar zijn toch geen (banken-) apps voor - lekker veilig
[modbreak]Ik heb even wat reacties van je verwijderd omdat je meermaals posts onder elkaar zet. Dat is niet de bedoeling op GoT. Gebruik de wijzig-knop boven de post als je iets wilt toevoegen.[/]

ING is toch gewoon beschikbaar? https://www.microsoft.com...ng-bankieren/9wzdncrfhv51

[Hydra]

b2vjfvj75gjx7 schreef op vrijdag 20 januari 2017 @ 18:11:
• WTF doen Facebook en Twitter daar? *)

Een of andere pruts PO heeft bedacht dat ze een like button nodig hebben en niemand heeft 'em dat uit z'n verstand kunnen praten. Stel je toch eens voor dat van je honderdduizend klanten er eentje op 't idee komt dat 'ie z'n bank wil liken.

Ik zou er vooral luid over klagen. Er is veel concurrentie bij banken en ze nemen klachten via social media erg serieus. Bron: ik werk bij de ING en die neemt 't erg serieus

b2vjfvj75gjx7 schreef op maandag 23 januari 2017 @ 19:53:
Bank-apps gebruik ik per definitie niet, inderdaad...

Die zijn anders gemiddeld een stuk veiliger dan je websites. Een mobile app interface spoofen is een stuk lastiger (niet onmogelijk mind you) dan een web app en daarnaast is de verbinding vaak beter beveiligd.

[ Voor 24% gewijzigd door Hydra op 24-01-2017 14:56 ]

[Brent]

Hydra schreef op dinsdag 24 januari 2017 @ 14:55:
[...]

Die zijn anders gemiddeld een stuk veiliger dan je websites. Een mobile app interface spoofen is een stuk lastiger (niet onmogelijk mind you) dan een web app en daarnaast is de verbinding vaak beter beveiligd.

Tenzij de source publiek is, zijn dit niets meer dan aannames. Hoe ging het gezegde ook alweer, security through obscurity is no ... Bovendien is Android (bijv) ook niet bepaald gekend om zijn veiligheid.

[Hydra]

Brent schreef op dinsdag 24 januari 2017 @ 15:22:
Tenzij de source publiek is, zijn dit niets meer dan aannames.

Daar verkijk je je op. Ik weet helaas niet precies wat ik wel en niet en plein public mag vertellen over de (back-end van) de app waaraan ik gewerkt heb en die waar ik nu aan werk maar het is geen 'security by obscurity'. Er zitten een paar erg slimme mechanismen in wat betreft het establishen van trust die een stukje verder gaan dan de SSL die ook gebruikt wordt. En de meeste pentesters die ingehuurd worden komen al niet langs de basale certificate pinning.

[F_J_K]

Hydra schreef op dinsdag 24 januari 2017 @ 15:52:
Daar verkijk je je op. Ik weet helaas niet precies wat ik wel en niet en plein public mag vertellen over de (back-end van) de app waaraan ik gewerkt heb en die waar ik nu aan werk maar het is geen 'security by obscurity'. Er zitten een paar erg slimme mechanismen in wat betreft het establishen van trust die een stukje verder gaan dan de SSL die ook gebruikt wordt. En de meeste pentesters die ingehuurd worden komen al niet langs de basale certificate pinning.

offtopic:
De gedachte is: er is sprake van obscurity omdat wij dat niet weten. Wij zien alleen een smoel
Wat overigens niet eens per se waar is, aangezien we er zelf een sniffer kunnen zetten, al dan niet incl. self signed certificates.

[Brent]

Hydra schreef op dinsdag 24 januari 2017 @ 15:52:
[...]


Daar verkijk je je op.

Nope

Ik weet helaas niet precies wat ik wel en niet en plein public mag vertellen over de (back-end van) de app waaraan ik gewerkt heb en die waar ik nu aan werk maar het is geen 'security by obscurity'.

Precies om die reden is het voor elke gebruiker dus 'through obscurity'. Als ik niets kan verifiëren, moet ik je vertrouwen en is het dus niet open maar obscuur. Het point of view van de ontwikkelaar is voor ons als gebruikers natuurlijk volkomen irrelevant.

[Hydra]

Brent schreef op dinsdag 24 januari 2017 @ 16:15:
Precies om die reden is het voor elke gebruiker dus 'through obscurity'.

Euh nee. Security by obscurity heeft niks met eindgebruikers te maken. Het slaat op het gebruik van gegoochel om de werking van het systeem te verhullen in plaats van het gebruik van echte beveiliging. Security by obscurity vertraagt een aanvaller alleen maar, het verhindert geen aanval.

Dat het voor een eindgebruiker niet transparant is, is een ander verhaal.

[Brent]

Hydra schreef op dinsdag 24 januari 2017 @ 16:36:
[...]


Euh nee. Security by obscurity heeft niks met eindgebruikers te maken.

STO in cryptografische zin, AKA Wikipedia: Kerckhoffs's principle. Zie ook de Security through obscurity paragraaf in bovenstaand artikel: het is het meest zinvol om erover te denken als een vertrouw-nooit-op-geheimen maxime.

Software met bergen bugs op een schijf begraven in het bos is 100% veilig. Het concept veiligheid kan dus alleen gaan spelen op het moment dat het gebruikt wordt. Onderscheid tussen dev en gebruiker is verkeerd, omdat dat veronderstelt dat een gebruiker niet bij de code kan. Dat heet closed source software, en dan is het per definitie obscuur. Deze notie is dus in feite een vorm van STO

Overigens is dit topic in de security wereld geen onderwerp van discussie meer, terwijl er veel 'professionals' toch nog steeds niet echt begrijpen waarom closed source onveiligheid vergroot ipv verkleind.

[Hydra]

Brent schreef op dinsdag 24 januari 2017 @ 18:24:
STO in cryptografische zin, AKA Wikipedia: Kerckhoffs's principle. Zie ook de Security through obscurity paragraaf in bovenstaand artikel: het is het meest zinvol om erover te denken als een vertrouw-nooit-op-geheimen maxime.

Je had het over gebruikers. Je kunt gaan gooien met Wikipedia artikelen maar security by obscurity gaat gewoon simpel over dat je niet moet leunen op dat de aanvaller niet weet hoe je systeem werkt, wat letterlijk in dat artikel gezegd wordt nota bene. Het gaat niet om of je beveiliging transparant is voor je gebruikers.

Dat heet closed source software, en dan is het per definitie obscuur.

Ik ben 100% pro open source maar closed source betekent niet dat een applicatie per definitie onveiliger is. Dan neem je Raymond's "the cathedral and the bazaar" iets the letterlijk.

Daarnaast heeft ook dit niks met security through obscurity te maken. Misschien is de Nederlandse vertaling makkelijker: "veiligheid door middel van onbekendheid". Er is niks mis met het het lastiger maken van de aanvaller door te verhullen wat je doet, zolang het maar niet is waar het systeem op leunt. Android apps worden over 't algemeen ook obfuscated; dit maakt het lastiger voor een aanvaller. Maar dit is niet waar android banking apps op leunen; de beveiliging is gewoon sterke cryptografie / certificates. Opzettelijke obscurity is daar boven op gelegd, het is niet "door middel van".

[ Voor 37% gewijzigd door Hydra op 25-01-2017 09:18 ]

[Brent]

Hydra schreef op woensdag 25 januari 2017 @ 09:12:
[...]


Je had het over gebruikers. Je kunt gaan gooien met Wikipedia artikelen maar security by obscurity gaat gewoon simpel over dat je niet moet leunen op dat de aanvaller niet weet hoe je systeem werkt, wat letterlijk in dat artikel gezegd wordt nota bene. Het gaat niet om of je beveiliging transparant is voor je gebruikers.

Waar 'je' is gebruiker, niet ontwikkelaar. Hence closed source equals STO.

[...]


Ik ben 100% pro open source maar closed source betekent niet dat een applicatie per definitie onveiliger is. Dan neem je Raymond's "the cathedral and the bazaar" iets the letterlijk.

Hier zie ik het verband niet? Dat gaat over een ontwikkelstijl, terwijl het argument dat ik aanhaalde over beschikbaarheid en verifieerbaarheid van een door een dev ontwikkelde code gaat.

[b2vjfvj75gjx7]

Kleine update;

Ik had ontdekt dat ze op zowel de front- als backend ook een (extra) vaag script inladen van een (nieuwe) feedback company uit Nijmegen (met een fake adres in Amerika).

Dat loopt via een WordPress site, die via obfuscating zich voordoet als "niet WordPress" - ik had hiervan code-samples, ed... als "bewijs" getoond (maar die zijn weggehaald, omdat ik 4 posts onder elkaar er aan had besteed - wat verder geen issue is).

Van de bank zelf heb ik niets gehoord, behalve dat ik nog gebeld word - maar ik neem dat nummer nooit op; ik heb geen telefoon om te bellen, maar om te developen (mail / Slack / Skype / Basecamp / WA / reddit / Redmine zijn 100% - 24/7 actief hier).

Qua codes is er verder niets veranderd; 1x inloggen en je krijgt 35 (inmiddels 36) externe trackers achter je aan.

[mannowlahn]

b2vjfvj75gjx7 schreef op woensdag 25 januari 2017 @ 23:05:
Kleine update;

Ik had ontdekt dat ze op zowel de front- als backend ook een (extra) vaag script inladen van een (nieuwe) feedback company uit Nijmegen (met een fake adres in Amerika).

Dat loopt via een WordPress site, die via obfuscating zich voordoet als "niet WordPress" - ik had hiervan code-samples, ed... als "bewijs" getoond (maar die zijn weggehaald, omdat ik 4 posts onder elkaar er aan had besteed - wat verder geen issue is).

Van de bank zelf heb ik niets gehoord, behalve dat ik nog gebeld word - maar ik neem dat nummer nooit op; ik heb geen telefoon om te bellen, maar om te developen (mail / Slack / Skype / Basecamp / WA / reddit / Redmine zijn 100% - 24/7 actief hier).

Qua codes is er verder niets veranderd; 1x inloggen en je krijgt 35 (inmiddels 36) externe trackers achter je aan.

Dan is het wellicht tijd om dit aan een grotere klok te hangen.

Ik blijf erbij, dit is niet een klein dingetje. De gevolgen hiervan kunnen enorm groot zijn. Hoe ironisch het ook is, een bank valt of staat bij vertrouwen. Wanneer een bank moedwillig dit soort scriptjes gaat inladen op een persoonlijk pagina waar gevoelige data staat. Dan moet deze bank zsm ter orde geroepen worden.

Als ik linkedn er even bij pak, zie ik nauwelijks medewerkers op het gebied van IT. Welke partij doet de automatisering van KNAB? Ik zie wel een medewerker ict coordinator die in nijmagen zit. Toevallig een vriendje van die vage partij uit Nijmegen?

en wordpress bij een digitale bank. Serieus, dit valt toch onder de noemer faalhazen hoor.

[ Voor 3% gewijzigd door mannowlahn op 26-01-2017 10:26 ]

[AW_Bos]

Ik ben zelf geen klant bij deze 'omgedraaide' bank, maar ik heb ze eens met een Tweetje op dit topic geattendeerd, met reactie tot gevolg. Dit omdat ik ook behoorlijk geschrokken ben van het aantal tracking-cookies en domeinen waarnaar requests worden gedaan voor zo'n belangrijke financieel administratieve omgeving.

we hebben direct na dat bericht veel aanpassingen gedaan. Lijstje zou een stuk kleiner moeten zijn: https://bit.ly/2jLXsVG ^DH

[b]muffstuff schreef op donderdag 26 januari 2017 @ 10:24:
en wordpress bij een digitale bank. Serieus, dit valt toch onder de noemer faalhazen hoor.

Waar zie je Wordpress? Ik zie wel soortgelijke linkjes naar templatesets en js-assets etc.
Maar is het misschien niet zo dat ze bij het inloggen dan verwijzen naar hun styles die hun wordpress-backend gebruikt, terwijl het inloggen op totaal een andere omgeving draait?

Klagen dat ze Wordpress gebruiken mag, maar kom eerst eens met grote bewijzen voordat je dat roept .

[ Voor 38% gewijzigd door AW_Bos op 26-01-2017 10:29 ]

[Hooglander1]

b2vjfvj75gjx7 schreef op woensdag 25 januari 2017 @ 23:05:
Van de bank zelf heb ik niets gehoord, behalve dat ik nog gebeld word - maar ik neem dat nummer nooit op

Dan kun je ook moeilijk verwachten dat je er nog iets van hoort lijkt me...

AW_Bos schreef op donderdag 26 januari 2017 @ 10:26:
Ik ben zelf geen klant bij deze 'omgedraaide' bank, maar ik heb ze eens met een Tweetje op dit topic geattendeerd, met reactie tot gevolg. Dit omdat ik ook behoorlijk geschrokken ben van het aantal tracking-cookies en domeinen waarnaar requests worden gedaan voor zo'n belangrijke financieel administratieve omgeving.


[...]

Goede actie En goed om te horen dat ze het snel opgepakt hebben.

[mannowlahn]

AW_Bos schreef op donderdag 26 januari 2017 @ 10:26:
Ik ben zelf geen klant bij deze 'omgedraaide' bank, maar ik heb ze eens met een Tweetje op dit topic geattendeerd, met reactie tot gevolg. Dit omdat ik ook behoorlijk geschrokken ben van het aantal tracking-cookies en domeinen waarnaar requests worden gedaan voor zo'n belangrijke financieel administratieve omgeving.


[...]

Dat dateert van 3 dagen geleden, blijkbaar is het nog steeds niet opgelost. Die ceo kan je weinig kwalijk nemen, die vertrouwd er op dat alles correct is. Al hoewel, worden er geen IT audits gedaan, vanuit de AFM/nederlandse bank? Hoe kan dit in godsnaam uberhaupt produktie hebben gezien?

[mannowlahn]

AW_Bos schreef op donderdag 26 januari 2017 @ 10:26:

Waar zie je Wordpress? Ik zie wel soortgelijke linkjes naar templatesets en js-assets etc.
Maar is het misschien niet zo dat ze bij het inloggen dan verwijzen naar hun styles die hun wordpress-backend gebruikt, terwijl het inloggen op totaal een andere omgeving draait?

Klagen dat ze Wordpress gebruiken mag, maar kom eerst eens met grote bewijzen voordat je dat roept .

Zie bericht deathgrunt waarin hij aangeeft dat er een referentie naar een website staat, die met veel moeite gecamoufleerd wordt omdat het een wordpress site is.

[Rukapul]

We hebben een mooi BV forum waar dit eigenlijk beter thuishoort: PFSL -> BV

Hydra schreef op dinsdag 24 januari 2017 @ 14:55:
Die zijn anders gemiddeld een stuk veiliger dan je websites. Een mobile app interface spoofen is een stuk lastiger (niet onmogelijk mind you) dan een web app en daarnaast is de verbinding vaak beter beveiligd.

Die afweging ligt iets genuanceerder. Je moet namelijk ook aannames doen over veiligheid van het onderliggende platform en dat is helaas bij veel (Android) systemen beroerd. Een fundamenteler bezwaar bij ING is dat een bank app op de telefoon principieel strijdig is met het gebruik van datzelfde device als out-of-band communicatie voor 2-factor. Je moet beveiligingsconcepten eenduidig houden.

Maargoed: het ging hier over KNAB en die maken er echt een rommeltje van met al die included scripts. Clueless. Je vraagt je af of er een product security officer en een security architect in dienst is, inclusief MT vertegenwoordiging via een CISO.

KNAB kan zo niet claimen een veilige bankomgeving te bieden. En ondanks hun flinke SEO zal dat binnenkort ook wel in Google bovendrijven.

[ Voor 7% gewijzigd door Rukapul op 26-01-2017 10:37 ]

[mannowlahn]

Rukapul schreef op donderdag 26 januari 2017 @ 10:33:
[mbr]We hebben een mooi BV forum waar dit eigenlijk beter thuishoort: PFSL -> BV[/]

[...]


Maargoed: het ging hier over KNAB en die maken er echt een rommeltje van met al die included scripts. Clueless. Je vraagt je af of er een product security officer en een security architect in dienst is, inclusief MT vertegenwoordiging via een CISO.

ik heb de 173 personen nagelopen die via linkedin aangeven werkzaam te zijn bij KNAB. Ik zie een hoop sociale media mensen, maar weinig tot niets dat wijst op het feit dat dit in house gemaakt wordt.

[mcDavid]

Rukapul schreef op donderdag 26 januari 2017 @ 10:33:
[mbr]We hebben een mooi BV forum waar dit eigenlijk beter thuishoort: PFSL -> BV[/]

[...]

Die afweging ligt iets genuanceerder. Je moet namelijk ook aannames doen over veiligheid van het onderliggende platform en dat is helaas bij veel (Android) systemen beroerd.

Het zelfde kan gezegd worden van een PC, genoeg draaien er nog op window XP of Vista. Of zijn geinfecteerd met virussen/spyware zonder dat ze het weten. Dit is meer de verantwoordelijkheid van de gebruiker dan van de softwareleverancier imo

Een fundamenteler bezwaar bij ING is dat een bank app op de telefoon principieel strijdig is met het gebruik van datzelfde device als out-of-band communicatie voor 2-factor.

Dat valt prima af te vangen door bijv. een identifier of biometrie te gebruiken.

[F_J_K]

Er lijkt technisch een en ander aan te schorten (en 'dus' ook organisatorisch) qua beveiliging, maar laten we er overigens geen KNAB-bash topic van maken

Rukapul schreef op donderdag 26 januari 2017 @ 10:33:
We hebben een mooi BV forum waar dit eigenlijk beter thuishoort: PFSL -> BV

Dan haal ik de alias er even weg, anders echo'd het er zo.

[ Voor 13% gewijzigd door F_J_K op 26-01-2017 10:40 . Reden: er schijnt geen e in qua te zitten. ]

[Hydra]

Rukapul schreef op donderdag 26 januari 2017 @ 10:33:
Die afweging ligt iets genuanceerder. Je moet namelijk ook aannames doen over veiligheid van het onderliggende platform en dat is helaas bij veel (Android) systemen beroerd. Een fundamenteler bezwaar bij ING is dat een bank app op de telefoon principieel strijdig is met het gebruik van datzelfde device als out-of-band communicatie voor 2-factor. Je moet beveiligingsconcepten eenduidig houden.

Een veelvoorkomende manier van aanvallen is mensen SMS interceptors laten installeren op hun device. Hiermee worden die TAN codes dan afgevangen. ING houdt hier rekening mee; een deel van het 'gebruiksgemakt' levert gewoon risico's op die door de bank opgevangen worden.

[b2vjfvj75gjx7]

muffstuff schreef op donderdag 26 januari 2017 @ 10:24:
[...]
Als ik linkedn er even bij pak, zie ik nauwelijks medewerkers op het gebied van IT. Welke partij doet de automatisering van KNAB? Ik zie wel een medewerker ict coordinator die in nijmagen zit. Toevallig een vriendje van die vage partij uit Nijmegen?

en wordpress bij een digitale bank. Serieus, dit valt toch onder de noemer faalhazen hoor.

Geen idee, ik besteed er niet zo veel tijd meer aan;

"We" hebben iets van 35 vage / overbodige scriptjes bloot-gelegd dus nu is de bank aan zet, vind ik...

Overigens ging het om deze partij uit Nijmegen die ook weer trackers injecteert (front-end en achter de inlog van de bank); http://www.blueconic.net

De status van hun API kan je hier uitlezen; https://knab.blueconic.net

Overigens is díe site gewoon WordPress; daar is niets mis mee, zolang de trackers maar niet geserveerd worden vanaf dezelfde server als de corporate site (WordPress is leuk, maar zou ik nooit inzetten voor tracking, natuurlijk).

Ze draaien een .htaccess-slug-redirect-ding waardoor het lijkt alsof het geen WordPress is, maar ik ken toevallig de anatomie van de server en dus werkt dit allemaal vrolijk door

https://www.blueconic.com/wp-json/

Zelf het themaatje had ik opgespoord, maar kan die even niet terugvinden...

- edit -

Themaatje : https://www.blueconic.com.../blueconic/screenshot.png

AW_Bos schreef op donderdag 26 januari 2017 @ 10:26:
Waar zie je Wordpress? Ik zie wel soortgelijke linkjes naar templatesets en js-assets etc.
Maar is het misschien niet zo dat ze bij het inloggen dan verwijzen naar hun styles die hun wordpress-backend gebruikt, terwijl het inloggen op totaal een andere omgeving draait?

Klagen dat ze Wordpress gebruiken mag, maar kom eerst eens met grote bewijzen voordat je dat roept .

Ik klaag niet, hoor - zet WordPress zelf ook vaak in

Maar mijn berichten daarover waren verwijderd door de admin hier, omdat ik ze onder elkaar had geplakt... foei.

En het gaat dus om een partij die WordPress draait en via (dezelfde?) server hun scripts weer bij KNAB injecteert (tracking-partij nr. 36 - and counting...).

Maar inderdaad; geen bank-bash topic aub... laat men gewoon al die scripts verwijderen en af en toe wat pro-actieve klant-onderzoeken doen...

muffstuff schreef op donderdag 26 januari 2017 @ 10:35:
[...]

ik heb de 173 personen nagelopen die via linkedin aangeven werkzaam te zijn bij KNAB. Ik zie een hoop sociale media mensen, maar weinig tot niets dat wijst op het feit dat dit in house gemaakt wordt.

Klopt - dat werd mij ook gemeld (via de telefoon); een externe partij heeft de site gebouwd, niet in-house.

[ Voor 35% gewijzigd door b2vjfvj75gjx7 op 26-01-2017 18:13 ]

[mannowlahn]

b2vjfvj75gjx7 schreef op donderdag 26 januari 2017 @ 17:09:
[...]


Klopt - dat werd mij ook gemeld (via de telefoon); een externe partij heeft de site gebouwd, niet in-house.

Dan ben ik heel erg benieuwd welke partij dat is geweest. Klant is is koning, dus je bouwt wat men vraagt. Maar ik snap niet dat die partij niet inziet dat dit alleen maar ellende kan opleveren in de toekomst met claims waardoor je meteen klaar bent als bedrijf.

Los daarvan, ben ik wel benieuwd of er regels in Nederland bestaan mbt digitale bancaire omgevingen.

[Rukapul]

muffstuff schreef op vrijdag 27 januari 2017 @ 09:32:
[...]

Dan ben ik heel erg benieuwd welke partij dat is geweest. Klant is is koning, dus je bouwt wat men vraagt. Maar ik snap niet dat die partij niet inziet dat dit alleen maar ellende kan opleveren in de toekomst met claims waardoor je meteen klaar bent als bedrijf.

Een belangrijker vraag die je kunt stellen is of je als online bank je primaire asset met bijbehorende attack surface en risico's eigenlijk wel op afstand kunt laten ontwikkelen.

Los daarvan, ben ik wel benieuwd of er regels in Nederland bestaan mbt digitale bancaire omgevingen.

Niet als je je afvraagt of er een uitgebreide lijst is van preciese technische maatregelen en verboden, maar er is altijd wel een standaard waar tegen gemeten wordt wat erop neerkomt dat datgene gedaan wordt wat redelijkerwijs verwacht mag worden.

Toegepast op deze casus betekent dat dat je moeite zult moeten doen om een ervaren security officer / architect te vinden die inladen van een dozijn+ externe social media tracker scripts in een omgeving voor financiele transacties als good practice zal kwalificeren

[b2vjfvj75gjx7]

UPDATE

Ze laden inmiddels (iets) minder scripts in, maar de gezellige rakkers van Facebook / Visual Website Optimizer en Google Ads (in de back-end van een zakelijke bank, waar je dus voor betaald om in te kunnen loggen?!) zijn nog steeds aanwezig...

---

Refused to load the script "data:application/javascript;base64,[...]"
because it violates the following Content Security Policy directive.

https://content.knab.nl
https://pincodekiezen.knab.nl
https://www.knab.nl
https://ssl.google-analytics.com
https://*.visualwebsiteoptimizer.com
https://cdn.uservoice.com
https://eultrcqa.morningstar.com
https://quadia.webtvframework.com
https://lt.morningstar.com
https://connect.facebook.net
https://www.googletagmanager.com
https://*.inbenta.com
https://*.liveperson.net
https://*.lpsnmedia.net
https://googleads.g.doubleclick.net
https://www.googleadservices.com
https://www.google.com
https://www.google.nl
https://c.flx1.com
https://go.flx1.com
https://at19.net
https://www.at19.net
https://secure.adnxs.com
https://eum.knab.nl

Failed to load those resources: ERR_BLOCKED_BY_CLIENT

[DukeBox]

Zou wel een mooie zijn voor een FP bericht.. misschien ook eens vergelijken met andere banken om te kijken of het nu wel/niet 'gebruikelijk' is.

[ Voor 53% gewijzigd door DukeBox op 28-01-2017 14:24 ]

[b2vjfvj75gjx7]

DukeBox schreef op zaterdag 28 januari 2017 @ 14:23:
Zou wel een mooie zijn voor een FP bericht.. misschien ook eens vergelijken met andere banken om te kijken of het nu wel/niet 'gebruikelijk' is.

Ik heb spaar- / betaal- / beleggings- / privé- / zakelijke- rekeningen bij ongeveer 6 banken;

Niemand laat externe scripts in, in de back-end (soms wel in de front-end, meestal feedback scripts).

Hooguit GA in de back, maar dat is het wel;

Deze bank is echt de enige die (eerst) 35+ en nu 15+ externe scripts injecteert (waar je dus feitelijk geen controle over hebt).

Ik blokkeer alles, maar dat zal een uitzondering zijn...

[jDuke]

Lol, wat grappig, dit was ook mijn constatering bij KNAB toen ik overging, dit was december 2016, aangezien ik geen fatsoenlijk antwoord terug kreeg, en daarna om reactie vroeg het antwoord was, ja we hebben het gemeld maar de manager vindt een reactie niet nodig was het voor mij aanleiding om gelijk weer op te zeggen.Wel jammer aangezien de aangeboden diensten goed waren maar voor een partij die serieus een internet bank wilt zijn gaat dit mij echt te ver. Wat me vooral stak was extern inladen van javascript die mogelijk maakt om mee te kijken en de pagina over te nemen, ja handig voor support maar geen mogelijkheid om dit uit te schakelen.

Mijn 'oude' bank ING heeft dit probleem niet, en de huidige bank (ASN Bank) heeft dit probleem ook niet. Rabobank had het tijd geleden ook niet.

[ Voor 10% gewijzigd door jDuke op 07-02-2017 16:13 ]

[Kecin]

Waarom heeft Tweakers dit nog geen FP item gemaakt ? Ik denk dat het optijd gemeld is, ze zouden er achteraan, maar het valt toch nu al te misbruiken door de genoemde partijen of anderen?

[Not_Disclosed]

Interessante ontdekking. En heel mooi om te zien dat dit absoluut impact heeft gehad. Mijn dank aan Deathgrunt om dit onder de aandacht te brengen.

Telling van externe domeinen van vandaag:
knab.nl
liveperson.net (chat)
lpsnmedia.net (= liveperson)
inbenta.com (search)
google-analytics.com (analytics)
googletagmanager.com (analytics)

[b2vjfvj75gjx7]

Not_Disclosed schreef op woensdag 8 februari 2017 @ 09:13:
Interessante ontdekking. En heel mooi om te zien dat dit absoluut impact heeft gehad. Mijn dank aan Deathgrunt om dit onder de aandacht te brengen.

Telling van externe domeinen van vandaag:
knab.nl
liveperson.net (chat)
lpsnmedia.net (= liveperson)
inbenta.com (search)
google-analytics.com (analytics)
googletagmanager.com (analytics)

Er is inderdaad, weken / maanden na dato, nog niet veel veranderd;

Wat rudimentaire scripts (die toch al niet gebruikt werden) zijn uitgezet, maar een handvol "pings" van je beveiligde omgeving naar third-parties wordt nog steeds getracked en getraced...

...en de rente is ook nog eens verlaagd