[PHP] iDeal integratie onveilige form

[Verwijderd]

Hallo allemaal,

Ik ben nieuw hier, dus hoop dat ik goed zit.
Mijn probleem is het volgende:

Als mensen op de webshop producten in hun mandje hebben, en naar de checkout vervolgen.
Dan kun je in de html source gevoelige velden zien, het is dus de bedoeling,
alleen de shop velden weer te geven. Dit naar een eigen script sturen ideal cq paypal velden
toevoegen, en dan het geheel in POST vars naar danwel ideal of paypal sturen.

Nu heb ik wel het een en ander over curl gevonden. Maar b.v. een van de vereiste van iDeal is
dat de gebruiker op het moment van versturen van de form geredirect wordt naar dat zelfde adres.

Naar wat ik begrijp uit wat ik heb gelezen over curl, is dat niet mogelijk.
Maar kun je alleen de response terug krijgen in een variable.

Ik hoop dat ik het duidelijk uiteen heb gezet.
Elk advies word zeer op prijsgesteld,

Jonathan Lourens

[Standeman]

En wat is nu precies het verschil tussen POST vars en GET vars?? Qua veiligheid helemaal niets.... net zoals dat hele curl verhaal, dat heeft ook niets met veiligheid te maken (en ik ken het hele curl niet eens).

Wat wil je nu eigenlijk vertellen, dat ideal niet veilig is.. of PHP... of curl???

[Gomez12]

Waarom wil je die gevoelige velden eruit halen? Zijn het wel gevoelige velden?

Zeker met ideal-zaken moet je dit heel goed in je achterhoofd houden.

Als jij namelijk ideal velden server side gaat versturen dan doet opeens jouw server de betaling en de klant niet meer.

Ja, je kan die POST Velden veranderen als client zijnde, maar wat dan? Dan betaalt de client ipv 10 euro 1 eurocent. Jij kan gewoon bij ideal opvragen wat het bedrag precies was dus geef je een melding dat er maar 1 eurocent betaald is ipv 10 euro en je verstuurt het goed niet.

[BCC]

Ideal kent meerdere implementaties met meerdere gradaties van veiligheid. De simpelste (en meest onveilige) is een formulier dat jij served en dat dan naar iDeal gepost wordt.

Hier staan "gevoelige" velden in, zoals het bedrag en het doel rekeningnummer. iDeal vereist ook dat indien je deze methode gebruikt, je zelf de verwachte bedragen moet controlleren met de daadwerkelijk ontvangen bedragen, omdat iDeal natuurlijk niet kan weten of iemand de velden in het formulier heeft aangepast.

Wanneer je dit geheel veiliger wil, moet je naar een complexere variant van iDeal gaan. Oftewel: Lees je even in in de (on)mogelijkheden van iDeal.
http://www.rabobank.nl/be...erkeer/via_internet/ideal
Ranzige implementaties met Curl gaan de veiligheid iig niet verhogen.

[ Voor 14% gewijzigd door BCC op 22-07-2008 08:41 ]

[Cartman!]

Je haalt 2 dingen door elkaar. Curl is serverside en daar kan de client niets van merken maar in het geval van de simpele ideal implentatie moet dat helemaal niet. En zoals eerder gezegd, controleren van bedragen en betalingen moet je zelf doen.

[Eijkb]

Vraag me ook af wat dan precies de gevoelige velden zijn... Denk dat het toch allemaal info is die verstuurd moét worden voor een goede afwikkeling.

[Voutloos]

Eijkb schreef op dinsdag 22 juli 2008 @ 08:44:
Denk dat het toch allemaal info is die verstuurd moét worden voor een goede afwikkeling.

Dat het toch moet gebeuren betekent nog niet dat je de eindgebruiker compeet kan vertrouwen op het intact houden van deze data, en dat moet je dus met de simpelste iDeal implementatie wel doen.

Anyway aangezien TS bljkbaar het een en ander kan en wil implementeren kan deze gewoon voor het betere protocol gaan.

