Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 84 reacties
Bron: Oscommerce

De e-commerce-helpdesk van iDeal waarschuwt webwinkels die gebruikmaken van het oscommerce-platform voor een lek in de iDeal-betaalmodule. Mogelijk lopen ook betaalmodules in andere webwinkelsoftware het risico op misbruik.

iDeal oscommerce logo'sDe helpdesk van iDeal heeft zijn klanten per e-mail op de hoogte gebracht van het probleem. Door het geconstateerde lek kan een consument tijdens het orderproces op een oscommerce-webwinkel het te betalen bedrag manipuleren. De fraude is mogelijk door een fout in de opensourcemodule 'idealm', een module die door anderen is geschreven; het iDeal-platform zelf is onaangetast.

Voorafgaand aan een iDeal-transactie krijgt een klant die elektronisch wil betalen een nieuw venster te zien waarin het af te rekenen bedrag wordt getoond, en om bevestiging wordt gevraagd. Een onbekende is er in geslaagd om een parameter waarmee dit venster wordt aangeroepen, aan te passen. Dezelfde parameter wordt ook gebruikt om na de bevestiging de iDeal-transactie richting de bank door te geven. Het webwinkelplatform controleert niet of het gemanipuleerde bedrag gelijk is aan het in de orderdatabase opgeslagen bedrag.

De helpdesk van iDeal spreekt van een ernstig lek in de idealm-betaalmodule, omdat de parameters die gebruikt worden bij het aanroepen van het iDeal-bevestigingsscherm voor de eindgebruiker niet zichtbaar mogen zijn. Om misbruik van het lek te voorkomen wordt aangeraden om de betaalmodule te controleren en zo nodig aan te passen of te vervangen. Ook zouden winkeliers moeten controleren of het betaalde bedrag overeenkomt met de orderdatabase, voordat tot levering wordt overgegaan. Bij eventuele fraude wordt aangeraden om aangifte te doen bij justitie. Op de website van oscommerce staat een mogelijke oplossing voor het probleem met de iDeal-module.

Moderatie-faq Wijzig weergave

Reacties (84)

Ze gebruiken in de code:

[code]
$iamount = $_POST['idealm_amount'];
[/code]

Maar dit lijkt me per definitie problemen opleveren, omdat er geen enkele validatie op de user input word uitgevoerd. Imho is dit dus gewoon een heel slordige fout.
Ze gebruiken in de code:

[code]
$iamount = $_POST['idealm_amount'];
[/code]

Maar dit lijkt me per definitie problemen opleveren, omdat er geen enkele validatie op de user input word uitgevoerd. Imho is dit dus gewoon een heel slordige fout.
Hoe kan je dat zeggen dat $_POST per definitie onveilig is?
Wie weet gebruiken ze deze code, niks onveiligs meer aan hoor en je kan overal $_POST gebruiken.

foreach($_POST as $key=>$value) {
$_POST[$key] = validatiefunctie($value);
}
Maar validatiefuntie() gebruiken ze dus niet,

Mij lijkt het logischer als er:
$iamount = validatiefunctie($_POST['idealm_amount']);

Zou worden gebruikt,

Het heeft gewoon totaal geen waarde of nut, om van een global $_POST['idealm_amount'], een variabel $iamount te maken als geen bewerking op word uitgevoert op $_POST['idealm_amount']. Ik vind het dus eigenlijk ook gewoon hele lose code. Er gebeurt niks.

[Reactie gewijzigd door Bedge_85 op 12 augustus 2007 12:00]

Mja, valt wel mee. De bank stuurt namelijk op de achtergrond een verzoek naar een speciale pagina van de winkelier met als POST-variabele het ordernummer. De winkelier moet vervolgens in een XML bestand het bedrag geven.

Je kunt dus wel het bedrag aanpassen, maar normaliter wordt dit bedrag gecontroleerd (buiten de klant om). Het probleem is dat deze controle achterwege is gelaten!

