Online vakantieboeking geeft adres en datum prijs

[perexerep]

Bij een online aanbieder van vakanties heb ik onze vakantie geboekt, na de betaling kwam ik een scherm met de bevestiging. In dit scherm stond mijn orderID. Om er zeker van te zijn dat deze pagina niet door iedereen bezoekt kan worden verlaagde ik dit orderID met 1. Wat schets mijn verbazing ik zie de boeking van 1 willekeurige vakantieganger die voor mij zijn boeking gemaakt heeft.

voorbeeld link [url="http://***.*******.com/thanks.php?paid=N&ORDERID=*************1"]http://***.*******.com/thanks.php?paid=N&ORDERID=*************1[/url]

Waarom nu mijn verontwaardiging, zowel mijn adresgegevens als de datum van de reis staan op deze pagina.

Na deze ontdekking heb ik direct contact gezocht met de reisorganisatie, ze hebben me teruggebeld en ik heb een mailtje van ze gekregen.

Nogmaals bedankt voor het onder de aandacht brengen van dit beveiligingsrisico. Zoals telefonisch afgesproken zal ik u op de hoogte houden van de acties die hierop ondernomen worden.

De programmeurs van ons webboekingsysteem zijn samen met de programmeurs van het betalingsbedrijf bezig om een meer veilige methodiek in te voeren. In de volgende versie van het betalingssysteem is dit risico opgelost maar voor de korte termijn wordt een alternatieve oplossing ingevoerd. Dit zou deze week gerealiseerd moeten zijn. Ik zal u hierover berichten.

Alleen is er afgelopen week niets gebeurd. Ik heb ook het CBP in gelicht, zij adviseren om een klachten brief te schrijven en vier weken te wachten. Persoonlijk vind ik dit te lang.

Kan dit zomaar en wat kan ik er nog meer aan doen om dit te bespoedigen?

[Megamind]

Het bedrijf links laten liggen en je verhaal posten

Je kan een bedrijf niet forceren hun beveiligingslekken te dichten, dat is hun eigen probleem. Het enige wat je kan doen is ze er nogmaals op wijzen, en zeggen als het niet opgelost is je niet meer bij hun wilt boeken.

[Verwijderd]

Je kunt de pers zoeken: Geenstijl / De Telegraaf / Radar vind ik dit soort items wil interessant. Als het publiekelijk komt weet je zeker dat ze de druk voelen het te repareren, én publiekelijk aan al hun klanten excuses aan te bieden. Want dit lek van de website is natuurlijk erg handig voor inbrekers etc, dus zeker niet netjes als ze niet aan alle klanten excuses aanbieden + melding op de website.

[ Voor 61% gewijzigd door Verwijderd op 22-06-2009 12:15 ]

[beany]

Alle order ID's aflopen en de adressen die je daaruit haalt een briefje sturen dat hun gegevens op en bloot op die website staan. Hopen dat velen van hun ook gaan klagen, en dan komt er vanzelf wat meer druk achter

Nah, verder denk ik gewoon stil houden. Wat niet weet, wat niet deert. Als je dit aan de grote klok hangt krijg je juist waar je bang voor bent: je gegevens liggen op en bloot op straat.

[WoBaDijk]

Ik denk dat je wel degelijk wat kan doen. Zij maken hun probleem jou probleem en door hun fout kunnen er voor jou extra risico's zijn op inbraak, etc. Ik denk dat je het nog één keer netjes moet vragen en daarna met stappen moet gaan dreigen. Ik denk dat je ze als het moet tot stappen moet kunnen dwingen.

Het licht er dan natuurlijk aan hoever je ermee wil gaan, maar je moet best wat kunnen bereiken. Meestal is dreigen met radar al genoeg (heel kinderachtig maar het werkt).

Ik vraag me btw af of die site door een stel 12 jarige is gebouwd. Door de gegevens gewoon in de url te zetten kan iedereen erbij

[Orion84]

Ik heb niet enorm veel verstand van web-development laat staan van het specifieke product, maar ik kan me best voorstellen dat zoiets niet ff in een weekje gefixt, getest en uitgerold kan worden.

Ze een officiële klachtenbrief sturen (CBP heeft daar wel mooie templates voor denk ik) kan niet echt kwaad natuurlijk. Ze hebben echter duidelijk (per telefoon en e-mail) laten weten de klacht serieus te nemen, bezig te zijn met een oplossing en jou op de hoogte te zullen houden. Dus ik zou zeggen, geef ze even de tijd om die aanpassing door te voeren. Nu nog eens even zo'n brief sturen, terwijl ze je opmerking al serieus nemen en er mee bezig zijn komt in mijn ogen nogal zeurderig over en zal je niet echt geliefd maken bij die toko.