[Cartman!]

Voutloos, de beheerder van de shop moet gewoon zelf achteraf checken of het goede bedrag wel is overgemaakt. Als ie heeft zitten rommelen met bedragen oid dan stuur je die persoon gewoon een mail dat ie het resterende bedrag nog even moet voldoen voor ie t produkt krijgt, zo simpel is het.

Bij PayPal is dat nog leuk want je kunt een betaling doen en akkoord terugkrijgen en een tijdje later kan iemand zn betaling weer intrekken. Heb een klant gehad die het teveel load vond om paypal data te updaten en die had het maar uitgezet

[Verwijderd]

Er zijn vele ideal implementaties maar de implementaties waar ik mee bekend ben kan je in twee groepen indelen.

- Simpel en handmatige verificatie
Door het copy/pasten van een formulier op je website (en dat server-side in te vullen) link je de klant naar het ideal systeem van de bank, of een PSP(payment service provider). De klant betaald (of niet) en daar houd het ideal gebeuren eigenlijk op.

Hoewel de klant de waarden van het formulier kan wijzigen, heeft hij daar niets aan. De status van een betaling wordt niet automatisch naar de webwinkel teruggekoppeld, dus een mens zal de inkomende betalingen moeten verwerken. Hierdoor is de 'beveiliging' precies hetzelfde als bij een normale bank-overschrijving. Je kan wel een verkeerd bedrag overmaken, of een factuurnummer veranderen, maar daar heb je helemaal niks aan...

Deze methode wordt gebruikt in de 'lite' en gratis versies die banken aanbieden


- Complex(er) en automatische verificatie
Net als bij bovenstaande methode wordt een formulier ingevuld, dit dirigeert de gebruiker naar een bank of PSP, en deze koppelt de betalingsstatus weer terug naar de webwinkel.

Omdat in dit geval betalingen wel automatisch verwerkt worden is beveiliging hiervan van belang. De PSP's waar ik mee bekend ben (oGone, buckaroo) voegen een extra veld toe aan het formulier waarin een versleutelde (MD5 uit mijn hoofd) waarde staat van alle critische velden en een geheime sleutel, die in princiepe alleen bij jouw en de PSP bekend is. Ook de terugkoppeling werkt op een soortgelijke manier

'Nadeel' van deze methode is dat het een maandelijks bedrag kost, maar deze kosten zijn relatief laag (afaik vanaf 35 euro per maand bij buckaroo). Maar als je een webwinkel hebt, en je hebt niet eens 35 euro over voor een dergelijke(in nederland erg populaire) betaalmogelijkheid dan ben je imho verkeerd bezig.

--
IMHO is het niet zo dat de ene manier onveiliger is dan de andere, maar bij de tweede manier gaat de automatisering gewoon wat verder, en daardoor zijn meer technische beveiligings middelen noodzakelijk.

PS. Ik ken geen betalingssysteem waarbij het rekeningnummer van de ontvanger in het formulier vermeld dient te worden. In plaats van dat je moeilijk gaat doen om hier om heen te werken zou ik voor een ander betaalsysteem kiezen.

PS 2: Zelfs al weten ze je rekeningnummer, het ergste wat ze kunnen doen is geld naar je rekening laten overmaken. Ik denk niet dat je dat erg zal vinden

[ Voor 3% gewijzigd door Verwijderd op 22-07-2008 13:44 ]

[CrashOne]

BCC schreef op dinsdag 22 juli 2008 @ 08:37:
[..]

Hier staan "gevoelige" velden in, zoals het bedrag en het doel rekeningnummer. iDeal vereist ook dat indien je deze methode gebruikt, je zelf de verwachte bedragen moet controlleren met de daadwerkelijk ontvangen bedragen, omdat iDeal natuurlijk niet kan weten of iemand de velden in het formulier heeft aangepast.

[..]

Onzin, je post een hash mee die je maakt met door een private key en alle velden te hashen. Het aanpassen van een veld is mogelijk, maar dan accepteert de iDeal server de transactie nooit omdat de hash niet klopt.

