Studenten bestellen pizza's voor een cent

[Arjan A]

Lees dit artikel eens.
In het kort: Studenten van oa Nyenrode hebben een gat of een fout ontdekt in de iDeal-koppeling met de bestelsite justeat.nl. Hierdoor kunnen ze voor een cent pizza's bestellen.

In het artikel staat (in vrij algemene bewoordingen) beschreven wat ze hebben gedaan. En dat snap ik niet. Ik heb zelf ook meerdere betaalsites ontwikkeld, en vraag mij dus af of dit bij elke site had kunnen gebeuren of dat dit specifiek aan justeat ligt.

Ik ben dus eigenlijk nieuwsgierig (zonder misbruik te willen maken) naar de manier waarop dit is gebeurd. Zijn er mensen die daar meer van weten, of die dat kunnen uitleggen?

[Koffie]

De meeste koppelingen tussen dergelijke sites loopt via POST messages. Als je dus op de een of andere manier kan beinvloeden wat er in moet staan, is er een kans dat je kunt beinvloeden hoe hoog het bedrag is.
Een andere mogelijk zou kunnen zijn dat je doet alsof je betaald, maar weigerd, en vervolgens een andere code laat posten waardoor de shop denkt dat iDeal verteld dat de betaling succesvol is.

[Trommelrem]

Los van dat snap ik niet waarom de studenten hun identiteit klaarblijkelijk bekend hebben gemaakt. Slimme studenten houden dergelijke zaken voor zichzelf en gaan gewoon jarenlang gratis eten. Valt vaak niet eens op.

[.oisyn]

Trommelrem schreef op vrijdag 16 oktober 2009 @ 11:33:
Slimme egoïstische studenten

Fixed. Heeft niets met intelligentie te maken.

[Anoniem: 218213]

naja, dat komt vrij snel terug in de boekhouding hoor

veel pizza's verkocht weinig winst

maar wel een grote blunder imo

[Rukapul]

.oisyn schreef op vrijdag 16 oktober 2009 @ 11:38:
[...]

Fixed. Heeft niets met intelligentie te maken.

Just-Eat dient dan ook aangifte te doen en daarnaast ook het verschuldigde bedrag te innen.

[Arjan A]

Koffie schreef op vrijdag 16 oktober 2009 @ 11:32:
De meeste koppelingen tussen dergelijke sites loopt via POST messages. Als je dus op de een of andere manier kan beinvloeden wat er in moet staan, is er een kans dat je kunt beinvloeden hoe hoog het bedrag is.
Een andere mogelijk zou kunnen zijn dat je doet alsof je betaald, maar weigerd, en vervolgens een andere code laat posten waardoor de shop denkt dat iDeal verteld dat de betaling succesvol is.

Je zou dat kunnen beinvloeden, maar de gateways die ik heb gebruikt zoeken altijd zelf nog contact met de shop. In zowel de shop als de gateway definieer je de hostnames én de IP-adressen van elkaar, zodat ze van elkaar weten dat ze met elkaar communiceren. Het liefst nog via SSL ook.

Ik vermoed dat bij Justeat daar de configuratie fout is gegaan, of (en dat zou erger zijn) dat er nooit rechtstreekse communicatie plaatsvindt tussen de gateway en de shop.

Dan nog, hoe kom je daar achter...

[JayVee]

Ik heb ooit een iDeal koppeling geschreven, en daarbij moest ik (op de site van onze klant) een hash maken van (secret + ordernr + prijs), en deze werd door de browser (hier kun je dus hacken!) samen met ordernr en prijs naar de bank gestuurd. Deze maakt dezelfde hash en vergelijkt die. Als die niet overeen komt weet de bank dat er mee geknoeid is.

Mijn gok is dat de jongens zelf hashes kunnen maken (omdat ze bijv. achter het secret zijn gekomen). Nu kunnen ze de post van justeat naar bank veranderen, en de bank ziet een correcte hash (die eigenlijk alleen door justeat gemaakt had kunnen worden!) en geeft justeat een signaal dat "de betaling" voor "ordernr" binnen is.

Denk dat het ongeveer zo werkt.

[ Voor 4% gewijzigd door JayVee op 16-10-2009 11:47 ]

[Trommelrem]

.oisyn schreef op vrijdag 16 oktober 2009 @ 11:38:
[...]

Fixed. Heeft niets met intelligentie te maken.

Dan nog blijven het slimme studenten. Niemand is in één hokje te plaatsen, iedereen is in meerdere hokjes te plaatsen.
Ook de studenten die het hebben bekendgemaakt zijn egoistisch. Eerst maandenlang goedkoop eten en dan pas bekendmaken.

Rukapul schreef op vrijdag 16 oktober 2009 @ 11:43:
[...]

Just-Eat dient dan ook aangifte te doen en daarnaast ook het verschuldigde bedrag te innen.

Dat krijgen ze ook, de studenten hebben zich klaarblijkelijk bekend gemaakt. Samen met de logs is alles te herleiden naar de studenten

[ Voor 30% gewijzigd door Trommelrem op 16-10-2009 11:46 ]

[RobIII]

De meeste payment providers waarmee ik heb gewerkt bevatten een extra controle in de vorm van een hash van bedrag + overige betaal info + (geheime) salt ofzo om te controleren of de gePOSTte gegevens wel correct zijn (en ik meen zelfs dat er daarna nog een POST gedaan wordt vanuit de payment provider naar de site als de betaling afgerond is). Dit is, afaik, redelijk standaard. Dus of er liggen wat geheime gegevens op straat van die site, of de implementatie is slecht gedaan. Lijkt me niet iets structureels (maar then again: Never say never )