Wat betreft je vraag "kan dit zomaar", als het CBP aangeeft dat de procedure standaard 4 weken de tijd geeft om het op te lossen, dan denk ik dat dat wel klopt, aangezien het CBP toch de geldende autoriteit is in deze.

Verder wel een interessante kwestie in het licht van het recente nieuwsbericht dat inbrekers steeds vaker gebruik maken van mededelingen op social network sites, twitter en andere digitale media waaruit op te maken valt dat iemand op vakantie is.

[ Voor 11% gewijzigd door Orion84 op 22-06-2009 12:27 ]

[Verwijderd]

Heb je inmiddels al voor een tweede keer contact met ze opgenomen? Ik zou je niet direct aanraden om naar de pers te gaan. Dat zou ik pas doen als je er geen vertrouwen meer in hebt dat een oplossing voorhanden is. Daarnaast vind ik dat je ook rekening moet houden met de imagoschade die je het bedrijf toebrengt. Zij zitten in het hoogseizoen en hebben geen zin in negatieve publiciteit. Dit kun je natuurlijk wel gebruiken in je communicatie. Ik zou eens contact opnemen en met een leidinggevende proberen te spreken. Maak met hem een tweede afspraak wanneer het probleem opgelost moet zijn en geef aan dat ze na die datum tweemaal in staat zijn geweest om het probleem te verhelpen. Laat dat nog even bevestigen per e-mail. Na die tweede datum kun je wat mij betreft prima naar de pers.

[arnoudwokke]

Pers zoeken is niet nodig, je zit op een site die ict-nieuws brengt

[perexerep]

Ik heb niet enorm veel verstand van web-development laat staan van het specifieke product, maar ik kan me best voorstellen dat zoiets niet ff in een weekje gefixt, getest en uitgerold kan worden.

Maar wat is dan wel een redelijke termijn? Het zijn mijn gegevens die daar staan.

Alle order ID's aflopen en de adressen die je daaruit haalt een briefje sturen dat hun gegevens op en bloot op die website staan. Hopen dat velen van hun ook gaan klagen, en dan komt er vanzelf wat meer druk achter

Ik vind eigenlijk dat de reisorganisatie dit moet doen.

Pers zoeken is niet nodig, je zit op een site die ict-nieuws brengt

Houden we even achter de hand

[Dimitri R]

Neem even contact met ons - redactie Tweakers.net : [e-mail] of 033- 464 14 44- op perexerep, we kunnen een objectief verhaal schrijven als hier daadwerkelijk nieuws in zit en het probleem voorleggen aan de eigenaren vd site. Je zult zien dat het lek dan snel gedicht is

[Orion84]

perexerep schreef op maandag 22 juni 2009 @ 13:43:
[...]


Maar wat is dan wel een redelijke termijn? Het zijn mijn gegevens die daar staan.

Tsja, CBP zegt 4 weken, daar zullen ze vast wel min of meer over nagedacht hebben. Al is dat natuurlijk wel erg veel, dat ben ik met je eens

Ik weet ook niet precies wat jij bedoelde met "er is afgelopen week niks gebeurd". Wanneer heb je ze precies op de hoogte gebracht, wanneer hebben ze gereageerd? Kortom hoeveel werkdagen hebben ze nu helemaal de tijd gehad om dit te communiceren naar de betreffende ontwikkelaar en hoeveel tijd heeft die al gehad om er iets aan te doen? Een week zijn maar vijf dagen en als er ergens een of twee dagen verloren gaan door niet al te vlotte communicatie blijft er weinig tijd over.

Maar opzich vind ik het voorstel van mig29 wel een goeie

[croxz]

Orion84 schreef op maandag 22 juni 2009 @ 14:15:
[...]

Tsja, CBP zegt 4 weken, daar zullen ze vast wel min of meer over nagedacht hebben. Al is dat natuurlijk wel erg veel, dat ben ik met je eens
[...]

Maar zou dat niet de termijn zijn die staat voor het lekken van 'gewone' persoonlijke gegevens als naam en adres? Ik vind het lekken van vakantietijden samen met adresgegevens toch behoorlijk risicovol. Aangifte bij de politie zou misschien niet eens misstaan.

[croxz]

Megamind schreef op maandag 22 juni 2009 @ 12:13:
Het bedrijf links laten liggen en je verhaal posten

Je kan een bedrijf niet forceren hun beveiligingslekken te dichten, dat is hun eigen probleem. Het enige wat je kan doen is ze er nogmaals op wijzen, en zeggen als het niet opgelost is je niet meer bij hun wilt boeken.

