[WEB] Fraudegevoelig lek ligt toch aan iDeal?

[StalieN]

Hallo allemaal,

Van de week was er enige opschudding toen bleek dat een betalingsmodule voor iDeal niet helemaal veilig was ontwikkeld. iDeal was zo vriendelijk geweest om alle iDeal klanten in te lichten over het probleem en te benadrukken dat het probleem in de module zat, dus dat iDeal op zich niets aan te verwijten viel.

Wij hebben voor een klant van ons een webshop ontwikkeld en daarin ook iDeal geimplementeerd. De webshop was intern ontwikkeld, en het iDeal betalingssysteem hebben we aan de hand van uitleg van iDeal geimplementeerd. Toen het bericht van de fraude onze klant bereikte, vroeg hij ons te onderzoeken of dit hem ook kon overkomen. We gingen het proces nalopen en inderdaad, in principe is het mogelijk dat een koper met slechte bedoelingen in de broncode variabelen kon aanpassen alvorens de betalingsprocedure bij iDeal in gang te zetten, met als gevolg dat er een ander bedrag betaald kan worden dan eigenlijk zou moeten. iDeal geeft dus tips ter implementatie die fraudegevoelig zijn. De implementatie zit dan dus wel in de shop, en ligt dus niet aan iDeal, het is echter wel een stukje kant en klare code die dit probleem veroorzaakt.

In tweede instantie gingen we onderzoeken of het probleem wel op te lossen was. Het volgende stappen worden doorgelopen:

• Wanneer de persoonsgegevens in de webshop zijn ingevuld, wordt betaalmethode gekozen.
• Als de klant kiest voor iDeal, wordt de order bevestigd en gaat de klant door een druk op de knop naar de betaalomgeving van iDeal (externe site).
• De betaalomgeving van iDeal vereist van de webshop een unieke winkelcode, ordernummer, nog wat variabelen uiteraard het betaalbedrag.
• Hier zit hem het probleem: de variabelen worden vereist middels _POST variabelen. Dit houdt in dat wij in de webshop de betalingsvariabelen frontend in hidden input fields moeten stoppen en dat dit 'verborgen' formulier met de druk op de knop als POST variabelen naar de betaalomgeving worden gestuurd, om de juiste interface terug te krijgen.
• Dit is natuurlijk zo lek als een mandje. Als ik in de laatste stap in de broncode het bedrag aanpas in de hidden form field en vervolgens overga op betaling, kan ik elk gewenst bedrag afrekenen. iDeal voert geen backend request naar de webshop uit om te controleren of het bedrag wel klopt, na betaling wordt gewoon een bevestiging gestuurd naar de webshop-eigenaar.

De webshopbezoeker kan alleen de juiste betalingsinterface van iDeal voor zijn neus krijgen door de POST variabelen. De structuur is dus niet zo dat de betalingsinformatie backend van webshopserver naar iDealserver worden doorgegeven, waarna de bezoeker middels redirect op de juiste betalingspagina komt. Momenteel is het dus simpelweg vereist dat de betalingsinformatie via de bezoeker terechtkomt bij iDeal, dus voorlangs, dus bevinloedbaar. Een kwalijke zaak lijkt mij, vooral voor webwinkeliers die grote hoeveelheden bestellingen per dag afhandelen en na bevestiging van iDeal niet willen controleren of het betaalde bedrag wel klopt.

Waarom post ik dit hier:

• Is mijn analyse correct of mis ik iets in het proces waardoor de variabelen welzeker achterlangs kunnen worden doorgegeven, zonder tussenkomst van de bezoeker?
• Ben ik de eerste die ontdekt dat het probleem daadwerkelijk voor een groot deel bij iDeal zit of is het een algemeen aanvaard/gedoogd probleem?
• Is dit lek niet ontzekkend risicovol voor de ca. 3000 iDeal-webwinkels in ons land?

Tot slot: volgens mij kunnen dezelfde problemen zich voordoen met bijvoorbeeld PayPal.
Tot slot 2: Ik wil onderzoeken of mijn bevindingen juist zijn. Ik hoop dat ik iets over het hoofd zie en dat er helemaal geen probleem is.

[Koppensneller]

Wat ik van iDeal weet, is dat niet alleen het totaalbedrag, maar ook alle losse artikelen met prijs worden verstuurd, samen met een checksum. Als die checksum niet meer klopt, kan de betaling niet voltooid worden.