[ Voor 6% gewijzigd door RobIII op 16-10-2009 11:46 ]

[SinergyX]

Trommelrem schreef op vrijdag 16 oktober 2009 @ 11:33:
Los van dat snap ik niet waarom de studenten hun identiteit klaarblijkelijk bekend hebben gemaakt. Slimme studenten houden dergelijke zaken voor zichzelf en gaan gewoon jarenlang gratis eten. Valt vaak niet eens op.

Vermoedelijk dat ze daarvoor ook gewoon netjes hun pizza's bestelden, maar met dit gat het tijdje dus gratis deden. Meeste hebben dan echt niet door dat ze dan nieuw account moeten maken met een ander adres (anders is het nog simpel te herleiden).

Niet nader te noemen boekhandel had dit ook, via een post (zonder check van afkomst) was er enkel een betaald=yes value bij gekomen. Geld van die betaalsystemen krijg je veelal later, maar zij gaan er gewoon vanuit dat het werkte en gingen uitleveren. In de oude dagen van Paypal was dit zelfs mogelijk.

[ Voor 20% gewijzigd door SinergyX op 16-10-2009 11:47 ]

[NRGetic]

Trommelrem schreef op vrijdag 16 oktober 2009 @ 11:44:
Dat krijgen ze ook, de studenten hebben zich klaarblijkelijk bekend gemaakt. Samen met de logs is alles te herleiden naar de studenten

Just-eat kan ook getipt zijn, waardoor ze erachter zijn gekomen. Mss was het een student met gewetensbezwaren o.i.d.

/edit of wilde gewoonweg van zijn verslaving afkicken

[ Voor 7% gewijzigd door NRGetic op 16-10-2009 11:52 ]

[Mx. Alba]

In de administratie komt zo'n massa aan één-cent-pizza's ook vanzelf bovendrijven hoor. Hoop ik voor ze...

[NMe]

Zoals ik het begreep uit het bericht op nu.nl zat het lek gewoon in de website zelf, nog voordat iDeal ermee te maken had. Ik kreeg sterk het vermoeden dat het iets te maken heeft met het bestelnummer en het totaal apart doorgeven.

edit:

Inderdaad dus, blijkbaar.

418O2 schreef op vrijdag 16 oktober 2009 @ 11:59:
deze fout is al tijden bekend en dat hadden ze wel kunnen weten.

Ergens werd de waarde als hiddenfield meegegeven, dat kon je gewoon wijzigen.

[ Voor 39% gewijzigd door NMe op 16-10-2009 12:56 ]

[DDX]

SinergyX schreef op vrijdag 16 oktober 2009 @ 11:45:
[...]

Vermoedelijk dat ze daarvoor ook gewoon netjes hun pizza's bestelden, maar met dit gat het tijdje dus gratis deden. Meeste hebben dan echt niet door dat ze dan nieuw account moeten maken met een ander adres (anders is het nog simpel te herleiden).

Tja leuk een ander adres, alleen klein detail dat je iets overhandig moet krijgen

[Wolly]

Reactie van iemand bij SpitsNieuws:

Voor diegenen die willen weten en willen proberen het zelfde te doen:

Gebruik FireFox en download the add-on Firebug (legale add-on te gebruiken voor het coden van websites in real time). Je verandert gewoon het bedrag daar mee en voila, de zo genaamde hack welke in het geheel geen hack is) is gedaan.

[Mx. Alba]

@ Wolly, dan krijgen ze er nog een flinke kluif aan om hun geld terug te krijgen denk ik...

[.oisyn]

Trommelrem schreef op vrijdag 16 oktober 2009 @ 11:44:
[...]


Dan nog blijven het slimme studenten.

Jij zegt: "slimme studenten houden het voor zichzelf". Het voor zichzelf houden heeft niets met intelligentie te maken, dát was mijn punt. En als je iets van logica snapt snap je ook dat dat niet impliceert dat die mensen niet slim zouden kunnen zijn.

[ Voor 15% gewijzigd door .oisyn op 16-10-2009 14:26 ]

[Peedy]

Crosspostje;

Ik hoorde een poos geleden al van een dergelijke 'hack' en ben toen zelf even op de JustEat site gaan speuren. Uitkomst; het totaalbedrag stond in een hidden input field. Met een browser als Firefox of Opera is heel simpel de DOM aan te passen dus kon je het bedrag in dit input field veranderen naar 1 cent. Vervolgens submit je het form en moest je bij iDeal dat bedrag betalen. De check of de meegegeven waarde daadwerkelijk klopte mist dus bij de checkout pagina. Fout van Just Eat, ze probeerden zelfs ook nog de schuld eerst op iDeal af te schuiven. Prutsers.

Spuit 13

JayVee schreef op vrijdag 16 oktober 2009 @ 11:44:
Ik heb ooit een iDeal koppeling geschreven, en daarbij moest ik (op de site van onze klant) een hash maken van (secret + ordernr + prijs), en deze werd door de browser (hier kun je dus hacken!) samen met ordernr en prijs naar de bank gestuurd. Deze maakt dezelfde hash en vergelijkt die. Als die niet overeen komt weet de bank dat er mee geknoeid is.

Mijn gok is dat de jongens zelf hashes kunnen maken (omdat ze bijv. achter het secret zijn gekomen). Nu kunnen ze de post van justeat naar bank veranderen, en de bank ziet een correcte hash (die eigenlijk alleen door justeat gemaakt had kunnen worden!) en geeft justeat een signaal dat "de betaling" voor "ordernr" binnen is.