Pardon? Ze lekken wanneer huizen leeg staan!! Voor mij reden genoeg om de website plat te leggen tot het probleem verholpen is.

[NeoMe]

Frontpage nieuws;

nieuws: Beveiligingslek in site Stayokay ontdekt

[perexerep]

Gelukkig is dit opgelost.
Misschien had ik wat langer moeten wachten met mijn vraag maar hoe lang wacht je dan?
Het is opgelost met een algemene melding:

Bedankt voor uw boeking.
Uw transactie is verwerkt; u ontvangt z.s.m. een ontvangstbevestiging per e-mail.

[ Voor 0% gewijzigd door perexerep op 22-06-2009 16:40 . Reden: zie dat het de frontpage gehaald heeft. ]

[Orion84]

Perexerep overwoog ook om een klacht in te dienen bij het College Bescherming Persoonsgegevens, maar de behandeling van een eventuele klachtenbrief zou mogelijk vier weken gaan duren en daar wilde hij niet op wachten.

Volgens mij heeft perexerep het in startpost over het verzenden van een klachtenbrief naar stayokay en ze 4 weken de tijd te geven om actie te ondernemen, niet over een brief naar het CBP of heb ik de volgende opmerking verkeerd geïnterpreteerd?

...zij adviseren om een klachten brief te schrijven en vier weken te wachten

En waar komt die opmerking over die workaround ineens vandaan?

...in de tussentijd zou binnen een week een workaround moeten zijn gevonden.

[himlims_]

hahaha grappig, die hard hackers hier op t.net
goesojij

[FreqAmsterdam]

himlims_ schreef op maandag 22 juni 2009 @ 16:39:
hahaha grappig, die hard hackers hier op t.net
goesojij

juist...

[Verwijderd]

Ik ben helemaal zoek in dit topic. Is die leak nu opgelost of niet?

[Rockvee2]

Leak is opgelost volgens mij

[Deem]

De site doet het niet meer Ook een oplossing

[Exorcist]

Dimitri R schreef op maandag 22 juni 2009 @ 14:08:
Neem even contact met ons - redactie Tweakers.net : [e-mail] of 033- 464 14 44- op perexerep, we kunnen een objectief verhaal schrijven als hier daadwerkelijk nieuws in zit en het probleem voorleggen aan de eigenaren vd site. Je zult zien dat het lek dan snel gedicht is

En inderdaad, dát ging snel!

[DaMayan]

Nu nog paid op paid=Y zetten en je hebt waarschijnlijk betaald volgens hun boekingssysteem. Prachtig.

[geerttttt]

Tja, hoe moeilijk kan het zijn. Ik zou voor nu gewoon een extra key meegeven aan elke boeking. dan krijg je zo'n link:
http://***.*******.com/thanks.php?paid=N&ORDERID=*************1&UID=F9932J0F2J039FJ290JF2!FA

Wil je dan iemand anders zijn orderid bekijken, moet je wel zijn unieke id weten. Over het algemeen in een paar minuten te realiseren (afhankelijk van de omslachtigheid van de developers )

Ze zouden ook evt een ip lock of gewoon altijd geen orderid maar een lange code als orderid doen.

Eigenlijk ook erg vreemd dat een redelijk groot iets als stayokay dit zelf niet beseft wanneer ze zo'n systeem bouwen.

[418O2]

geerttttt schreef op maandag 22 juni 2009 @ 18:24:
Tja, hoe moeilijk kan het zijn. Ik zou voor nu gewoon een extra key meegeven aan elke boeking. dan krijg je zo'n link:
http://***.*******.com/thanks.php?paid=N&ORDERID=*************1&UID=F9932J0F2J039FJ290JF2!FA

Wil je dan iemand anders zijn orderid bekijken, moet je wel zijn unieke id weten. Over het algemeen in een paar minuten te realiseren (afhankelijk van de omslachtigheid van de developers )

Ze zouden ook evt een ip lock of gewoon altijd geen orderid maar een lange code als orderid doen.

Eigenlijk ook erg vreemd dat een redelijk groot iets als stayokay dit zelf niet beseft wanneer ze zo'n systeem bouwen.

om niet al te technisch te worden, maar ik denk dat er een account aan de boeking is gekoppeld. Het is niet meer dan normaal om dat af te vangen, dat is wel heel basic.

Dit is ook geen beveiligingslek te noemen, dit is gewoon luiheid van de programmeurs

www.mangrove.nl

dat is dus de ontwikkelaar. Komt verder wel aardig profi over (stylingsgewijs gezien)

[ Voor 5% gewijzigd door 418O2 op 22-06-2009 18:56 ]