[BCC]

CrashOne schreef op dinsdag 22 juli 2008 @ 13:49:
[...]
Onzin

Dat is dus alleen bij de extra beveiligde variant die geld kost. Lees ff de 10 reacties hierboven.

[ Voor 43% gewijzigd door BCC op 22-07-2008 17:56 ]

[Borizz]

BCC schreef op dinsdag 22 juli 2008 @ 16:53:
[...]

Dat is dus alleen bij de extra beveiligde variant die geld kost. Lees ff de 10 reacties hierboven.

Dat betwijfel ik, waar heb je dit vandaan? Enkel uit de reacties? Heb je ook een link/document met deze informatie. Ik heb al verschillende malen met een implementatie van ideal te maken gehad, maar dit lijkt me toch wel heel onveilig.Bij mijn weten wordt er als minimale beveiliging altijd gebruik gemaakt van een (SHA1 of andere) hash met een private key.

Bijvoorbeeld uit hoofdstuk 4.1 Beveiliging van de Rabobank handleiding over iDEAL lite:

In het Rabo iDEAL Dashboard dient u voor zowel de test als productieomgeving een beveiligingssleutel op te geven via het tabblad ‘Integratie’ die u ook gebruikt bij de berekening van de hashcode over een betalingsverzoek.

BCC schreef op dinsdag 22 juli 2008 @ 08:37:
Wanneer je dit geheel veiliger wil, moet je naar een complexere variant van iDeal gaan. Oftewel: Lees je even in in de (on)mogelijkheden van iDeal.
http://www.rabobank.nl/be...erkeer/via_internet/ideal

Oftewel kijk zelf even op de betreffende url..

[ Voor 45% gewijzigd door Borizz op 22-07-2008 22:43 ]

[CrashOne]

BCC schreef op dinsdag 22 juli 2008 @ 16:53:
[...]

Dat is dus alleen bij de extra beveiligde variant die geld kost. Lees ff de 10 reacties hierboven.

Ik heb zelf implementaties van iDeal gedaan, en kan je verzekeren dat de basis variant ook goed beveiligd is (zoals ik al aan gaf). Er is clientside geen invloed uit te oefenen op de geposte waarden zonder dat de iDeal server een error geeft.

[Janoz]

Borizz en CrashOne, zouden jullie mij die extra veilige sha1 hash aan kunnen wijzen in het stukje html code op pagina 8 van de door Borizz geposte handleiding?

@hieronder:
Ik heb inderdaad gezien dat in hoofdstuk 4 een andere versie wordt behandeld waarbij wel een hash berekend wordt. De mensen boven mij beweerde dat er altijd met een hash gewerkt werd. Dat is dus niet zo.

[ Voor 40% gewijzigd door Janoz op 23-07-2008 09:17 ]

[RobIII]

Janoz schreef op woensdag 23 juli 2008 @ 09:01:
Borizz en CrashOne, zouden jullie mij die extra veilige sha1 hash aan kunnen wijzen in het stukje html code op pagina 8 van de door Borizz geposte handleiding?

Psst, scroll eens een tikje verder

[CrashOne]

Janoz schreef op woensdag 23 juli 2008 @ 09:01:
Borizz en CrashOne, zouden jullie mij die extra veilige sha1 hash aan kunnen wijzen in het stukje html code op pagina 8 van de door Borizz geposte handleiding?

Heel hoofdstuk 4 gaat daar over, op pagina 8 wordt hierover niks gezegd.
De versie zonder hash werkt met controle van van de vooraf ingevoerde artikelen in iDeal (inclusief prijs). Deze versie is echter super onhandig, omdat je maar 1 artikel per transactie kan bestellen en dus totaal niet relevant voor wat de TS wilt (een winkelmandje met artikelen) en je alle artikelen handmatig in iDeal moet invoeren.

Wat dat betreft heeft BCC gelijk, er is een versie zonder hash, alleen kan je dan nog niks omdat alles nog een keer aan de kant van iDeal wordt gecontroleerd (aan de hand van wat daar ook bekend is over het product).