Denk dat het ongeveer zo werkt.

Jij bent een goede programmeur, want jij dénkt aan die hash en het checken ervan. De programmeurs die JustEat hebben gebouwd hebben deze stap simpelweg overgeslagen.

Trommelrem schreef op vrijdag 16 oktober 2009 @ 11:33:
Los van dat snap ik niet waarom de studenten hun identiteit klaarblijkelijk bekend hebben gemaakt. Slimme studenten houden dergelijke zaken voor zichzelf en gaan gewoon jarenlang gratis eten. Valt vaak niet eens op.

Bekend hebben gemaakt? Als jij een pizza bestelt laat je die thuisbezorgen; dan geef je toch je adres op? JustEat heeft gewoon alle bestelling van 1 tot 5 cent in hun database geanalyseerd en getraced naar de steden Breukelen, Groningen en Utrecht.

[ Voor 61% gewijzigd door Peedy op 16-10-2009 13:13 ]

[evaarties]

Mijn aanpak is dan ook om alleen de artikelnummers te posten, de bedragen zoek je serverside wel weer bij elkaar.

[Djordjo]

Zullen ze blij mee zijn bij een bank, artikelnummers

[Arjan A]

Dat is dan wel heel erg slecht. Bijna zo slecht dat ze het verdienen om zo'n verliespost te krijgen.
Je vraagt je zelfs af of dit nog wel oplichting is, zo stom als dit zo geïmplementeerd is...

Ik vraag me alleen af hoe het kan dat iDeal zulke data accepteert. Dat is toch vragen om moeilijkheden. Elke andere site die zijn bedragen via POST-values verstuurt, is op deze manier ook te beïnvloeden. Ik durf het eigenlijk geen oplichting te noemen.

[evaarties]

Arjan A schreef op vrijdag 16 oktober 2009 @ 13:14:
Dat is dan wel heel erg slecht. Bijna zo slecht dat ze het verdienen om zo'n verliespost te krijgen.
Je vraagt je zelfs af of dit nog wel oplichting is, zo stom als dit zo geïmplementeerd is...

Ik vraag me alleen af hoe het kan dat iDeal zulke data accepteert. Dat is toch vragen om moeilijkheden. Elke andere site die zijn bedragen via POST-values verstuurt, is op deze manier ook te beïnvloeden. Ik durf het eigenlijk geen oplichting te noemen.

De iDeal koppeling zal waarschijnlijk op de server worden afgehandeld, daar komt de gebruiker niet tussen.

[NMe]

JorgD schreef op vrijdag 16 oktober 2009 @ 13:14:
Zullen ze blij mee zijn bij een bank, artikelnummers

Die artikelnummers stuur je niet naar de bank, en het bedrag stuur je niet naar de klant. Het bedrag was aan te passen op de website van JustEat (dom!) terwijl die gewoon intern moet blijven totdat de server zelf het request stuurt naar de bank waar het bedrag in staat... Vervolgens is de bank juist blij met bestelnummers.

[Da Weef]

Arjan A schreef op vrijdag 16 oktober 2009 @ 13:14:
Dat is dan wel heel erg slecht. Bijna zo slecht dat ze het verdienen om zo'n verliespost te krijgen.
Je vraagt je zelfs af of dit nog wel oplichting is, zo stom als dit zo geïmplementeerd is...

En als iemand de sleutels in zijn auto laat zitten is het ook geoorloofd om ermee weg te rijden...

Overigens denk ik wel dat Justeat een goede case heeft om geleden schade die ze niet kunnen verhalen, neer te leggen bij hun webdesigner. Want dom is het zeker...

[Anoniem: 200498]

Shit... echt slecht.
Een beetje website gebruikt gewoon de artikelen die besteld zijn en berekend dan achter de schermen de prijs lijkt me. Die moet niet zichtbaar zijn en encrypted over het net gaan icm een salt. (is verplicht bij ideal, anders werkt het gewoon niet)
Wat er gebeurd is, is dat de prijs voordat het naar iDeal ging eerst nog op hun eigen site werd gepost/get. Kan niet anders!

[IntToStr]

Het lijkt me duidelijk dat de totaalprijs clientside te wijzigen was omdat het in een hidden field stond. Deze waarde zal dus ook in het eigen systeem zijn opgeslagen en naar iDeal zijn gegaan. Op deze manier gaat de hash uiteraard gewoon goed en ook als er een terugkoppeling is van iDeal naar de shop komt de waarde gewoon overeen. De iDeal-koppeling kan perfect geimplementeerd zijn, maar als er zo'n grote ontwerpfout in zit (vertrouwen op clientside data) houdt het natuurlijk op...

Niet heel handig om hier gebruik van te maken als student (naam? + adres bekend...) maar de idioot die dit ontwerp heeft gemaakt kunnen ze beter gaan vervolgen ipv de studenten voor slechts 30000 euro lijkt me.

[ik222]

Hoe kun je zo dom zijn om de totaalprijs clientside te berekenen en die dan door te laten sturen als zijnde het juiste bedrag. Dat soort berekeningen horen gewoon serverside te gebeuren uiteraard.

Verder is er gebruik van maken inderdaad ook niet echt slim omdat ze alle gegevens van je hebben verder. Je zult dus uiteindelijk toch moeten betalen...

[LieveNiels]

Wat on-ge-loofelijk stom dat die luitjes dan pizza's voor 1 cent gaan kopen. Zorg dan dat je gewoon 5 euro overmaakt als je 10 pizza's wil hebben. Op die manier was dit nu nog steeds niet opgevallen in de boekhouding.