[Verwijderd]

Ik weet niet precies hoe het zit met iDeal, maar is het niet zo dat het betaalde bedrag ook weer wordt meegegeven naar de webshop na de betaling zodat deze gechecked kan worden (al dan niet dmv een checksum zoals eerder aangegeven).

Als dat het geval is dan moeten de mensen bij iDeal zich flink gaan schamen, de webshop moet in principe altijd het werk van iDeal kunnen controleren.

Edit:

Even nagezocht, de webshop krijgt netjes het daadwerkelijk betaalde bedrag terug van iDeal, het lijkt me inderdaad de verantwoordelijkheid van de webshop dit te controleren.

Alle data verzonden via de client moet je als onbetrouwbaar behandelen en dus achteraf controleren (in alle situaties).

Was dat ook het probleem bij osCommerce? Dan zijn die gasten daar wel redelijk stupid (nofi).

[ Voor 35% gewijzigd door Verwijderd op 14-08-2007 15:22 ]

[Standeman]

KoppenSneller schreef op dinsdag 14 augustus 2007 @ 15:08:
Wat ik van iDeal weet, is dat niet alleen het totaalbedrag, maar ook alle losse artikelen met prijs worden verstuurd, samen met een checksum. Als die checksum niet meer klopt, kan de betaling niet voltooid worden.

Tja, maar als de checksum ook via een post-variable wordt verstuurd, kan ik die ook natuurlijk aanpassen.

[Verwijderd]

Standeman schreef op dinsdag 14 augustus 2007 @ 15:23:
[...]


Tja, maar als de checksum ook via een post-variable wordt verstuurd, kan ik die ook natuurlijk aanpassen.

Ja maar die checksum bevat gegevens die de client niet kan weten maar enkel bij iDeal en de webshop bekend zijn.

Ik geloof dat de iDeal checksum niet het bedrag bevat, veel paymenthandlers gebruiken wel een checksum met het bedrag erin (die werken dan als soort van gateway naar bijvoorbeeld iDeal toe)

[killercow]

Een knappe iDeal implementatie verstuurd onderhuids alle gegevens zodat je de klant alleen met een SessieKey naar de iDeal server gestuurd hoeft te worden, pas je de sessie key aan, dan is je sessie niet meer correct (ik gok dat ze sessies per IP bijhouden).

zo werkte RaboDirect vroeger al,
Als jouw implementatie dit niet gebruikt heb je de gemakkelijkere variant geimplementeerd en ja die is idd onveiliger.

[MueR]

StalieN schreef op dinsdag 14 augustus 2007 @ 15:01:
iDeal voert geen backend request naar de webshop uit om te controleren of het bedrag wel klopt, na betaling wordt gewoon een bevestiging gestuurd naar de webshop-eigenaar.

[knip]

Een kwalijke zaak lijkt mij, vooral voor webwinkeliers die grote hoeveelheden bestellingen per dag afhandelen en na bevestiging van iDeal niet willen controleren of het betaalde bedrag wel klopt.

Natuurlijk doet iDeal dat niet. iDeal is een betalingsmethode, en het is niet hun verantwoordelijkheid om te controleren of de webshop wel goed omgaat met data. Dit is enkel en alleen de verantwoordelijkheid van de webwinkel.

Als een bedrijf er zelf voor kiest om transacties niet te controleren, is dat nalatigheid van dat bedrijf, en daar kunnen ze iDeal moeilijk de schuld van geven. iDeal biedt voldoende mogelijkheden om de status van een transactie, plus alle relevante informatie zoals bedrag, bankrekeningnummer etc, te controleren. Als winkeliers dat niet doen, en er wordt fraude gepleegd, is dat hun probleem.

[thomaske]

Er zijn verschillende 'versies' van iDeal. Degene die jij beschrijft staat bekend als iDeal Basic (naamgeving is afhankelijk van de bank waarbij je de dienst afneemt).
iDeal basic is inderdaad niets meer dan een form-post naar een script op de iDeal servers. Dit is dan derhalve ook niet waterdicht en moet de rekeninghouder dus controleren of het juiste bedrag is overgemaakt.