[BCC]

Ik weet iig zeker dat ze vroeger geen hash hadden en dat je dan relatief eenvoudig iets naar een cent kon veranderen, waarna sommige webshops gewoon je bestelling uitleverden. Hebben ze niet recent de beveiliging iets meer opgeschroefd?

Ps. waar is te TS gebleven eigenlijk ?

[ Voor 8% gewijzigd door BCC op 23-07-2008 09:37 ]

[RobIII]

BCC schreef op woensdag 23 juli 2008 @ 09:37:
Ik weet iig zeker dat ze vroeger geen hash hadden

Niet om nou door te blijven emmeren hierover, want het boeit niet _{het kan immer dus wel}, ik heb iDeal implementaties vanaf het eerste uur gedaan en AFAIK zaten die hashes er toen al in (weet alleen niet of dat ook in de 'basic'/'lite' variant was).

Then again, mijn geheugen vertoont wel vaker gelijkenissen met een zeef Maar ik ben vrij zeker dat die hash er vanaf de eerste dag in zat (zal ook wel moeten wil je iDeal een beetje fatsoenlijk in de markt willen zetten en een brede acceptatie bereiken).

[ Voor 24% gewijzigd door RobIII op 23-07-2008 09:41 ]

[Borizz]

RobIII schreef op woensdag 23 juli 2008 @ 09:40:
[...]

Niet om nou door te blijven emmeren hierover, want het boeit niet _{het kan immer dus wel}, ik heb iDeal implementaties vanaf het eerste uur gedaan en AFAIK zaten die hashes er toen al in (weet alleen niet of dat ook in de 'basic'/'lite' variant was).

Then again, mijn geheugen vertoont wel vaker gelijkenissen met een zeef Maar ik ben vrij zeker dat die hash er vanaf de eerste dag in zat (zal ook wel moeten wil je iDeal een beetje fatsoenlijk in de markt willen zetten en een brede acceptatie bereiken).

Hetzelfde geldt voor mij, ik heb nooit anders gezien dan dat er een hash inzat. En dat met centen knoeien verhaal lijkt me ook erg onwaarschijnlijk dat is toch het eerste wat getest zal worden als het om dit soort applicaties gaat. Maar goed ik kan er natuurlijk ook naast zitten .

[Verwijderd]

Borizz schreef op woensdag 23 juli 2008 @ 22:21:
[...]

Hetzelfde geldt voor mij, ik heb nooit anders gezien dan dat er een hash inzat.

Ik heb een maand geleden nog 'iDeal Easy' van ABN-Amro geintegreerd en deze bevat geen hash. Ik dacht even dat alle easy/lite systemen hetzelfde waren omdat volgens de documentatie van iDeal Easy ook geen return pagina's kunnen worden opgegeven, maar als je op dit gebeid de handleiding van de rabobank volgt dan werkt het stiekem wel...

[CMG]

Wat ik doe met paypal is het volgende:

Data in een querystring naar paypal, alle instellingen worden middels een unique key opgeslagen, deze wordt ook meegestuurd naar paypal. Als iemand de querystring aanpast (bijv. bedrag omlaag, etc), dan wordt de betaling op mijn server geweigerd (paypal betaling is wel doorgegaan, maar klant krijgt geen license/serial, hij heeft namelijk dingen aangepast waar hij niet aan mocht zitten). Op die manier is het welliswaar mogelijk om de betaling aan te passen, maar als de gegevens die terug komen van paypal niet overeen komen met de link die ik voor de gebruiker heb aangemaakt, is de betaling niet gelukt. Als je je betalingen op die manier op zet loop je iig niet het gevaar dat er dingen fout gaan waar jij de dupe van wordt, de klant wordt de dupe, maar dat is niet zo'n probleem aangezien hij het zelf heeft veroorzaakt.

[BCC]

CMG schreef op maandag 28 juli 2008 @ 23:42:
Wat ik doe met paypal is het volgende:

Data in een querystring naar paypal, alle instellingen worden middels een unique key opgeslagen, deze wordt ook meegestuurd naar paypal. Als iemand de querystring aanpast (bijv. bedrag omlaag, etc), dan wordt de betaling op mijn server geweigerd

Dus je moet ook even de returnstring aanpassen? Of stuurt Paypal iets rechtstreeks naar jouw toe?

[ Voor 5% gewijzigd door BCC op 29-07-2008 00:01 ]

[Gomez12]

CMG schreef op maandag 28 juli 2008 @ 23:42:
Wat ik doe met paypal is het volgende:

Data in een querystring naar paypal, alle instellingen worden middels een unique key opgeslagen, deze wordt ook meegestuurd naar paypal. Als iemand de querystring aanpast (bijv. bedrag omlaag, etc), dan wordt de betaling op mijn server geweigerd (paypal betaling is wel doorgegaan, maar klant krijgt geen license/serial, hij heeft namelijk dingen aangepast waar hij niet aan mocht zitten). Op die manier is het welliswaar mogelijk om de betaling aan te passen, maar als de gegevens die terug komen van paypal niet overeen komen met de link die ik voor de gebruiker heb aangemaakt, is de betaling niet gelukt. Als je je betalingen op die manier op zet loop je iig niet het gevaar dat er dingen fout gaan waar jij de dupe van wordt, de klant wordt de dupe, maar dat is niet zo'n probleem aangezien hij het zelf heeft veroorzaakt.

Ik hoop wel dat je bij een foutieve string wel een mailtje naar jezelf genereerd ter nacontrole. Zal niet de eerste keer zijn dat ik brakke software-firewall / spyware zie die willekeurige post-data verminkt.

[CMG]

BCC schreef op dinsdag 29 juli 2008 @ 00:01:
[...]

Dus je moet ook even de returnstring aanpassen? Of stuurt Paypal iets rechtstreeks naar jouw toe?

Paypal heeft IPN (Instant Payment Notification). Deze sturen de data van de betaling naar een door jouw opgegeven pagina. Als bevestiging post je de ontvangen data nog eens terug naar PayPal, zij zullen dan nog eens bevestigen.

Dus 1: Bouw je query op om naar paypal te sturen. Voeg daarbij een unique key toe waarmee je de gegevens die je gegenereerd hebt vast legd in je database. Deze key zal je als custom veld ook van paypal terug krijgen

2: je krijgt de betalings info van paypal. Post dit weer terug naar paypal om er zeker van te zijn dat het van paypal af kom. Als dit ok is, vergelijk het dan met wat je zelf hebt opgeslagen (aan de hand van de unique key in een custom veld). Als dit ok is -> Betaling gelukt.

Gomez12 schreef op dinsdag 29 juli 2008 @ 07:02:
[...]

Ik hoop wel dat je bij een foutieve string wel een mailtje naar jezelf genereerd ter nacontrole. Zal niet de eerste keer zijn dat ik brakke software-firewall / spyware zie die willekeurige post-data verminkt.

Zie ook stappen plan boven, daar is aan gedacht

Daarnaast wordt alles, maar dan ook echt alles opgeslagen zodat je altijd dingen kan nazoeken. Is an zich wel leuk, kun je ook zien hoeveel mensen naar PayPal gaan en dan toch nog zo iets hebben van: toch maar niet (ratio mensen die interesse hebben t.o.v. mensen die de betaling ook echt door laten gaan).

[ Voor 10% gewijzigd door CMG op 30-07-2008 00:25 ]

[BCC]

CMG schreef op woensdag 30 juli 2008 @ 00:24:
Is an zich wel leuk, kun je ook zien hoeveel mensen naar PayPal gaan en dan toch nog zo iets hebben van: toch maar niet (ratio mensen die interesse hebben t.o.v. mensen die de betaling ook echt door laten gaan).

Is dat omdat ze het toch te duur vinden, of omdat paypal afschrikkend werkt denk je?