[ Voor 4% gewijzigd door LieveNiels op 16-10-2009 14:51 ]

[NMe]

LieveNiels schreef op vrijdag 16 oktober 2009 @ 14:51:
Wat on-ge-loofelijk stom dat die luitjes dan pizza's voor 1 cent gaan kopen. Zorg dan dat je gewoon 5 euro overmaakt als je 10 pizza's wil hebben. Op die manier was dit nu nog steeds niet opgevallen in de boekhouding.

Natuurlijk zou dat wel gewoon opvallen. Er wordt toch (naar ik aanneem) ook gewoon opgeslagen wát er verstuurd is? Als er 10 pizza's verstuurd worden en er maar een bedrag van 5 euro bij staat klopt er geheid ook iets niet.

[Dr. Horrible]

Het gaat erom dat een bedrag van vijf euro veel minder opvalt dan van 1 cent. Als iemand snel de papieren over kijkt en niet oplet hoeveel er precies besteld is dan kijk je er zo overheen.

[Marzman]

Arjan A schreef op vrijdag 16 oktober 2009 @ 11:30:
Lees dit artikel eens.
In het kort: Studenten van oa Nyenrode hebben een gat of een fout ontdekt in de iDeal-koppeling met de bestelsite justeat.nl. Hierdoor kunnen ze voor een cent pizza's bestellen.

In het artikel staat (in vrij algemene bewoordingen) beschreven wat ze hebben gedaan. En dat snap ik niet. Ik heb zelf ook meerdere betaalsites ontwikkeld, en vraag mij dus af of dit bij elke site had kunnen gebeuren of dat dit specifiek aan justeat ligt.

Ik ben dus eigenlijk nieuwsgierig (zonder misbruik te willen maken) naar de manier waarop dit is gebeurd. Zijn er mensen die daar meer van weten, of die dat kunnen uitleggen?

De betreffende site levert zelf niet, maar werkt samen met aangesloten bedrijven. Daarom valt het de bezorgers ook verder niet op. Bij webwinkels denk ik niet dat ze het op gaan sturen als hetzelfde truukje daar werkt omdat ze zelf de check doen tussen prijs en product.

[arnoudwokke]

Het hele verhaal over het hidden input field en hoe dat werkte staat nu ook op de fp: nieuws: Veertig bedrijven kunnen slachtoffer zijn van beveilingslek Just-Eat

Ik heb ik een reactie ook nog even gereconstrueerd hoe wij het hier op de redactie hebben gereproduceerd. Daarbij waren geen developers betrokken, met wat ruwe kennis van HTML was het al mogelijk om dit lek te vinden en te misbruiken: arnoudwokke in 'nieuws: Veertig bedrijven kunnen slachtoffer zijn van beveilingslek Just-Eat' Meer dan Kladblok en Firefox hadden we niet nodig...

[Arjan A]

arnoudwokke schreef op vrijdag 16 oktober 2009 @ 15:22:
[..]
Ik heb ik een reactie ook nog even gereconstrueerd hoe wij het hier op de redactie hebben gereproduceerd. Daarbij waren geen developers betrokken, met wat ruwe kennis van HTML was het al mogelijk om dit lek te vinden en te misbruiken: arnoudwokke in 'nieuws: Veertig bedrijven kunnen slachtoffer zijn van beveilingslek Just-Eat' Meer dan Kladblok en Firefox hadden we niet nodig...

Idd, ik had het ook al even bekeken mbv Firebug, iets wat ik standaard in Firefox heb zitten...

[André]

"Never trust user input" wordt hier weer eens flink bewezen.

[HawVer]

Als de website door een externe partij is ontwikkeld heb je wat om aan te klagen. Ik ben benieuwd wat de juridische gevolgen zullen zijn.

[BtM909]

Of het echt waar is weet ik niet, maar 't lijkt erop dat de eersten al gepakt en "gestraft" zijn:

Sharky schreef op vrijdag 16 oktober 2009 @ 15:01:
Vriend van een collega belde zojuist dat hij 6000,- euro moet terugbetalen. Hij heeft 2 weken lang voor bijna 400 euro aan pizza's voor het hele studentenhuis en de halve straat besteld. Is in Groningen btw.

[Arjan A]

BtM909 schreef op vrijdag 16 oktober 2009 @ 15:30:
Of het echt waar is weet ik niet, maar 't lijkt erop dat de eersten al gepakt en "gestraft" zijn:

[...]

De hele straat, tuurlijk. Volgens mij waren ze nog niet eens begonnen met claimen.

Overigens is het nog steeds mogelijk zag ik net: - klik -.

[Bramos]

Echt stom dat ze het niet gefixt hebben. Je knikkert je website toch meteen dicht als er lekken in zitten .

[Cartman!]

Dan nog begrijp ik t niet helemaal. Een iDeal basic koppeling maakt toch serverside een hash van een aantal variabelen (oa. de prijs). Dus als je de prijs aanpast klopt de hash toch niet meer? Of zat t zo dom in elkaar dat deze hash pas bij de externe partij werd gemaakt die werkte met de hidden input van justeat? Als developer die dit moet maken trek je dan toch al direct aan de bel als je die API docs aangeleverd krijgt

Overigens snap ik niet dat ze zeggen "enkele versies firefox". Je kunt in elke browser toch wel de pagina manipuleren met een plugin...?

[n0elite]

Ik vind het eigen schuld van de bestelsite zelf , maar wel geniaal dat ze maandenlang gratis pizza hebben gehad

[Soultaker]