De iDeal Advanced implementatie 'praat' direct met het de ideal-servers dmv xml-berichten over SSL. Hierbij is het niet mogelijk om als client nog variabelen aan te passen (mits je implementatie natuurlijk niet lek is)

[Niemand_Anders]

De 'basic' methode wordt voornamelijk op homepages gebruikt. Een webwinkel behoort toch echt op low-level niveau alle parameters naar de ideal server te sturen. Vervolgens wordt daarna de bezoeker naar de ideal server geredirect met alleen zijn referentie nummer (meestal ordernr).

Heb je geen 'zin' de rompslomp die erbij komt kijken, maak dan gebruik van een betaal service zoals Bibit. Die bieden honderden betalings mogelijkheden aan via 1 enkele interface.

[KabouterSuper]

Ik ben het met de TS eens (analyse van TS is dus correct). De Basic variant van ideal (ik ben bekend met de ING variant) werkt met een POST, en krijgt geen informatie terug over de transactie die daadwerkelijk is uitgevoerd.

@MueR: het probleem is dat ideal basic geen mogelijkheid geeft om de transactie te verifieren. Ideal kan dus niet zeggen dat het de verantwoordelijkheid is van de klant (=webwinkel) omdat ideal niet de mogelijkheid biedt om de verificatie te doen.

Maar om ook practisch te blijven.....is het mogelijk om een POST te doen die de gebruiker niet kan beinvloeden, dus een server-side post? Hiermee wordt het in elk geval een stuk moeilijker om het formulier te beinvloeden voordat deze verstuurd wordt.

[xtra]

Niemand_Anders schreef op dinsdag 14 augustus 2007 @ 16:19:
De 'basic' methode wordt voornamelijk op homepages gebruikt. Een webwinkel behoort toch echt op low-level niveau alle parameters naar de ideal server te sturen. Vervolgens wordt daarna de bezoeker naar de ideal server geredirect met alleen zijn referentie nummer (meestal ordernr).

Als webwinkel kun je baat hebben bij de extra mogelijkheden die de 'advanced' variant biedt. De beveiliging van de transactie moet bij beide methodes natuurlijk goed zijn door een controle van de verstuurde gegevens en/of het resultaat van de transactie.

[Verwijderd]

KabouterSuper schreef op dinsdag 14 augustus 2007 @ 16:28:
Ik ben het met de TS eens (analyse van TS is dus correct). De Basic variant van ideal (ik ben bekend met de ING variant) werkt met een POST, en krijgt geen informatie terug over de transactie die daadwerkelijk is uitgevoerd.

Fout de webwinkel krijgt wel vanuit iDeal informatie over de transactie terug.

Het is dus aan de webwinkel om dit te checken, als een webwinkel dat niet doet dan ligt dat aan de webwinkel en dus niet aan iDeal.

Derhalve:

iDeal is niet lek maar je moet wel opletten waar je mee bezig bent bij de implementatie.

[KabouterSuper]

o ja.....je krijgt bij ideal basic GEEN informatie terug over de transactie, behalve dan of deze geslaagd/gefailed/gecancelled is.

@TRRoads: heb je ervaring met ideal basic dat je dit zo stellig durft te beweren?

[FragFrog]

KabouterSuper schreef op dinsdag 14 augustus 2007 @ 16:28:
Maar om ook practisch te blijven.....is het mogelijk om een POST te doen die de gebruiker niet kan beinvloeden, dus een server-side post? Hiermee wordt het in elk geval een stuk moeilijker om het formulier te beinvloeden voordat deze verstuurd wordt.

In theorie? Ja. Je kan met bijvoorbeeld PHP een websocket openen en POST data erdoor plempen.

Overigens begreep ik via een kennis dat een iDeal betaler na afloop van zijn transactie een linkje krijgt om terug te gaan naar de oorspronkelijke site waarna je alsnog kan controleren of het bedrag etc wel klopt. Hij was bezig met een implementatie die 10 minuten wachtte op die verificatielink en daarna zelf ging controleren of het betaalde bedrag wel klopte. Heb er zelf verder geen ervaring mee, maar het lijkt me dat het dus wel degelijk te controleren is.

PayPal is in principe om dezelfde reden onveilig, maar bij Paypal weet je het en weet je dus ook dat je altijd achteraf het bedrag moet controleren. Dat iDeal de indruk wekt dat het bij hun niet hoeft is op zich wel zorgwekkend natuurlijk

