Lek in betaalmiddel iDEAL

[Ber|Art]

Het is mogelijk de online betaalmiddel iDEAL te misbruiken in combinatie met Oscommerce-platformen.

Dit schrijven de banken aan de participanten, zoals aan Central Point. Dit frauderisico is geconstateerd in de betaalmodule idealm voor het webwinkel-platform OScommerce. Deze betaalmodule wordt via de community van oscommerce.nl verspreid. lees hier de rest van het artikel

[groenleer]

Deze informatie was vrijdag ochtend/donderdag avond al bekend.

De email heb ik namelijk van de ING Bank, Postbank, Rabobank en ABN-Amro gehad. Krijg je als je bij diverse partijen als technisch contact bent geregistreerd.
Niet te min goed om mensen in te lichten.


Het volledige bericht zoals verzonden door de meeste banken:

Subject: iDEAL: waarschuwing Oscommerce module
Date: Fri, 10 Aug 2007 11:49:32 +0200


Geachte klant,

Recentelijk is vastgesteld dat een consument tijdens het orderproces op de site
van een webwinkelier het te betalen bedrag gemanipuleerd heeft. Via deze weg
willen wij u informeren over de specifieke betaalmodule waarin dit probleem
zich heeft voorgedaan. Daarnaast vindt u hier een aantal adviezen hoe dit
probleem in zijn algemeenheid is te voorkomen.

Hoewel het geconstateerde frauderisico zich rondom een betaling met iDEAL
manifesteerde, heeft het risico geen directe relatie met de betaalmethode
iDEAL. Vanuit service-oogpunt willen wij u deze informatie echter niet
onthouden. Het is dus heel goed denkbaar dat hetzelfde risico zich tevens bij
andere betaalmethoden of ‑modules voordoet.

Dit frauderisico is geconstateerd in de betaalmodule idealm voor het
webwinkel-platform OScommerce. Deze betaalmodule wordt via de community van
www.oscommerce.nl <http://www.oscommerce.nl/> verspreid. De relatie met het
platform OScommerce is hier slechts een voorbeeld, het is denkbaar dat dezelfde
en ook andere betaalmodules binnen andere webwinkel-platforms hetzelfde risico
hebben.


Beschrijving van het frauderisico

Het frauderisico wordt veroorzaakt doordat voorafgaand aan een iDEAL-betaling
aan de consument een scherm met orderbevestiging wordt getoond, waarbij voor
het opbouwen van dit scherm gebruik wordt gemaakt van dezelfde parameter
waarmee later in het proces het iDEAL AcquirerTrxReq bericht richting de bank
van de webwinkelier wordt samengesteld. Hier is sprake van een onvolkomenheid
in de betaalmodule, omdat het niet raadzaam is parameters die gebruikt worden
bij een betaalverzoek toegankelijk te maken vanuit de browseromgeving van de
consument. Het frauderisico ontstaat in de omgeving van de webwinkel, niet in
de iDEAL betaalmethode.

Bij het geconstateerde frauderisico heeft een consument, bij het weergeven van
de orderbevestiging, het te betalen bedrag gewijzigd, waarna door de module
idealm, met het aangepaste bedrag, het iDEAL bericht richting de bank werd
samengesteld. In dit geval controleerde het webwinkel-platform dus niet of dit
bedrag gelijk is aan het in de orderdatabase opgeslagen bedrag. Het betreft de
parameter idealm_amount.

Vervolgens is door deze kwaadwillende consument de iDEAL transactie via het
bancaire circuit geautoriseerd en afgehandeld. De webwinkelier ontving daardoor
een lager bedrag voor de order dan waarvoor deze was aangeboden.

De feitelijke iDEAL betaling en de terugmelding aan de webwinkel zijn volledig
vrij van risico. Het risico geldt enkel voor de betreffende webwinkel als deze
bij het samenstellen van het betaalverzoek aan hun bank gebruik maakt van
parameters die vanuit de browseromgeving toegankelijk zijn. Aangeraden wordt om
direct na ontvangst van de terugmelding pas over te gaan tot levering nadat
gecontroleerd is of het betaalde bedrag overeenkomt met hetgeen in de
orderadministratie is vastgelegd.


Geadviseerde maatregelen

1. Controleer uw betaalmodule

Wij adviseren u om te controleren of de velden die benodigd zijn bij het
initiëren van een iDEAL-betaling niet door tussenkomst van de consument
aangepast kunnen worden. Indien dit risico aanwezig blijkt te zijn, adviseren
wij u de betaalmodule zo snel mogelijk te (laten) aanpassen of vervangen.

2. Controleer de juistheid van het betaalde bedrag voorafgaand aan de levering

Daarnaast wordt geadviseerd om voorafgaand aan de levering te controleren of
het betaalde bedrag overeenkomt met het in de orderdatabase opgeslagen bedrag.

3. Aangifte doen in geval van fraude

In geval van geconstateerde afwijkingen van het betaalde bedrag wordt u
aangeraden om aangifte te doen bij justitie.

Wij hopen u met deze informatie van dienst te zijn geweest.



Met vriendelijke groet,

iDEAL / E-commerce servicedesk

[Ber|Art]

De email heb ik namelijk van de ING Bank, Postbank, Rabobank en ABN-Amro gehad. Krijg je als je bij diverse partijen als technisch contact bent geregistreerd.

Het is goed om te horen dat je wordt ingelicht

[BsHosting]

Had hem ook vrijdag al binnen

eerst via ideal zelf en toen nog via postbank en ing.

[Ramon Fincken]

Maar feitenlijk is dit toch gewoon slechte coding door de progger?