@Bramos: wellicht draait de site netto nog steeds winst, omdat er maar een kleine groep mensen is die er misbruik van maakt. Dan is het niet slim om de site offline te gooien.

---

Uit het artikel:

...Het zijn waarschijnlijk de slimste jongetjes van de klas geweest die het lek in ons systeem ontdekt hebben...

Dat weet ik niet. Wat ik wél weet is dat de makers van de JustEat website zeker níet de slimste jongetjes van de klas zijn, want dan hadden ze wel bedacht dat je je totaalprijs niet door de user's browser moeten laten posten (in ieder geval niet zonder authenticatie d.m.v. een HMAC ofzo).

Beetje slap (maar wel voorspelbaar) van de eigenaar om te doen alsof ze gehackt zijn door geniën in plaats van de hand in eigen boezem te steken. Dit is ook tekenend trouwens:

...Anders dan hij eerder beweerde, ging het niet om een lek in betaaldienst iDeal, maar om een fout in de website van de bezorgdienst zelf...

Blijkbaar probeerde 'ie het eerst (niet gehinderd door enige kennis van zaken) nog op iDeal af te schuiven. Dit soort mensen mogen van mij best een ander vakgebied gaan zoeken.

[ Voor 19% gewijzigd door Soultaker op 16-10-2009 22:17 ]

[NMe]

Cartman! schreef op vrijdag 16 oktober 2009 @ 22:11:
Overigens snap ik niet dat ze zeggen "enkele versies firefox". Je kunt in elke browser toch wel de pagina manipuleren met een plugin...?

Neem jij überhaupt iets serieus dat gezegd wordt door een partij die zo'n beveiligingslek niet van mijlenver ziet?

Soultaker schreef op vrijdag 16 oktober 2009 @ 22:14:
@Bramos: wellicht draait de site netto nog steeds winst, omdat er maar een kleine groep mensen is die er misbruik van maakt. Dan is het niet slim om de site offline te gooien.

Nu half Nederland de exploit in geuren en kleuren heeft uitgelegd denk ik dat dat een slechte zet is. Zelfs hier op T.net is inmiddels precies beschreven hoe je de zaak kan flessen.

[ Voor 39% gewijzigd door NMe op 16-10-2009 22:18 ]

[Cartman!]

Daar heb je een punt

[crisp]

Cartman! schreef op vrijdag 16 oktober 2009 @ 22:11:
[...]
Overigens snap ik niet dat ze zeggen "enkele versies firefox". Je kunt in elke browser toch wel de pagina manipuleren met een plugin...?

plugin? helemaal niet nodig, gewoon vanuit je adresbalk:

code:

javascript:document.getElementById('paymentform_amount').value='5';void(null);

[.oisyn]

Wat is nou het nut van die void(null) op het eind?

[Maverick]

Ongelooflijk wat een prutsers zeg. Eerst ben je nog benieuwd naar het geflikt hebben, maar als je het dan hoort Als je als bedrijf hier last van hebt gehad, omdat just-eat je maar 1 cent betaalt voor het bezorgen van eten, dan klaag je ze toch keihard aan voor nalatigheid als je dit zo leest.

[crisp]

.oisyn schreef op zaterdag 17 oktober 2009 @ 01:13:
Wat is nou het nut van die void(null) op het eind?

Je kan de hele expressie ook wrappen in void() natuurlijk, maar belangrijk is dat de expressie zelf niets teruggeeft, anders overschrijft dat het huidige document.

[Marzman]

Zou het goedkoper als een reclamecampagne zijn ofzo, omdat ze die site gewoon zo laten doordraaien? Iedereen weet nu wel meteen wat Just Eat is.

[ZpAz]

crisp schreef op zaterdag 17 oktober 2009 @ 01:25:
[...]

Je kan de hele expressie ook wrappen in void() natuurlijk, maar belangrijk is dat de expressie zelf niets teruggeeft, anders overschrijft dat het huidige document.

Enkel

javascript:document.getElementById('paymentform_amount').value='5';

Dat in de adresbalkneerplempen veranderd toch alleen die waarde?

[Anoniem: 144479]

Gewoon een beunhaas aan het werk geweest. Er zijn honderden bedrijven in Nederland die honderdduizenden euro's verdienen met incompetente code monkeys. Geen peer reviews, geen system testing of te wel alle personen in deze keten denken er iets over te weten maar weten eigenlijk maar bar weinig.

[ Voor 8% gewijzigd door Anoniem: 144479 op 17-10-2009 10:57 ]

[Anoniem: 183983]

Hallo Arjan,

Na drie pagina's reacties heb je nog steeds je antwoord niet. Het lullige is dat het helemaal niet om ingewikkelde hashcodes gaat, maar het 'lek' bestaat er gewoon in dat een bedrag, als de klant het gaat betalen in zijn browser ALTIJD via de klant zal gaan. Dus of dat nou via een hash gaat of zonder hash, het bedrag GAAT via de klant.

Wat moet je als webwinkel doen om dit soort hacks te voorkomen? Je moet de handleiding van je betaalprovider goed doornemen. En daar staat (bij een goede betaalprovider) altijd in dat je een payment confirmation pagina moet hebben. Zodat je een bericht van je betaalprovider ontvangt als je klant daar betaalt.

Wat is een payment confirmation dan precies? Het bedrag dat de klant uiteindelijk betaald (in Ideal, of via creditcard of wat dan ook) zal via de browser van de klant bij je terug komen. Maar dit bedrag is totaal onbetrouwbaar. De hash kan gekraakt worden, of als er geen hash is, het bedrag kan domweg worden aangepast zoals bij Justeat.