[ Voor 4% gewijzigd door FragFrog op 14-08-2007 17:06 ]

[creative8500]

Over de onveiligheid van iDeal in dezen kan geen twijfel bestaan: na het vinden van deze lek konden we slechts gewapend met Firebug voor 42 cent een bloemetje bestellen...

[Verwijderd]

KabouterSuper schreef op dinsdag 14 augustus 2007 @ 17:00:
o ja.....je krijgt bij ideal basic GEEN informatie terug over de transactie, behalve dan of deze geslaagd/gefailed/gecancelled is.

@TRRoads: heb je ervaring met ideal basic dat je dit zo stellig durft te beweren?

Ik heb niet zoveel ervaring met iDeal basic, enkel met een paymenthandler, maar ik kan wel de manual lezen van iDeal basic.

Je hebt mogelijkheid terugkoppeling te krijgen via email en XML.

Het is inderdaad wel een beetje lastig dit te implementeren, maar zonder deze extra check ben je inderdaad pretty much fucked bij iDeal basic.

Ik kan haast niet geloven dat iDeal basic helemaal niets van terugkoppeling doet, al was het maar het automatisch toevoegen van de door hun ontvangen hash aan de returnurl zodat het gechecked kan worden.

Overigens kun je daarna alsnog wel de dader achterhalen wanneer je zelf ziet dat er te weinig geld op je rekening binnenkomt (neem aan dat meeste mensen dat toch achteraf wel checken, zelfs automatisch checken) en dan aangifte doen.

Maar het blijft kwalijk.

Deze opmerking ook:

Postbank adviseert om alleen tot levering over te gaan indien de status “Success” zichtbaar is in
het iDEAL Dashboard

Uit de manual van iDeal basic Postbank...

En verderop:

Als uw website vereist dat de transactie status geautomatiseerd kan worden opgehaald, dient u te
integreren via iDEAL Advanced of een Payment Service Provider

Alle systemen die geen terugkoppeling doen naar de webshop zijn dus per definitie kwetsbaar, ik weet niet hoe het met paypal ofzo is maar als daar ook die terugkoppeling er niet is dan is dat ook kwetsbaar.

Daarom nemen meeste webshops gewoon een paymenthandler zoals Buckaroo of Bibit, dan hoef je maar 1 interface te maken om iDeal, Paypal, creditcards etc aan te bieden aan je klanten en je hebt een goede support vanuit de paymenthandler.

[ Voor 52% gewijzigd door Verwijderd op 14-08-2007 17:30 ]

[bbstreams]

ideal is los van deze lek zoiezo erg gevoelig voor misbruik, met name het feit dat men vanuit een webwinkel site gelinkt wordt naar bank-interface waar vervolgens allerei gevoelige gegevens gevraagd worden, dit kan door criminelen eenvoudig misbruikt worden, klant heeft dan niets vermoedend zijn codes gegeven.

een gewone overboeking ovv opmerking is nog steeds het meest veilige, ik zou liever zien dat Ideal een digitale acceptgiro code aanmaakt en die realtime aanbiedt aan de bank. nadeel is dat gebruiker apart naar de website van zijn bank moet surfen, maar is hierdoor stukken veiliger uit.


UPDATE: mijn fortisbank biedt de mogelijkheid om ClieOp bestanden aan te bieden, een klein bestandje waarmee je geen invulwerk hebt. lijkt mij een ideale en goedkoop alternatief voor een webwinkel, klant kiest deze betaalwijze, waarna een asp of php scriptje deze als download document aanbied. clieOp kan makkelijk verwerkt worden in veel administatie software. jammer dat hier zo weinig tot geen gebruik van wordt gemaakt.

[ Voor 26% gewijzigd door bbstreams op 15-08-2007 09:19 ]

[StalieN]

Bedankt voor alle reacties!

Het gaat in ons geval inderdaad om iDeal basic. Ik ga eens uitzoeken hoe het zit met de xml-terugkoppeling, als dat bij het basic-pakket ook geboden wordt, dan is het inderdaad op te lossen. Zo niet, zal ik onze vriendelijke klant toch maar adviseren te upgraden naar een van die pakketten waar terugkoppeling wel kan plaatsvinden. Emailterugkoppeling vind ik persoonlijk helemaal niks, dan moet je handmatig in een email gaan lezen welk bedrag er is overgemaakt, om dat vervolgens te checken in de orderdatabase met de bijbehorende bestelling. Tuurlijk, kan ook automatisch, maar is niet echt safe. De xml is in elk geval een goede manier - als het mogelijk is.