[Verwijderd]

Het klopt dat zich in onze website een lek bevond. Wij betreuren dit zeer en bieden hiervoor onze excuses aan.

Stayokay wil echter ten stelligste benadrukken dat haar internetbureau Mangrove niet betrokken is bij dat deel van ons boekingsproces waarin het lek zich heeft voorgedaan. Het bedrijf treft derhalve geen enkele blaam.

[r0b]

Duidelijke reactie Stayokay. Netjes dat het toch serieus opgepakt is dat zie je nog wel eens anders helaas..
Gaan jullie ook nog de access logs van de afgelopen tijd na om na te kijken of hier eerder misbruik is van gemaakt?

(1 uniek IP per hit voor thanks.php?paid=N&ORDERID=XXXXX, anders > mogelijk foute boel?)

[ Voor 7% gewijzigd door r0b op 22-06-2009 20:31 ]

[DaMayan]

geerttttt schreef op maandag 22 juni 2009 @ 18:24:
Tja, hoe moeilijk kan het zijn. Ik zou voor nu gewoon een extra key meegeven aan elke boeking. dan krijg je zo'n link:
http://***.*******.com/thanks.php?paid=N&ORDERID=*************1&UID=F9932J0F2J039FJ290JF2!FA

Het lijkt mij dat die url just van een ander betalingssysteem afkomt en daarom niet 1-2-3 gewijzigd kon worden. Gezien ook dat een update van betalingsprovider het zal oplossen.
Anders hadden ze er in ieder geval wel even een post van gemaakt (lijkt me).

[BinaryRun]

Wel erg eigenlijk dat zulke lekken zolang bestaan zonder gerepareerd te worden. Maar gelukkig hebben ze deze uiteindelijk dan wel gerepareerd.

[pim]

Dus ze hebben het uiteindelijk toch in een weekje opgelost? Grote bedrijven hebben soms voor een tekstwijziging al 1 maand nodig, omdat het langs 5 personen moet gaan.
Nog ff getest bij http://www.hostelberlijn.nl/ maar werkte niet

[ Voor 16% gewijzigd door pim op 29-06-2009 14:20 ]

[burrug]

Orion84 schreef op maandag 22 juni 2009 @ 12:24:
Ik heb niet enorm veel verstand van web-development laat staan van het specifieke product, maar ik kan me best voorstellen dat zoiets niet ff in een weekje gefixt, getest en uitgerold kan worden.

Ik dan weer wel, en ik kan je vertellen dat het gewoon een controlefout is. De User-id (UID=..) dient gekoppeld te zijn aan een toegewezen order-id.
Ik zou zeggen een if-lusje koppelen aan het sessie-id of de gebruikerid controleren aan de hand van een aanpassing in de query en het is gefixxed. Hierna komt dan indien nodig bij hoge impact wat nazorg kijken.

[ Voor 11% gewijzigd door burrug op 23-06-2009 00:17 ]

[Orion84]

burrug schreef op dinsdag 23 juni 2009 @ 00:15:
[...]


Ik dan weer wel, en ik kan je vertellen dat het gewoon een controlefout is. De User-id (UID=..) dient gekoppeld te zijn aan een toegewezen order-id.
Ik zou zeggen een if-lusje koppelen aan het sessie-id of de gebruikerid controleren aan de hand van een aanpassing in de query en het is gefixxed. Hierna komt dan indien nodig bij hoge impact wat nazorg kijken.

Dat het in feite een triviale check zou moeten zijn wil nog niet zeggen dat het in het huidige product ook triviaal op te lossen was

In grote software producten kan je niet zomaar ff ergens een if-statement tussenknallen en weer online gooien.

Maargoed, de huidige workaround waar ze die pagina gewoon (tot ie gefixt is) niet meer gebruiken en in plaats daarvan een mailtje sturen met de bevestiging had wellicht wel wat vlotter klaar kunnen zijn.

[418O2]

pim schreef op maandag 22 juni 2009 @ 20:07:
Dus ze hebben het uiteindelijk toch in een weekje opgelost? Grote bedrijven hebben soms voor een tekstwijziging al 1 maand nodig, omdat het langs 5 personen moet gaan.

ja, maar een 'foutje' van de buitencategori moet gewoon snel verholpen worden en dat moet dan ook wel kunnen.

[-d-]

pim schreef op maandag 22 juni 2009 @ 20:07:
Dus ze hebben het uiteindelijk toch in een weekje opgelost? Grote bedrijven hebben soms voor een tekstwijziging al 1 maand nodig, omdat het langs 5 personen moet gaan.

Totdat het in de pers komt, dan kan het wel snel