Het probleem is alleen dat deze controle niet door de banken verplicht wordt gesteld. Lijkt me toch ook een slechte zaak van de banken zelf!
Maar voor mij geeft het feit dat er geen validatie op de code word uitgevoerd al aan, dat de code niet netjes is van deze module.

Je zou namelijk ook in de $_POST een stuk code mee kunnen geven waardoor de pagina anders gaat reageren (javscript) of er anders uit laten zien (html/css).

Mijn inziens zou er iig op deze $_POST de volgden iig de volgende 2 controles uitgevoerd moeten worden.
1. Is $_POST numriek
2. Aantal karrakters van $_POST

Ik weet dat je met deze 2 controles niet de genoemde security leak kunt voorkomen, maar het zou wel de minimale controle moeten zijn voor de $_POST variabele.

Vervolgens zou (zoals de IDEAL ook suggereert) bij de werkelijke transactie het totaal bedrag uit de database moeten worden gehaald, en niet uit een variabele welke gewoon door gewoon een gebruiker kan worden gewijzigd |:(
Van die $_POST variabele wordt nergens gekeken of de waarde overeenkomt met de prijs, maar je gaat er nu - wellicht onterecht - vanuit dat $_POST verderop, of bij output, ook niet wordt gecontrolleerd of beveiligd op syntax.
Die POST waarde hoeft niet gevalideerd te worden. Die zou niet eens mogen bestaan. Aan de hand van de artikelen in het winkelmandje moet in de PHP code de totale prijs berekend worden, nooit door een POST vanaf een bestel- of bevestigingspagina.
Het gaat om een koppeling met het externe iDeal systeem. De webshop berekent de prijs, naar ik mag aannemen via de winkelmand, en stuurt dit vervolgens via een post richting de iDeal site. De iDeal service kan niet query'en in je database en al helemaal niet in je winkelmand.
Hoezo een slechte zaak van de banken? Winkeliers die zelf geen maatregelen nemen om zichzelf goed te beschermen en daar nadelen van ondervinden zonder dat dat aan iDeal zelf ligt is geen verantwoordelijkheid van banken. Banken stellen overigens al dat zakelijke gebruikers voor het aanbieden van de betaaldienst zelf zorg moeten dragen voor een goede implementatie.
Ik heb verschillende iDeal implementaties gedaan, de fout zit niet in de iDeal software maar in de software van de aansluiter.
Deze ontvangt van de webshop een bedrag en stuurt dit door naar iDeal.
Ideal rekent dit bedrag af en meld dat het gelukt is.

Dat de webshop zijn bedragen niet onderhuids maar gewoon via de browser naar de aansluiter stuurt is het probleem, zo kan de bezoeker gewoon zelf het bedrag aanpassen.

Alle betaal methoden van multipay waren (of zijn) ook zo te misleiden.

Rabodirect ondersteunde ook het bedrag doorsturen via de klant, maar dan moest er ook een hash meegestuurd worden om zo aanpassingen door de klant tegen te gaan.

@mddd, wat een geflame weer.
Wat heeft dit met open source te maken, je argument "als je niet weet wat er gebeurt" kun je juist weerleggen met opensource software, en niet met closed source software. Of ben je niet kundig genoeg om even te lezen wat er gebeurt onder de motorkap en kun je er alleen op fitten als het jouw uitkomt?

[Reactie gewijzigd door killercow op 10 augustus 2007 16:07]

Mijn post is absoluut niet als opensource-flame bedoeld hoor. Mijn argument is ook niet 'je kunt het niet controleren', maar 'blijkbaar moet je het zelf alsnog controleren'.

Als je een website bouwt kun je zelf een onderdeel (in dit geval een betaalmodule) bouwen, of je kunt een standaard bouwsteen gebruiken. En dat standaard onderdeel kan dan eventueel gekocht zijn of uit het vrij beschikbare circuit komen.

Het voordeel van een standaard element (zoals oscommerce idealm in dit geval) is natuurlijk dat je niet zelf al het werk hoeft te doen. Als je zelf alsnog de volledige code moet gaan doorspitten om te kijken of alles wel veilig is, dan heeft het m.i. weinig zin om uberhaupt dat element te gebruiken! Dan kun je het net zo goed zelf maken.

Het valt mij nogal tegen dat zo'n veelgebruikt pakket als oscommerce zulke slechte plugins kent. En dat versterkt mijn idee dat ik dus beter zelf een kritisch stuk als een betaalmodule kan schrijven, dan het van het net plukken.

En wat mij nog somberder stemt: er zijn ook zat mensen die zelf niet eens de kennis hebben om zoiets te kúnnen schrijven. Die hebben geen keuze. (Of die webshops zouden moeten bouwen is trouwens ook de vraag, maargoed).

[Reactie gewijzigd door mddd op 10 augustus 2007 16:47]

Gebruik dat niet "dit soort open source producten", want nu zijn je posts wat mij betreft flamebait of allerminst op onwaarheden gebaseerd.

Je geklaag slaat op open EN closed source... waarbij je bij closed source niet eens de mogelijkheid hebt deze te controleren.

Ik neem aan dat je dus alles zelf schrijft?
Of gebruik je closed source modules? Ik zie weinig closed source die niet ontzettend waanzinnig duur is waarbij de leverancier daadwerkelijk de verantwoording neemt voor fouten onstaan door problemen in hun software.
1. Closed source software wordt voornamelijk geschreven door ervaren programmeurs bij bedrijven die eerst hebben moeten solliciteren. Open source wordt geschreven door jan en alleman. Dit kunnen diezelfde goede programmeurs zijn, maar ook pietje die dus een totaalbedrag via POST verstuurt en er waarschijnlijk geen idee van heeft dat het niet veilig is.
2. Closed source is meestal betaald, en daarvoor verwacht je dat de software uitgebreid getest is. Niemand heeft de iDeal plugin van pietje bekeken, maar honderden winkels gebruiken deze wel.
3. Betaalmodules zijn een van de belangrijkste onderdelen van een webwinkel. Je wilt dat deze goed gebouwd en veilig is. Bij open source heb je de kans om deze in te kijken, bij closed source helaas niet. Máár als je betaald voor een betaalmodule, verwacht je kwaliteit, en bij open source weet je dat het mogelijk is dat pietje het gemaakt heeft.

Hieruit kan je concluderen dat closed source meer vertrouwen wekt als het om betaalmodules gaat. Wil je deze niet inkopen, en kies je voor open source, zorg dan dat je zelf kijkt of het veilig is (was osCommerce trouwens ook had moeten doen bij pietjes module). Als het niet veilig is, pas het dan aan.

Of je bespaart je al deze moeite, en kiest in sommige gevallen om het zelf maar te doen, wat mddd aandraagt.

Het is geen flame, maar een constatering van mogelijkheden en een oplossing daarvoor. Ik ben 100% voor open source, maar zoals dit bericht bewijst: het is een mogelijk beveiligingsrisico.
1. Dit weet je niet, voor hetzelfde geld is het door Floris de stagiair geschreven, maar hierbij ga je dan vaak af op de blauwe ogen (de reputatie) van het bedrijf. Bij OSS projecten kun je vaak wel een beetje een indruk opdoen van hoe met kwaliteit omgegaan word. Bekijk de documentatie (Klote documentatie is of geen serieuze developers, te kleine community, of zo een haast werk dat ze geen tijd meer hadden voor documentatie), lees wat code, en je krijgt vaak wel een indruk van de kwaliteit.

2. Ik heb enkele implementaties van webshops gedaan, en heb derhalve heel wat regels code van osCommerce gelezen (is al weer een poosje terug, dus kwaliteit ervan kan ik me niet meer herinneren). Als vele mensen onafhankelijk van elkaar met eigen ogen code doorlezen, dan is de kans groot dat er veel bugs geplet worden. Closed source modules worden maar door een beperkt aantal verschillende mensen gelezen.
"Verwacht dat deze goed getest is". Lees even een paar pagina's meuktracker door, en verbaas je over enkele commercieele closed source paketten met fouten waarvan je denkt "hadden ze dat niet wat beter kunnen testen". Verwachten/denken moet je zien te voorkomen, ik controleer liever nog eens.

3. Kwaliteit verwachten is iets anders dan krijgen, ik kan hier moeilijk voorbeelden gaan noemen van software waar je kwaliteit van zou verwachten maar het niet krijgt (Want dan loop ik het risico een verzameling fanboys van het betreffende product achter me aan te krijgen), maar er zijn genoeg voorbeelden.
Het is inderdaad een risico voor de winkelier, dat er een verkeerd bedrag wordt afgeschreven. Het gaat erom dat de waarde die van je rekening wordt afgeschreven, wordt bepaald door een variabele die vanuit de gebruiker (dus de bezoeker van de shop) wordt doorgestuurd. En die later blijkbaar niet meer wordt gecheckt. Wat natuurlijk een enorm stomme fout is. Wat je hoort te doen, is de parameters van de bestelling in je database op te slaan, dan de iDeal betaling uit te voeren en vervolgens te checken of er ook echt is gebeurd wat je had gevraagd. Wat hier dus niet gebeurde.

Dit is dus de reden waarom ik geen sites maak op basis van dit soort opensource producten. Je kunt onmogelijk richting je opdrachtgever verklaren dat iets veilig is, als je niet weet wat er eigenlijk gebeurt!

Aanvulling:
"Als je niet weet wat er eigenlijk gebeurt" slaat niet op de vraag of je het KUNT controleren. Dat kan natuurlijk juist wel bij open-source software, de naam zegt het al. Het gaat mij erom dat het in de praktijk niet nuttig is; als je een open-source component compleet moet gaan nachecken of het wel veilig is geschreven, wat is dan nog de meerwaarde. Schrijf het dan zelf denk ik dan. En dat doe ik dan dus ook.

[Reactie gewijzigd door mddd op 10 augustus 2007 16:50]

uhm.. Met open source heb je toch juist WEL de mogelijkheid om te zien wat er eigenlijk gebeurd.
Enige andere optie om het zeker te weten is door het zelf uit te programmeren (aangenomen dat je de compiler vertrouwd).

Wanneer je het voor jezelf zeker wilt weten zou ik eerder de bestaande code reviewen dan zelf iets te maken. Andersmans fouten zie je vaak eerder dan je eigen.
Ik ben ook geneigd zelf iets te maken als ik dit geprogrammeerde stukje onkunde zie. Bugs zullen er altijd zijn, maar om het totaalbedrag via de gebruiker te laten lopen is toch wel echt reden om deze "programmeur" het project uit te schoppen.

(en PHP code wordt niet gecompileerd)
Reagerend op je aanvulling:


Jouw eigen knutselsoftware is zeker wel bugfree omdat jij beter programmeert dan een OSS community? Als je zelf iets implementeert komen dit soort bugs inderdaad niet aan het licht, omdat jij de enige bent die de code kan zien.


Bij software ontwikkeling worden simpelweg fouten gemaakt, ongeacht het ontwikkelmodel. Terwijl dit wel een redelijk slordige fout is, kan je onmogelijk over OSS in het algemeen als minder kwalitatief goed spreken. Juist door dit soort ontdekkingen bereikt de software sneller een hoger niveau van volwassenheid. Door gebruik te maken van volwassen OSS componenten zal het resultaat beter zijn dan zelfbouw, of je moet wel heel briljant zijn.

[Reactie gewijzigd door PHiXioN op 10 augustus 2007 17:05]

Mijn eigen software is ongetwijfeld niet bug-free. Maar tenminste kan ik er op vertrouwen dat ik weet hoe het in elkaar steekt. Ik zeg ook nergens dat OSS van mindere kwaliteit zou zijn dan iets wat een individu (e.g. ikzelf) schrijft. In zijn algemeenheid is OSS vast beter. Maar dit geval geeft wel aan, dat het dus best kan dat er in een stuk OSS een enorm stomme fout zit, terwijl je er juist vanuit zou gaan dat het beter is. Nou daar schrik ik dan wel van ja.

Het gaat mij om de vraag of je er verantwoordelijkheid voor kunt/wilt nemen. Ik doe dat dus liever voor mijn eigen werk dan voor een samenspel van elementen waar je zelf weinig controle over hebt.
terwijl je er juist vanuit zou gaan dat het beter is.
Zo lang je nergens vanuit gaat, verwacht je ook geen verkeerde dingen, verwacht vooral niet dat je eigen code (c) beter is dan Supershop (r) Pro(tm) of OpenShop.
Dat hele verhaal van jou heeft toch niets maar dan ook niets met open source te maken?
Jij schrijft lekker alles zelf omdat je het beter meent te kunnen dan iemand anders. Tot hoever voer je dit eigenlijk door? Schrijf je alle libraries / platforms ook zelf? Je OS? Anders zou er nl nog wel eens een fout in kunnen zitten Als je het zelf schrijft niet.
Jij schrijft lekker alles zelf omdat je het beter meent te kunnen dan iemand anders
Beter lezen, dat zegt hij helemaal niet! Sterker nog:
Ik zeg ook nergens dat OSS van mindere kwaliteit zou zijn dan iets wat een individu (e.g. ikzelf) schrijft. In zijn algemeenheid is OSS vast beter.
Nogmaals eerst lezen, dan pas reageren:
Het gaat mij om de vraag of je er verantwoordelijkheid voor kunt/wilt nemen.
Ik snap nog steeds niet hoe je het nou echt precies bedoelt, maar ja, natuurlijk kunnen (nee eigenlijk zullen) er fouten in OSS zitten die echt wel schade kunnen doen. Niet ieder OSS project heeft zoveel vrijwillige ogen op de code als de Linux kernel. Dus kan je de kwaliteit van de Linux kernel ook nooit elders verwachten.

Er zit een bug in en er is een patch beschikbaar gemaakt. Dat is toch een ideale situatie dat iemand anders al een oplossing voor je kan aandragen?
Het slimste is om gewoon een artikelnummer als referentie te gebruiken. Wanneer een betaling wordt gedaan neem je pas de prijs op. Eventueel kun je nog wat spelen met versleutelde tijden/prijswijzigingen.

Als de gebruiker nu een artikelnummer veranderd hij zichzelf het hardste mee, omdat hij iets totaal anders afrekend.
Ofdat closed sourcesoftware veiliger is joh?
Als je dit op je website hebt geďmplanteerd of op een website van je opdrachtgever dan had je al in de source kunnen zien dat er een mogelijk beveiligingsprobleem is. Hier kan je dan naar handelen door of de fout op te lossen en de patch zelf door te voeren en natuurlijk naar de ontwikkelaars te sturen.

Jouw redernatie is dan ook bull-shit! Bij open source kan je dus in de source kijken wat er al gebeurd. Bij closed sourcesoftware moet je maar op de blauwe ogen van de softwarebouwer(s) vertrouwen. Mogelijk dat daar wel een verborgen 'backdoor' in zit die allerlei vertrouwelijke gegevens doorsluist... Maar dat weet je niet en kan je niet weten. Per definitie is dat dus altijd onveilig! Want je weet niet wat de software allemaal doet! :P
Zie ook mijn antwoord verderop. Ik pleit niet ervoor om een closed-source module in te kopen in plaats van een open-source module. Ik signaleer enkel, dat in de praktijk ontwikkelaars niet de complete code van elk onderdeel willen gaan nalopen, dat is ook haast niet te doen zo complex als veel frameworks zijn. Je moet er dus uiteindelijk op vertrouwen dat het open-source element zo veilig is dat je het durft toe te passen. (Of je moet zelf actief in de community van dat product zitten maar je kunt niet in alle communities zitten en alle producten op je duimpje kennen).

De theorie "je had het zelf na kunnen lopen" is dus leuk maar levert geen beter resultaat op vind ik.
Je hoeft het niet zelf na te lopen om het te kunnen vertrouwen, de gedachte dat velen voor jou naar de code hebben gekeken regelt dat. Aan de hand van het versienummer, de activiteit binnen de community, de leeftijd van het project kan je bepalen of je het vertrouwt. Blijkt er dan toch iets niet te kloppen zijn er bij een actieve community genoeg mensen die staan te trappelen om het probleem op te lossen met een volgende release.
Dit toont volgens mij aan dat dat dus niet altijd goed werkt. De gedachte dat "De Community" er wel proactief naar kijkt en de fouten eruit haalt kan ertoe leiden dat iedereen verwacht dat zijn/haar buurman dat wel doet... Deze fout is ook niet door "De Community" gevonden, maar door een "cracker".

Indien een fout naar boven komt kan het bij OSS software snel opgelost worden, maar dit is reactief, niet proactief. Crackers die fouten vinden zullen het in het geheim voor eigen gebruik uitbuiten en niet naar "De Community" doorspelen.
Hoe kom je erbij dat het door een cracker is gevonden (staat namelijk nergens in het artikel)? De bank meldt dit en is in feite een deel van de 'community'. Het werkt dus...

Hoe denk je dat bugs/exploits worden gevonden in closed source software? Kijk eens naar je OS of je office pakket, je browser, je games... Ook allemaal achter de feiten aan lopen, als ze al worden opgelost (ook al heb je een onderhouds contract).
Probleem met OsCommerce, heb ik ontdekt, is dat er geen fatsoenlijke documentatie is.
Er is broncode, ook een rammelende slecht leesbare installatie handleiding, maar geen documentatie over structuur, concept, doelstellingen, ontwerpkeuzen, of wat meer vereist is voor inzicht en om het pakket te kwalificeren als serieus ontworpen. Wat dat betreft heeft mddd een punt, je kunt OsCommerce moeilijk beoordelen.
Logisch dat velen dit niet doen. Zo blijven wel de fouten er in zitten!
Idealm is een losse module, bestaat pas een half jaar in deze vorm, denk ik.
Ook daarvan kon ik geen fatsoenlijke documentatie vinden. Logisch dat er nog fouten in Idealm zitten.
Ik heb verder alleen als gebruiker (gunstige) ervaring met OpenSource software. Ik hoop wel dat OsCommerce een uitzondering is, met de slechte documentatie. Anders moet ik mijn opvattingen over Open Source drastisch aanpassen..
Het lijkt mij dat jouw reactie niet echt ergens op slaat. Het feit dat het opensource is betekent niet automatisch dat het onveilig is, andersom betekent closed-source ook niet automatisch dat het veilig is.

Bij een opensource applicatie kan je tenminste de code er nog eens op naslaan om te zien wat er gebeurd, bij closed source is dat toch wat lastiger lijkt mij.

Feit is dat het gewoon een slordige fout is, en dat heeft m.i. niks te maken met open/closed source.
Ik vind zijn reaktie juist erg zinnig: hij ontkent niet dat je met OS alles ziet hij zegt dat waneer je effectief alles in de OS code moet nagaan je het zowel zelf kan schrijven, en daar heeft hij volgens mij een goed punt, want als je het zelf schrijft is het 100% hetgeen jij wil en niet wat een gemeenschap gedacht heeft dat een grote groep zou willen...
Ook zouden winkeliers moeten controleren of het betaalde bedrag overeenkomt met de orderdatabase, voordat tot levering wordt overgegaan.
Hmm het mooie van iDeal was dat er dan snel geleverd gaat worden in tegenstelling tot overboeking. Als ze nu elke iDeal transactie handmatig moeten controlleren dan gaat het uiteindelijk langer duren. Ik weet niet hoeveel tijd er tussen zit van iDeal verzending en geld ontvangen.
Nee. Je moet gewoon zorgen dat het totaalbedrag niet door de gebruiker te beďnvloeden is, en het uiteindelijke bedrag dat door wordt gegeven aan iDeal eerst verifiëren. Daarnaast is het uit reacties hierboven gebleken dat iDeal zelf een implementatie heeft voor een verificatie, dus die ook gewoon gebruiken. En dit alles onder water, zonder tussenkomst van de gebruiker.
Het bericht werd wel opmerkelijk gelekt, ik heb vandaag als consument 2 maal iets bij een oscommercewinkel besteld en ook 2 maal de mail over het veilgheidslek ontvangen, normaal gesproken krijgt eerst de winkelzijde een mail zodat ze het in orde kunnen maken.

Een extra tip aan IDEAL, als klanten op het veld bevestigen staan, en dan aanvinken stuur deze mail ook aan mij, doe ze dan in een subgroep, zodat ze later uitgesloten kunnen worden van de security mailing.

als we toch bezig zijn........
Zoals de mensen boven mij ook al zeggen: het is een fout van de inplementatie van de software van de winkelier. De communicatie gaat namelijk als volgt:

[Formulier met ordernummer en bedrag] --> via POST naar Bank van winkelier
Controle van totaalbedrag en ordernummer bij winkelier *
Bank van winkelier presenteert keuzelijst met banken voor de klant
Klant kiest zijn eigen bank en betaalt via iDeal.

*Op de achtergrond wordt er normaal gesproken een verzoek van de bank richting de winkelier gedaan, met een POST met het ordernummer. De website van de winkelier moet hierop een XML maken waarin het totaalbedrag staat. Dit gaat compleet buiten de klant om. Zodoende wordt het bedrag geverifieerd. Als het bedrag niet overeenkomt wordt dit aan de klant gemeldt (nog voordat de klant een bank kan kiezen). :)