Maar dit weten betaalproviders (zoals dibs en Ogone, die de betaalafhandeling voor jou als webwinkel doen via Ideal of creditcard) natuurlijk ook. Dus zij bieden iets extra's. En dat extra's moet je als webwinkel natuurlijk wel implementeren.

Het extraatje wat betaalproviders bieden is die payment confirmation. Dit is een bericht dat van de betaalprovider naar de webwinkel gaat. Let op: Dit is voor de webwinkel dus een extra bericht. Met daarin het ordernummer en het daadwerkelijk betaalde bedrag van de klant. En dat bericht kun je als webwinkel uiteraard WEL vertrouwen. Omdat je weet waar dat bericht vandaan komt (IP adres van de provider op een afgesproken url bij jouw webwinkel).

Kortom hoe gaat het in zijn werk?
Klant is A
Webwinkel is B
Betaalafhandelaar C.

A bestelt iets bij B. Bijvoorbeeld een bestelling ABCDEFG voor 10 euro.
B stuurt aan A een 're-direct' terug zodat A naar C wordt gestuurd (met het bestelnummer ABCDEFG en het bedrag).
Hier zit het probleem, A kan het bedrag van 10 euro veranderen (naar 1 cent), maar de klant kan niet het ordernummer veranderen, want dat is de pizza en het adres waar die pizza heen moet.

A betaalt 1 cent bij C. De betaalactie slaagt (uiteraard), en via A (die 1 cent weer terugwijzigt naar 10 euro) komt dan de betaalbevestiging terug (bij de webwinkel).

Als webwinkel moet je die betaalbevestiging die van A ontvangt niet vertrouwen. Sommige webwinkels doen dit wel; da's niet erg handig. In elk geval heb je als webwinkel wel een betaalregistratie, maar je weet niet zeker of daadwerkelijk zoveel betaald is als je wilt hebben. Die klant A zegt wel 10 euro in zijn betaalbevestiging, maar in werkelijkheid -kan- het 1 cent zijn.

Nu het extraatje, de payment confirmation die van C naar B gaat.

Betaalprovider C biedt een extraatje. Als de klant 1 cent betaalt, stuurt die behalve het antwoord aan A, ook zelf een (tweede) bericht uit, namelijk naar de webwinkel. Nu weet de webwinkel dus dat er voor bestelling ABCDEFG 1 cent is betaald, of 10 euro als de klant niet heeft zitten frutselen aan het bedrag natuurlijk. En pas als de webwinkel dit tweede bericht ontvangt, weet de webwinkel dat de bestelling de deur uit kan!

Duidelijkste plaatje van dit tweede bericht dat ik zo snel kon vinden:


Ik hoop hiermee wat licht over de duisternis te hebben geschenen.

Groet,

[Soultaker]

ZpAz schreef op zaterdag 17 oktober 2009 @ 10:45:
Dat in de adresbalkneerplempen veranderd toch alleen die waarde?

Tip: probeer 't eens, dan zie je of crisp die opmerking voor niets maakte.

(Wel met een pagina die echt een paymentform_amount element heeft natuurlijk, anders krijg je een error ergens halverwege de executie en gebeurt er inderdaad niets.)

[Soultaker]

Anoniem: 183983 schreef op zaterdag 17 oktober 2009 @ 17:28:
Wat moet je als webwinkel doen om dit soort hacks te voorkomen? Je moet de handleiding van je betaalprovider goed doornemen.

Inderdaad, helemaal mee eens. De bedrijven die dit soort betaalsystemen opzetten hebben (meestal) wel over dit soort attacks nagedacht, dus moet je hun instructies serieus nemen (zeker als je zelf - blijkbaar - weinig inzicht hebt in dit soort zaken.)

Maar hier ben ik het minder mee eens:

Het bedrag dat de klant uiteindelijk betaald (in Ideal, of via creditcard of wat dan ook) zal via de browser van de klant bij je terug komen. Maar dit bedrag is totaal onbetrouwbaar. De hash kan gekraakt worden, of als er geen hash is, het bedrag kan domweg worden aangepast zoals bij Justeat.

Het doel van cryptografische hash-functies is nu juist om dit soort transacties mogelijk te maken. Ik vind het vrij onzinnig om er dan vanuit te gaan dat een hash gekraakt kan worden (wat in theorie mogelijk is, maar dat geldt ook voor de techniek achter SSL bijvoorbeeld).

Het moet dus best mogelijk zijn om een systeem op te zetten waarbij alle data via de browser van de klant verstuurd wordt. Dan moet de verkoper een ondertekende bestelling meegeven aan de client, die 'm naar de betaaldienst stuurt, en die vervolgens een door de betaaldienst ondertekende betaalbevestiging terugkrijgt die de verkoper weer kan verifiëren (op basis van een public key ofzo).

[Cartman!]

hace_x, leuke uitleg maar dat is gewoon niet wat er is gebeurd bij just-eat imo. Daar ging alles via een externe partij die pas met ideal communiceerde. Het (extreeeeeem) domme bij just eat is dat zij in het formulier in een verborgen veld het bedrag hadden staan. Dat bedrag kun je makkelijk aanpassen en daarna ging het pas door de beveiligde molen heen (voor de opbouw van de controle-hash werden de gegevens gebruik uit het eerste formulier waar je zelf in kon rommelen). Dit heeft dus niks te maken met de veiligheid van ideal maar gewoon met de beroerde developers die dit geimplementeerd hebben. Ze hadden zelf ook gewoon al gebruik moeten maken van een hash in dat formulier met een geheime token die alles serverside bekend is.