[GX]

bbstreams schreef op woensdag 15 augustus 2007 @ 09:04:
ideal is los van deze lek zoiezo erg gevoelig voor misbruik, met name het feit dat men vanuit een webwinkel site gelinkt wordt naar bank-interface waar vervolgens allerei gevoelige gegevens gevraagd worden, dit kan door criminelen eenvoudig misbruikt worden, klant heeft dan niets vermoedend zijn codes gegeven.

een gewone overboeking ovv opmerking is nog steeds het meest veilige, ik zou liever zien dat Ideal een digitale acceptgiro code aanmaakt en die realtime aanbiedt aan de bank. nadeel is dat gebruiker apart naar de website van zijn bank moet surfen, maar is hierdoor stukken veiliger uit.


UPDATE: mijn fortisbank biedt de mogelijkheid om ClieOp bestanden aan te bieden, een klein bestandje waarmee je geen invulwerk hebt. lijkt mij een ideale en goedkoop alternatief voor een webwinkel, klant kiest deze betaalwijze, waarna een asp of php scriptje deze als download document aanbied. clieOp kan makkelijk verwerkt worden in veel administatie software. jammer dat hier zo weinig tot geen gebruik van wordt gemaakt.

Clieop is gebaseerd op machtigingen, terwijl dat bij iDeal juist niet meer hoeft. Dat vinden mensen fijn; zelf de 'ja' knop indrukken van hun betaling.

Daarnaast komen de URL's van iDeal gewoon uit een XML-bericht zetten; waar ze heen moeten. Knappe hacker als hij die aan weet te passen. (ik heb overigens alleen maar ervaring met iDeal advanced)

[ Voor 7% gewijzigd door GX op 15-08-2007 15:38 ]

[Verwijderd]

iDeal Advanced is inderdaad wel gewoon veilig, daar kom je niet zomaar doorheen.

[Verwijderd]

Verwijderd schreef op dinsdag 14 augustus 2007 @ 15:24:
[...]

Ja maar die checksum bevat gegevens die de client niet kan weten maar enkel bij iDeal en de webshop bekend zijn.

Ik geloof dat de iDeal checksum niet het bedrag bevat, veel paymenthandlers gebruiken wel een checksum met het bedrag erin (die werken dan als soort van gateway naar bijvoorbeeld iDeal toe)

Wordt er geen MD5 of (beter nog) SHA hash ipv een gewone checksum gebruikt? Die is namelijk praktisch niet aan te passen i.t.t. een gewone checksum.
Mijn 2 cent (nou vooruit, 10 ...

[Verwijderd]

Verwijderd schreef op woensdag 15 augustus 2007 @ 16:50:
[...]

Wordt er geen MD5 of (beter nog) SHA hash ipv een gewone checksum gebruikt? Die is namelijk praktisch niet aan te passen i.t.t. een gewone checksum.
Mijn 2 cent (nou vooruit, 10 ...

SHA wordt er inderdaad gebruikt.

Checksum gebruikte ik als algemeen woord, ik had ook wel hash kunnen gebruiken (iets wat in de normale spreektaal hetzelfde is).

Echter bij de iDeal Basic implementatie zitten er geen gegevens in de hash die niet bekend zijn bij de klant geloof ik.

[ Voor 11% gewijzigd door Verwijderd op 15-08-2007 17:09 ]

[Verwijderd]

Verwijderd schreef op woensdag 15 augustus 2007 @ 17:09:
[...]

SHA wordt er inderdaad gebruikt.

Checksum gebruikte ik als algemeen woord, ik had ook wel hash kunnen gebruiken (iets wat in de normale spreektaal hetzelfde is).

Echter bij de iDeal Basic implementatie zitten er geen gegevens in de hash die niet bekend zijn bij de klant geloof ik.

Bedoelde ook SHA als speciaal geval van een checksum. Ik maakte wel een aander foutje. Ik bedoelde natuurlijk de data zodanig aanpassen dat de checksum (hash) hetzelfde blijft ipv andersom.

Maar je beantwoorde mijn vraag eigenlijk al. Als ze geen secrets meesturen . Ging daar idd vanuit

[st0p]

misschien denk ik te simpel het volgende niet kunnen:

1) eerst de fraudegevoelige gegevens naar een database schrijven
2) formulier laten zien (zonder hidden fields of wat dan ook)
3) gegevens van het formulier combineren met de gegevens uit de DB
4) alles samen versturen dmv sockets