Maar het blijft natuurlijk vreemd dat de bank een dergelijke controle niet afdwingt!

[Reactie gewijzigd door SysRq op 10 augustus 2007 16:22]

De methode die je beschrijft werkt in elk geval niet bij de ING en Fortis als ik hun documentatie doorlees.
De eerste communicatie die je als shop hebt met iDeal over de betaling is meteen het xml bericht met het totaal bedrag.
Als antwoord krijg je een bericht met de url voor de klant terug. Hierin zit geen bedrag, maar alleen het order nummer verwerkt.
De klant gaat daarna meteen naar zijn bank om de betaling te doen. Vervolgens kun je de verplichte status request doen, maar ook hier krijg je geen bedrag terug van ideal.

Kortom ik zie nergens een mogelijkheid om het bedrag te verifieren nadat je het betaalproces met iDeal hebt opgestart.

Als je een verwijzing voor me hebt, heel graag. Ik heb namelijk ook een (open source) ideal module in ruby geschreven en wil deze uiteraard zo veilig mogelijk hebben.
Zo heb ik laatst nog van een prachtige osCommerce bug mogen genieten. Al klant was het mogelijk om 1.5 stuks van een product (van ¤60) te kiezen. Bij het orderbedrag stond dan ook doodleuk anderhalf keer de prijs van het product (¤90). Bij het uiteindelijk bestellen van het product werd dit weer op 1 teruggezet, terwijl er 2 stuks van het voorraadbeheer afgehaald werd. Bij het terugzien van de order was het totaal bedrag ¤90, met een product-totaal van ¤60.