bij ideal basic staat ook in de documentatie volgens mij (lang geleden dat ik t voor t laatst heb ingebouwd) dat de controle variabelen in de GET niet betrouwbaar zijn en dit altijd handmatig gecontroleerd moet worden in het ideal dashboard. Bij de ideal advanced (naam wisselt per bank geloof ik) krijg je serverside een call binnen die je wel kunt vertrouwen zodat je weet of de betaling echt geslaagd is.

[ Voor 21% gewijzigd door Cartman! op 18-10-2009 12:40 ]

[Anoniem: 183983]

Cartman! schreef op zondag 18 oktober 2009 @ 12:38:
hace_x, leuke uitleg maar dat is gewoon niet wat er is gebeurd bij just-eat imo. Daar ging alles via een externe partij die pas met ideal communiceerde. Het (extreeeeeem) domme bij just eat is dat zij in het formulier in een verborgen veld het bedrag hadden staan. Dat bedrag kun je makkelijk aanpassen en daarna ging het pas door de beveiligde molen heen (voor de opbouw van de controle-hash werden de gegevens gebruik uit het eerste formulier waar je zelf in kon rommelen).

Ik probeer juist uit te leggen dat het niets uit maakt dat dat bedrag bij just eat niet beveiligt was. Ook als het niet beveiligd is, moet je als webwinkel just eat even wachten op de betaalbevestiging die je binnen krijgt van dibs. Die communicatie via de klant moet je gewoon nooit vertrouwen; dan ben je als webwinkel pas veilig.

Dit heeft dus niks te maken met de veiligheid van ideal maar gewoon met de beroerde developers die dit geimplementeerd hebben. Ze hadden zelf ook gewoon al gebruik moeten maken van een hash in dat formulier met een geheime token die alles serverside bekend is.

Ze hadden gebruik moeten maken van de payment confirmation message die betaalproviders zoals Dibs (en ook Ogone) bieden.

bij ideal basic staat ook in de documentatie volgens mij (lang geleden dat ik t voor t laatst heb ingebouwd) dat de controle variabelen in de GET niet betrouwbaar zijn en dit altijd handmatig gecontroleerd moet worden in het ideal dashboard. Bij de ideal advanced (naam wisselt per bank geloof ik) krijg je serverside een call binnen die je wel kunt vertrouwen zodat je weet of de betaling echt geslaagd is.

Dan is mijn advies voor alle webwinkels om altijd van advanced gebruik te maken, en zou mijn advies aan betaaldiensten zijn om geen basic-pakketten meer aan te bieden. Omdat het geval van just eat maar weer eens bewijst dat je betaaldienst dan een slechte naam kan krijgen...

Cheers,

[sub0kelvin]

@hierboven.
Ook als de iDeal-koppeling perfect veilig uitgevoerd was met een payment confirmation messages e.d., dan was dit nog steeds verkeerd gegaan. Het totaalbedrag werd bepaald bij de gebruiker en daarna opgeslagen bij de food-toko. Dat bedrag werd dan doorgestuurd naar iDeal en dus ook gebruikt bij de confirmation. En DAT is de fout die gevaarlijk was. Bepalen van de prijs moet server-side gebeuren en dan naar de klant gestuurd worden en niet andersom. In de communicatie naar iDeal hoefde dus helemaal niet gerommeld te worden.

Wellicht ter verduidelijking: Je kent vast wel die PIN-systemen waar de PIN los staat van de kassa en dus handmatig het te betalen bedrag apart ingevoerd wordt in het PIN-apparaat voordat men kan gaan pinnen. Wat hier min of meer gebeurde is te vergelijken met dat de winkel de klant het bedrag liet invoeren in plaats van de caissière. Het PIN-systeem doet nog steeds braaf zijn werk, alleen is het bedrag niet wat de winkelier/caissière verwachtte.

Laatste voorbeeld: de ober maakt de rekening op maar laat het optellen van alle subbedragen over aan de klant. Die vult heel sneaky 0.01 in, because he can, en de ober leest 0.01, vraagt 0.01 aan de klant, ontvangt 0.01, en is ook nog eens zo netjes om nog een keer te checken of 0.01 inderdaad als totaal op de rekening staat.
Dat blijkt inderdaad zo te zijn, dus hij vind het prima. Dag klant, tot de volgende keer.

[Cartman!]

Anoniem: 183983 schreef op zondag 18 oktober 2009 @ 15:47:
[...]
...verhaal...

Echt heel veel helpen doet dat niet. Bij een dienst als paypal (zeg ik uit mn hoofd) kun je een dag later nog een betaling intrekken waardoor eerder een betaling op "betaald" stond nu ineens op "ingetrokken" kan staan. Zo zijn er bij meerdere diensten van uitzonderingen waar je pas later achterkomt misschien. Het hele probleem met justeat is dat zijn daar niet op kunnen wachten, zodra de betaling binnen is (of als ze denken dat dit zo is) wordt de order in werking gezet. Mocht er een uur later blijken dat er niet geincasseerd is, dan is de buit al binnen. Blijft een lastig iets.

Overigens zijn er shops die prima van basic gebruik kunnen maken, kleine shopjes die toch met de hand de betaling controleren hebben daar genoeg aan. Vergeet niet dat advanced voor een ondernemer duurder is dan basic. Diensten als ogone zijn ook niet gratis. Hoewel ik het opzich wel met je eens ben hoor

[Anoniem: 207902]

Mailtje van Just-Eat

Modbreak:

Wat voegt dit toe aan de discussie van dit onderwerp

[ Voor 94% gewijzigd door BtM909 op 18-10-2009 21:51 ]