Bedragen moet je gewoon uit de DB/ winkelmand-systeem trekken en op de laatste betaalpagina de mogelijkheid tot veranderen verwijderen ( of zie ik dit verkeerd ? )

[groenleer]

Maar feitenlijk is dit toch gewoon slechte coding door de progger?

Bedragen moet je gewoon uit de DB/ winkelmand-systeem trekken en op de laatste betaalpagina de mogelijkheid tot veranderen verwijderen ( of zie ik dit verkeerd ? )

Dat zie je goed, als je kijkt naar de code zie je ook dat enkele gegevens wel uit de database komen, maar dat het bedrag uit de submit van de user komt.

Wij controleren wel altijd of de gebruiker de gegevens heeft gemodificeerd. Dit doen we door de individuele waardes te controleren en de checksums met wat in de database staat. Daarnaast worden de gegevens uit de database naar de bank gestuurd.
Mochten de checksums of waardes niet kloppen krijgt de gebruiker een melding te zien dat er een aanpassing in de gegevens is gevonden en dat zijn ip-adres, bestelling en andere gegevens worden doorgegeven aan de beheerder ter controlle om de omgeving te verbeteren. Daarnaast is het natuurlijk ook bedoeld om de informatie te vergelijken met eerdere 'aanpassingen' om een patroon te ontdekken.

Verder hebben we veel winkelwagentjes die op basis van AJAX communiceren met de server. Deze sturen vervolgens ook nog XML via een post-action over.
Hier door is het al lastig, maar niet onmogelijk om gegevens te modificeren.

Maar dit was gewoon een domme fout in die module.

[nielsrenselaar]

Vind het sowieso netjes dat de banken de verantwoordelijkheid nemen om ook fouten van derden serieus te nemen, en mee te helpen om te de gebruikers van deze module te waarschuwen, een goed pluspunt!

Sowieso moet je als eigenaar van een webwinkel het bedrag altijd controleren, en niet klakkeloos een mailtje van dat de betaling afgerond is interpreteren als 'het gehele bedrag is betaald'.

[groenleer]

Het is jammer dat de banken alleen doorgeven dat de betaling is voldaan.
Als ze nu ook eens het bedrag doorgaven dat daadwerkelijk is overgemaakt zou het controleren hier op eenvoudiger zijn.

Nu moet je betalingen met de handcontroleren. iDeal was juist bedoeld om dat te voorkomen.

Het is niet moeilijk om een php-file te maken die alleen communiceert met de iDeal omgeving van de bank. Ze zouden die bijvoorbeeld ook met curl aan kunnen roepen. Dan is de koper er niet mee gemoeid.
Webwinkel bewaard het betaalde bedrag waarna de klant weer via een redirect en een trxid en entrance-code terug komt op je site.
Je kan dan vanzelf aangeven dat er een deelbetaling is binnengekomen. En dat er een extra iDeal betaling nodig is om de betalling volledig af te ronden.

[Triloxigen]

De lek zit dus niet in iDeal!

Lek zit inderdaad gewoon in de software die voor osCommerce gemaakt is.

[fastsolutions]

Het is jammer dat de banken alleen doorgeven dat de betaling is voldaan.
Als ze nu ook eens het bedrag doorgaven dat daadwerkelijk is overgemaakt zou het controleren hier op eenvoudiger zijn.

Nu moet je betalingen met de handcontroleren. iDeal was juist bedoeld om dat te voorkomen.

Het is niet moeilijk om een php-file te maken die alleen communiceert met de iDeal omgeving van de bank. Ze zouden die bijvoorbeeld ook met curl aan kunnen roepen. Dan is de koper er niet mee gemoeid.
Webwinkel bewaard het betaalde bedrag waarna de klant weer via een redirect en een trxid en entrance-code terug komt op je site.
Je kan dan vanzelf aangeven dat er een deelbetaling is binnengekomen. En dat er een extra iDeal betaling nodig is om de betalling volledig af te ronden.

Dat is niet waar, banken geven door dat de betaling is succesvol is afgerond, maar het is zelfs verplicht om zelf de status van de betaling op te vragen, hier heeft een bank een api voor (Check payment API (API-3)) een voorbeeld van deze api staat bijvoorbeeld hier: http://www.fastsolutions.eu/index.ph...menu=iDEAL_api

Je krijgt dan het bedrag rekeningnummer, plaats en de naam van de bank terug, dit bedrag moet je vergelijken met het bedrag die je in de shop hebt aangemaakt en als deze bedragen niet overeenkomen dan betekent dat de shopper aan het sjomelen is dus moet je de status van de order niet op "betaald" zetten.

De fout zit in dit geval wel in Oscommerce module.
P.S. indien je de status van de betaling niet opvraagt dan krijg je een automatisch e-mail van de bank met het verzoek dit alsnog te doen.

[Thijs]

Zover ik weet is deze bug al eerder aan de orde geweest en gefixt, zal nu wel om een remake gaan waar de fout weer in zit.

Tevens vind ik het knap dat mensen hier bijna durven beweren dat hun methode beter en meer waterdicht is.

Ik durf ook met zekerheid te zeggen dat deze personen even hun code ingedoken zijn... beter goed gejat dan slecht gemaakt natuurlijk.

[crazycoder]

Zover ik weet is deze bug al eerder aan de orde geweest en gefixt, zal nu wel om een remake gaan waar de fout weer in zit.

Tevens vind ik het knap dat mensen hier bijna durven beweren dat hun methode beter en meer waterdicht is.

Topic is van 13 augustus, betreft dus het destijds bekend geworden probleem.

Misschien is hun methode ook wel beter wie zal het zeggen.