Dit is exact hetzelfde: Gebruikersinput is nooit te vertrouwen!
Dat probeer ik ook altijd voor de grap als ik wat bestel :)
-1 artikelen bestellen doet het ook altijd leuk!

Je staat er nog van te kijken hoevaak zoiets gewoon mogelijk is, zo moeilijk is het toch niet om te checken of er een heel, positief getal in dat veld staat zou je denken :)
Virtuemart geeft ook leuke bedragen inc. BTW. random 1 a 2 cent teveel of te weinig..
Ze ronden bijna in elke functie het bedrag af. Zeer slecht geprogrammeerd vind ik.
Het probleem zit volgens mij in het ideal protocol. Afhankelijk van de bank en pakket (basis/geavanceerd) wordt het volgende aangeboden:

1) winkel dient een POST-form te sturen naar de ideal-site van de winkel
2) bank verwijst de klant na betaling door naar een vooraf gespecifeerde url (eigenlijk 4: succes, failure, cancel en nog een). Er worden geen gegevens meegestuurd over de betaling (zoals het bedrag).

Dit maakt het onmogelijk een foolproof betalingssysteem te maken. Of zie ik dit verkeerd?
Een extra module van een softwarepakket voor webwinkeliers blijkt door derden zoals klanten manipuleerbaar te zijn. Hoe je het ook een draai geeft, de webwinkel heeft er in de eerste plaats al voor te zorgen dat de klant nooit en te nimmer het bedrag voor de betaling kan aanpassen en een verkeerd bedrag voor verwerking bij iDeal wordt aangeboden. Als het daar namelijk al mis gaat en de controle niet eens correct is maakt het niets uit of de bank nu wel of niet een bedrag van een volbrachte transactie nogmaals kenbaar maakt. Dan is het al veel en veel te laat in het proces om verdere fouten te voorkomen.
Dus dit is meer schadelijk voor de winkels? Dus een 'winkelier' zou de waardes kunnen veranderen in hun voordeel? als ik het goed begrijp?
Nee, de klant kan het bedrag naar beneden schroeven, naar eigen believen. Normaal kan je dat niet aanpassen, maar door de aangepaste parameter is dat dus wel mogelijk.
Als de winkelier het zou doen, dan accepeteer je het gewoonweg niet, toch?
Yap goed gezien, ik koop een plasma voor 3000 euro, verander het bedrag naar een willekeurig bedrag (of 0) en vervolgs druk ik op accepteren en heb de betaling volledig gedaan volgens ideal, wat dus ook "volledig" wordt ingevuld op de website.

