Rabobank iDeal-test voor webwinkels lek

Is dit niet een beetje een storm in een glas water? Het is code uit een handleiding. Is deze daadwerkelijk door webwinkels toegepast? En zo ja, hoe vaak is dat gebeurd?

Mocht dit wel echt een probleem blijken te zijn, is er dan een procedure waarmee de organisatie achter iDeal de deelnemende webwinkels regelmatig op lekken controleert? Dit zodat webwinkels die de veiligheid niet serieus nemen kunnen worden afgesloten. Kan zo'n check plaatsvinden voorafgaand aan elke betaling, zodat je als klant weet dat je niet belazert wordt op het moment dat je in de adresbalk https://jeeigenbank.nl ziet staan?

Mosterd na de maaltijd toch? Leuk dat men er op wijst.

Als je Ideal wilt gebruiken dan zal je die code wel moeten gebruiken want het is de enige documentatie die beschikbaar is.
Bij de Rabo en ook de ING is er niemand die je ook maar 1 antwoord kan geven als je vragen hebt.
Ik vind het overigens een vreemd verhaal want als ik de procedure van de verschillende banken naast elkaar leg zie ik weinig verschillen.
Bij de ABN Amro hoef je zelfs geen testen uit te voeren het sturen van een simpele url is daar genoeg om te betalen.

Het probleem is dus dat er geen controle is op het gebruik van de juiste code voor iDeal, waardoor klanten van een foute webwinkel (een die zo stom is om testcode te gebruiken voor de echte winkel) slachtoffer kunnen worden.

Wie zou dat moeten controleren? En wie zijn hier de verantwoordelijken? We leven in een maatschappij waarin we erg afhankelijk zijn van zelfregulering. Maar van die regulering komt weinig terecht. De bank stelt code beschikbaar die lek is, de webwinkel kan het gebruiken in productie terwijl dat niet de bedoeling is en er blijkt geen controle te zijn dat er voor betaling de juiste omgeving/code in gebruik is.

Ik vind dat de organisatie/banken achter iDeal de verantwoordelijkheid heeft om te controleren of de juiste code implementatie wordt gebruikt. Maar die mentaliteit is er in Nederland niet bij de banken. Net als bij automatische incasso laten ze het voorkomen van misbruik over aan het bedrijf dat opdracht geeft om een betaling te verwerken. De banken trekken zich steeds meer terug van hun verantwoordelijkheid om voor een veilig omgeving te zorgen waarin zij de regie hebben over hoe het volk betalingen kan doen. Er is veel aandacht voor skimmen omdat dat populair is in de media, maar voor de overige verantwoordelijkheden loopt men weg.

Ik geef niet de banken de schuld van het gehele probleem: het is een algehele mentaliteit die het in stand houd. Klanten willen niet weten wanneer iets veilig is en slikken wat ze voor zich krijgen, bedrijven willen zo goedkoop en snel mogelijk cashen en nemen geen verantwoordelijkheid. Het risico neemt ieder voor lief.

So what ?
Een oude test/voorbeeld code die uiteraard na ruim 3 jaar lek blijkt te zijn.

Laat eerst maar eens weten hoe (er moet echt nog het eea aangepast worden eer deze oude code werkt) en hoeveel websites het ook daadwerkelijk zo (vout dus) hebben geïmplementeerd...

Tot die tijd is het FUD

even ter verduidelijking:
Fear, uncertainty and doubt
Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken
FUD is een afkorting uit de informatica die staat voor Fear, Uncertainty, and Doubt. In het Nederlands: 'Angst, Onzekerheid en Twijfel'

Het lijkt wel of men puur uit is op sensatie met dit artikel.

Een programmeur die een "goed beveiligde webshop" heeft gebouwd, is slim genoeg om te zien dat het voorbeeld script inderdaad weinig controleert op de inputvelden, en zal nóóit letterlijk de voorbeeldscripts overnemen.

Het is namelijk een voorbeeld script, puur en alleen ter verduidelijking en niet bedoeld om programmeurs bij te scholen op het gebied van beveiliging.
Dit is geen écht schokkend nieuws te noemen. als men inderdaad veel moeite wil gaan doen om de voorbeeld scripts te misbruiken,
loont het meer om de grotere shops te proberen te misbruiken daar is immers meer te halen dan bij de beginnende webwinkels waarvoor iDeal lite bedoeld is.

De iDeal betaling zélf gaat via een beveiligde omgeving van de banken en is niet afhankelijk van de code van de shop die de transactie instuurt mits de berekende checksum (waarvan de manier van samenstellen in het voorbeeld script staat) uiteraard klopt anders kan er géén betaling plaats vinden !

Een geavanceerde (kwaadwillende) hacker, kan dus totaal geen invloed uitoefenen op de daadwerkelijke betaling en zelfs als dit hypothetisch gesteld mogelijk zou zijn, dan zou het een behoorlijk domme hacker zijn : men kan immers alleen iDEAL betalingen ontvangen op een Nederlandse bankrekening met een iDeal aansluitkontrakt,en daarbij zijn sowieso de gegevens bekend van de rekeninghouder die de iDEAL betaling ontvangt. Gevolg : aangifte van oplichting, en uiteraard wordt zijn rekening geblokkeerd.

Al met al, begrijp ik de negatieve berichtgeving als deze totaal niet :laten we toch blij en trots zijn dat we in Nederland voorop lopen met deze veilige manier van betalen via internet (zowel voor de consument als de webwinkelier), en veiliger dan alle andere betaalmethodes die voorheen aanwezig waren !!

Wat ik zo vreemd vind aan ideal lite is dat de eventuele succes url geen argument bevat die gesigned is door de bank. Als je dus een shop maakt die van lite gebruik maakt zit je of met XML processing of met e-mail verificatie. Terwijl door het aanvoegen van een succescode gesigned met de shared key de webshop direct kan vaststellen of de redirect gestuurd is door de bank of niet.