[Verwijderd]

st0p schreef op woensdag 15 augustus 2007 @ 21:26:
misschien denk ik te simpel het volgende niet kunnen:

1) eerst de fraudegevoelige gegevens naar een database schrijven
2) formulier laten zien (zonder hidden fields of wat dan ook)
3) gegevens van het formulier combineren met de gegevens uit de DB
4) alles samen versturen dmv sockets

Het gaat er niet om dat er manieren zijn weermee het wel veilig gedaan kan worden, er zijn duizenden manieren die al jaren gebruikt worden om zoiets veilig voor elkaar te krijgen.

Het gaat er ook niet om dat ze bij iDeal niet weten hoe ze het veilig moeten doen, immers is iDeal Advanced wel veilig.

Waar het om gaat is dat iDeal Basic (expres?) onveilig is en de banken achter iDeal als enig antwoord hebben dat je dan maar Advanced moet gebruiken.

Overigens is het niet zo dat iDeal Basic echt onveilig is, het is alleen eenvoudig voor de gek te houden en het is erg lastig dit automatisch op te vangen. Handmatig kun je natuurlijk alles checken en dan zie je gelijk dat de transactie niet klopt (en kun je eventueel aangifte doen tegen de fraudeur).

De banken hebben dus een goed argument, wil je iDeal Basic veilig hebben dan moet je alles handmatig nalopen, als je dat niet wilt neem je maar een iDeal Advanced abbo af.

Het zijn dus gewoon commerciele bedrijven die hun duurdere product aan de man willen brengen, zoals ieder bedrijf dat zou doen. Niets mis mee, wat alleen minder netjes is is dat hier bijna niet op gewezen wordt en mensen er dus vanuit gaan dat het wel veilig is terwijl dit absoluut niet het geval is (maar dit ook niet pretendeert te zijn).

[thomaske]

st0p schreef op woensdag 15 augustus 2007 @ 21:26:
misschien denk ik te simpel het volgende niet kunnen:

1) eerst de fraudegevoelige gegevens naar een database schrijven
2) formulier laten zien (zonder hidden fields of wat dan ook)
3) gegevens van het formulier combineren met de gegevens uit de DB
4) alles samen versturen dmv sockets

Wat jij beschrijft is inderdaad ongeveer wat de Advanced versie inhoudt, de Basic versie _moet_ met een client POST naar ideal toe. Dit kan niet op de server gedaan worden, omdat jij de client naar ideal toe moet.

[Verwijderd]

Daarnaast is een verschil (het belangrijkste verschil) dat de Advanced versie gegevens terugkoppelt naar de webshop, daardoor kan de webshop controleren of alles goed is gegaan en direct er vanuit gaan dat iDeal het verder goed afhandelt (en dus gelijk de boel verzenden wat het voordeel is van iDeal, automatisch en lekker snel).

[Evilbee]

st0p schreef op woensdag 15 augustus 2007 @ 21:26:
misschien denk ik te simpel het volgende niet kunnen:

1) eerst de fraudegevoelige gegevens naar een database schrijven
2) formulier laten zien (zonder hidden fields of wat dan ook)
3) gegevens van het formulier combineren met de gegevens uit de DB
4) alles samen versturen dmv sockets

Dat kan dus niet omdat de klant op de site van iDeal moet uitkomen, als je het via een socket stuurt ziet alleen de server de goede pagina.

Ik heb zelf alleen ervaringen met de Advanced versie van iDeal. Maar ten eerste kan je in het dashboard alle betalingen zien, zodat je de betalingen kan controleren. En ten tweede wordt er een door iDeal een mailtje verstuurd met de betalingsbevestiging waar ook het betaalde bedrag in staat.

Als je dus het betaal bedrag aan kan passen en je order wordt toch geaccepteerd, is dat mijn inziens een grove fout van de winkelier.