[Anoniem: 183983]

sub0kelvin schreef op zondag 18 oktober 2009 @ 16:18:
@hierboven.
Ook als de iDeal-koppeling perfect veilig uitgevoerd was met een payment confirmation messages e.d., dan was dit nog steeds verkeerd gegaan. Het totaalbedrag werd bepaald bij de gebruiker en daarna opgeslagen bij de food-toko. Dat bedrag werd dan doorgestuurd naar iDeal en dus ook gebruikt bij de confirmation. En DAT is de fout die gevaarlijk was. Bepalen van de prijs moet server-side gebeuren en dan naar de klant gestuurd worden en niet andersom. In de communicatie naar iDeal hoefde dus helemaal niet gerommeld te worden.

Huh? Als just-eat werkelijk -zo- stom is geweest, dan helpt niets meer

Normaliter kan je de prijsbepaling best bij de klant laten doen, zolang je als webwinkel serverside ten minste -ook- een prijsbepaling hebt. Ik bedoel: als een klant 2x de pizza margerita van 10 euro aanvinkt, dan mag je best clientside berekenen dat dat 20 euro wordt. Zo lang er serverside ten minste ook maar een winkelmandje bestaat van 2 pizza's = 20 euro. Dan gaat het goed komen met die payment confirmation. Omdat je server side uiteraard het totaalbedrag van het winkelmandje bewaart. Als de klant dan terug komt met 1 cent voor die 2 pizza's weet je serverside dat er iets niet in de haak is.

Overigens werken veel websites met een bestellingsbevestiging die direct naar de klant wordt gestuurd als het betaalbericht via de klant weer terug komt. Omdat dat bericht iets sneller bij de server komt dan de payment confirmation; en natuurlijk omdat je meteen een nieuwe bevestigingspagina aan de klant wilt tonen wanneer die betaalt heeft.

Wellicht ter verduidelijking: Je kent vast wel die PIN-systemen waar de PIN los staat van de kassa en dus handmatig het te betalen bedrag apart ingevoerd wordt in het PIN-apparaat voordat men kan gaan pinnen. Wat hier min of meer gebeurde is te vergelijken met dat de winkel de klant het bedrag liet invoeren in plaats van de caissière. Het PIN-systeem doet nog steeds braaf zijn werk, alleen is het bedrag niet wat de winkelier/caissière verwachtte.

Laatste voorbeeld: de ober maakt de rekening op maar laat het optellen van alle subbedragen over aan de klant. Die vult heel sneaky 0.01 in, because he can, en de ober leest 0.01, vraagt 0.01 aan de klant, ontvangt 0.01, en is ook nog eens zo netjes om nog een keer te checken of 0.01 inderdaad als totaal op de rekening staat.
Dat blijkt inderdaad zo te zijn, dus hij vind het prima. Dag klant, tot de volgende keer.

Als dat echt zo is, dan hebben ze meer dan 1 ding over het hoofd gezien bij justeat. Ik vermoed echter dat justeat gewoon vertrouwd heeft op de betalingsbevestiging van de klant, en de payment confirmation niet heeft ingevoerd.

Voor de duidelijkhied: Ik ken zelf die pinbetalingen uit je voorbeeld niet, maar wel de online betalingsafhandeling van www.vliegwinkel.nl

Dus nog wat extra's: In het echte leven komt het voor dat je de payment confirmation van Dibs of Ogone niet krijgt, en alleen de betalingsbevestiging via de klant. Dat kan gebeuren door internetstoringen. Op dat moment kun je serverside NOG een bericht uitsturen naar Dibs/Ogone om een fraudecheck te doen. Geeft die een OK: dan wordt je vliegticket 'geprint'.

Cheers,

[cariolive23]

Anoniem: 183983 schreef op zondag 18 oktober 2009 @ 21:36:
Voor de duidelijkhied: Ik ken zelf die pinbetalingen uit je voorbeeld niet, maar wel de online betalingsafhandeling van www.vliegwinkel.nl

En dat is toch zo'n geweldige betalingsafhandeling:

Ordernummer :
VW-00xxxxx_xxxxx
Totaalbedrag :
---
Begunstigde :
Vliegwinkel BV

Deze bug heb ik afgelopen week maar eens aangemeld nadat het voor de zoveelste keer niet was gelukt om een ticket af te rekenen via iDeal.

Verder heeft Just-Eat en zijn softwareleverancier gewoon lopen blunderen en aangetoond dat ze geen enkel benul hebben van beveiliging. Het zou mij niet verbazen wanneer blijkt dat er nog veel meer lekken in de site zitten, het gebruik van hidden fields voor vertrouwelijke informatie geeft goed aan op welk niveau men zich bevindt. Zowel opdrachtnemer als opdrachtgever hebben de afgelopen 10 jaar niet zitten opletten, ze hebben geen enkele aandacht besteed aan beveiliging.

Gevalletje "eigen schuld, dikke bult".

[.oisyn]

Het is alleen dat die bult niet zo dik gaat zijn, itt bij de studenten waarop de kosten verhaald worden (en terecht overigens, een streepjescode van een blikje tomatenpuree a 15 cent plakken over die van een groot vers stuk ossenhaas valt ook gewoon onder fraude)

[Cartman!]

Dat is de eerste goede vergelijking die gemaakt is in dit topic volgens mij. Ik mag ook hopen dat alle misbruikers moeten terugbetalen maar vooral dat de developers op hun flikker hebben gekregen...

[Lulukai]

Een kick van meer dan 8 jaar, maar ik vroeg me af wat de afloop van deze zaak was?