Ofwel je kan producten kopen voor een "eigen" ingevulde prijs simpel gezegt ;)
"Helaas" zal een winkelier altijd zijn bank gegeven controleren met het order bedrag.
Die bankgegevens zie je pas een dag later. Dan is het hele voordeel van IDeal naar de haaien. IDeal is bedoeld als Direct en Gegarandeerd betaalsysteem, waarbij de winkelier er op moet KUNNEN vertrouwen dat als een artikel als betaald staat dat het geld MORGEN op zijn rekening staat.

Dit bespaard dus 1 dag levertijd, iets waar de klanten hard om vragen.
Dit bespaard dus 1 dag levertijd, iets waar de klanten hard om vragen.
Bij de goede webwinkels kan je nog steeds onder rembours bestellen, wat resulteert in dezelfde levertijd. Sommige winkels buiten dit echt uit om er extra geld uit te slaan, bij andere winkels valt de remboursprijs hartstikke mee.
Doet me denken aan de supermarkt truuk, waarbij je een stickertje van een goedkope luidspreker set plakt overdie van een duur hifi systeem (met DAB :p).
Winkelier zal niet doorhebben dat het om een ander product gaat.

Maar ik ben veel te eerlijk om zo iets uit te proberen..
Is inderdaad het zelfde principe. Een vriend van mij ging als kind stickers van NES games aftrekken om ze dan op een SNES spel te plakken en dan af te rekenen bij de meest onnozel-uitziende cassiere. Gelukkig is een volledig geautomatiseerd systeem wat minder makkelijk te foppen.
Alleen als het je wel lukt om zo'n volledig geautomatiseerd systeem te foppen zullen ze er niet zo heel snel achter komen in de meeste gevallen.
Maar het werkt vaak wel ;)
Meer in supermarkten, heb je vaak van die "afprijs" stickers voor dingen die bijna over datum zijn.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True