Beveiligingslek in site Stayokay ontdekt - update

De website van Stayokay, een bedrijf dat kamers in hostels verhuurt, zou te kampen hebben met een ernstig beveiligingslek door een kleine aanpassing in de url. Inmiddels zou het lek zijn verholpen, zo laat het bedrijf aan Tweakers.net weten.

Het lek in het boekingssysteem van Stayokay.com werd blootgelegd door tweaker Perexerep, zo is te lezen in een posting op het GoT-forum. Door in de url het orderid-nummer te verlagen, zouden de adresgegevens en de boekingsperiode van andere gebruikers tevoorschijn getoverd kunnen worden. Dit is niet alleen in strijd met de wet op de privacy, maar dergelijke gegevens kunnen ook misbruikt worden door bijvoorbeeld inbrekers.

Perexerep heeft naar eigen zeggen contact gehad met de hostelorganisatie. Stayokay erkende dat er een probleem was en liet per mail weten dat 'de programmeurs van ons webboekingsysteem samen met de programmeurs van het betalingsbedrijf bezig zijn om een veiliger methodiek in te voeren'. In de tussentijd zou binnen een week een workaround moeten zijn gevonden. Deze is echter tot op heden nog niet doorgevoerd, zo laat Perexerep aan Tweakers.net weten. 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. Wel heeft hij van Stayokay de garantie gekregen dat in ieder geval zijn eerdere boeking uit het systeem is verwijderd.

Update 22/6 16:56: Stayokay laat aan Tweakers.net weten dat het lek is verholpen.

Reacties (63)

[Miyamoto]

De website van Stayokay is gemaakt door Mangrove, met een dergelijke klantenkring mogen we hopen dat andere projecten van ze beter in elkaar zitten!

Zonder enige controle alle gegevens behorend bij een willekeurig id weergeven is wel een hele slechte zaak. Overigens is de fout inmiddels hersteld. (Of in ieder geval: De gegevens zijn niet meer op te vragen)

edit:
Hieronder laat Stayokay weten dat de fout niet bij Mangrove lag, ik heb de links dus verwijderd.

[Reactie gewijzigd door Miyamoto op 24 juli 2024 00:18]

[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.

[Soldaatje]

Kunt u ook aangeven hoelang dit lek open geweest is?

[sys64738]

Dus jullie hebben een professioneel bedrijf dat jullie website maakt, maar als dan het meest cruciale deel van de applicatie gebouwd moet worden, laten jullie het iemand anders ineens doen? Toevallig een stagiair die ook wel eens 10 minuten rond heeft gehangen op www.php.net ? Zo komt het namelijk wel over maar het lijkt me dus stug.

Daarnaast zou ik als bedrijf als mijn naam onder zo'n site staat, en er ook andere partijen ontwikkelen aan mijn app, toch goed in de gaten houden wat die developers aan het doen zijn. En dan zou ik toch even aan de alarmbel gaan hangen als ik dit soort dingen zou zien.

[Verwijderd]

als er van dit soort fouten vaker word gemaakt in die klantenkring, hebben ze denk ik nog wel een aardig probleem,

ik zie er veel bekende en grote namen tussen zitten

[Deem]

Zozo, ze hebben niet de minste namen in hun klantenbestand. Als dat net zo knullig in elkaar steekt als deze site dan vrees ik dat ze veel van die klanten snel zullen verliezen.

Kan iemand bevestigen of het lek inmiddels opgelost is?

Edit: Laatmaar, ze hebben nu de stekker eruit getrokken

[Reactie gewijzigd door Deem op 24 juli 2024 00:18]

[Verwijderd]

dus Meneer Balkenende gaat lekker een weekje op Texel zitten?

[piccollo1985]

Now dit is een van de stomse fouten die een programmeur kan maaken.

En een tip voor de programmeurs van Stayokay:
gebruik sessions in plaats id string in te adress balk.

[cariolive23]

Now dit is een van de stomse fouten die een programmeur kan maaken.

En wat dacht je van zijn werkgever? Of zelfs de opdrachtgever? Niemand die ook maar enige poging doet om de medewerkers (programmeurs, testers, etc.) maar een heel klein beetje gevoel voor veiligheid mee te geven en hierop te gaan testen.

Veiligheid wordt door minstens 99,99% van de opdrachtgevers en opdrachtnemers gezien als iets dat lastig, kostbaar en vooral overbodig is. Het speelt pas een rol wanneer het te laat is...

Het feit dat ze in een paar uur het genoemde lek hebben kunnen dichten, wil overigens niet zeggen dat het systeem nu wel veilig is. Wanneer de code in onderdeel A zo lek als een mandje is, mag je gerust aannemen dat het met de rest van de code niet veel beter is. En dat geldt ook voor alle andere producten van deze leverancier, ga dat maar eens heel goed doorspitten, te beginnen met de testrapporten. Daarin staat precies beschreven welke zaken zijn getest, dus ook wat er is getest met betrekking tot de beveiliging.

[J.J.J. Bokma]

Dat maakt niks uit (nee, echt niet) als je de session ids slecht kiest (je kan dan nl.
een cookie maken met gegokte sessie IDs wat niet moeilijker is dan een ID in een URL plakken) en ze niet snel genoeg laat verlopen.

[Reactie gewijzigd door J.J.J. Bokma op 24 juli 2024 00:18]

[piccollo1985]

Now mijn idee is:
pagina A:
<php_code>
start_session();
...
$session['id'] = $id;
</php_code>
en dan op pagina B:
<php_code>
start_sesion();
$id = $sesion['id']
$sesion['id'] = null;
</php_code>

Deze code werk alleen als je van pagina a naar pagina b gaan.

En dit is ook me idee waar de bug zit.

[Reactie gewijzigd door piccollo1985 op 24 juli 2024 00:18]

[sys64738]

Ten eerste hoef je helemaal geen sessie-id te kiezen, dat kan PHP heel goed voor je doen. En heb je voor de grap wel eens gekeken hoe lang die session id's zijn?!? De kans dat je toevallig eens session-id gokt van iemand die op dat moment is ingelogd is zo klein dat het echt niet de moeite loont dat te proberen. Je kunt beter paar Staatsloten kopen als je er rijk mee wilt worden.

Een oplopend id daarentegen begint bij 1 (of een ander klein getal... bv als id altjijd 7 cijfers moet zijn bij 1000000) en die zijn makkelijk te gokken. Zeker als ze oplopend zijn

Dus gewoon id's van de boekingen lekker server-side in de session bewaren en dan vanaf de clientsite verwijzen naar de index van deze boekingen. En dan mag jij van mij session-id's komen gokken zo lang je wilt.

[Reactie gewijzigd door sys64738 op 24 juli 2024 00:18]

[Verwijderd]

sessions verlopen
als je het op een relatief eenvoudige manier wilt beveiligen:

$id=12345;
$key=$id;
for($i=0;$i<10000;$i++) $key=md5('secretkey'.$key); //bruteforce vertragen
$url=".....?id=$id-$key";

voldoende lange secretkey uitkiezen.
vervolgens de id reqvar splitten in $id en $key, $key check en gaan met die banaan

[ultimasnake]

Je weet hopelijk wel dat het idee van md5 juist is dat ongeacht hoevaag je 'secretkey'.$key ook "md5'et" het altijd dezelfde uitkomst zal hebben he. Het enige dat jouw code doet is een server optimaal overbelast maken....


md5('secretkey'.rand(0,10000).$key); alvast een minder ernstige oplossing
of
md5('se.$firstname.'cr'.$surname.'et'.$id); ofzo

($key = $id is trouwens ook wat nutteloos )

[Verwijderd]

Niet helemaal waar...

Eigenlijk helemaal niet waar. Want er wordt 10.000x $key geset door een hash, en deze wordt dan de volgende iteratie weer gebruikt in de hash.

Maarja, het hele voorbeeld is "wat nutteloos".

[J.J.J. Bokma]

Beter: gebruik een library inplaats van zelf het wiel uitvinden. Bovenstaande code is ronduit knullig, in het bijzonder de lus van 10 000.

[Verwijderd]

Zeg a.u.b. dat die reactie niet serieus is...

De manier die je suggereert is bagger! Ipv "bruteforce vertragen" kan je er beter "script vertragen" van maken, 10.000x een md5 hash maken om een "uid" (unique id) te maken...

Als je dan een uid wilt, doe het dan goed:
http://nl2.php.net/manual/en/function.uniqid.php

Maar ook dat is hier niet van toepassing. De gegevens die hij uit de database haalt zit ongetwijfeld een ID bij van de user, deze controleren adhv de gegevens in de sessie en klaar ben je!

[Svennetjee]

Wat een makkelijke exploit is dit zeg.. Je cross-checkt dat ID toch met het ID van de ingelogd user?

Basiscursus PHP hoofdstuk 1...

[graceful]

Het zit 'm meer in de luiheid van de gemiddelde PHP scripter dan wat anders. Dit soort dingen kom je namelijk redelijk vaak tegen tegenwoordig en dan gaan ze je ook nog eens vertellen dat het wel 'even' duren kan om het op te lossen. Probeer dan nog maar eens je lach in te houden.

[SuperDre]

Tja, of het luiheid is is natuurlijk niet goed te zeggen, het kan ook gewoon onwetendheid zijn.. Niet iedereen is zo bedacht op beveiliging van een website, en wat voor jou zo vanzelfsprekend is, hoeft voor een ander helemaal niet zo te zijn..
want ook die crosscheck van ID met ingelogde user is niet 100% safe...

[sys64738]

Als je dit soort dingen niet weet, hoor je geen web applicaties te maken. Maar ja, je ziet het wel vaker dat de verkeerde mensen op de verkeerde plek zo behoorlijke schade berokkenen.

Crosscheck van een id met het id van de ingelogde user lijkt me behoorlijk safe hoor. Nee, niets is 100% safe maar als je je inlog gegevens niet weggeeft, is dit toch echt behoorlijk waterdicht.

Daarnaast is het sowieso stom om dit soort dingen als parameter door te passen. Je kunt toch gewoon de id('s) van de reis of reizen van de ingelogde persoon in de session opslaan en daaraan refereren. Dan kom je zelfs met gokken nergens (hetgeen met hashes theoretisch nog zou kunnen).

[guitarzphreak]

...
want ook die crosscheck van ID met ingelogde user is niet 100% safe...

Nee, maar als je kijkt naar de moeite die het kost om van 1% naar 90% veiligheid te gaan... luiheid. En ja het is luiheid, want imho als je professioneel programmeert moet je ook de veiligheid waarborgen, er niks vanaf weten is geen excuus, je moet gewoon voor jezelf zorgen dat je op dat vlak bij bent.

[AtlonXP1800]

Klopt, er zijn inderdaad te veel mensen die maar wat aanprutsen. Dit is zo simpel te voorkomen, neem op zijn minst een hash in plaats van een id.

[ZpAz]

Imho gewoon controleren of de ID in de url overeenkomt met de ID van de ingelogde gebruiker, of op zijn minst de relatie in de database te koppelen is aan die gebruiker (dus dat bestelling X dezelfde userId heeft als de ingelogde gebruiker).

Daar komt helemaal geen hash aan te pas.

[apokalypse]

Niet als flame naar PHP (al hoewel in geen fan ben van scripttalen), maar dit is eenmaal het nadeel van deze simpel te leren talen. Ze trekken mensen aan die minder kennis hebben en het toch werkend krijgen.

Anyway, kan ook luiheid van de opdrachtgever zijn die totaal geen aandacht/geld voor security heeft.

[dasiro]

dan is het al wel ff geleden dat jij je cursus php bij de hand hebt genomen

[Svennetjee]

Dat regeltje diende ter illustratie..

[BlackHawkDesign]

Te kansloos voor woorden dit. Het was dan niet h1 dat ik hier zelf bij stil stond, maar meer dan 3 weken php ervaring als 15 jarig jochie had ik niet nodig om stil te staan bij het feit dat iedereen zo van elkaar dingen kon inzien

[Torrentus]

Goed dat dit gepubliceerd wordt,
De druk zal nu wel opgevoerd worden daar, vooral omdat het nu uitgebreid met naam van de betreffende organisatie gepubliceerd staat. Ik zie het trouwens ook zo morgen in de telegraaf staan..

Goed gezien van je, Perexerep!

[Verwijderd]

nah ik weet niet of dat zon goed idee is om te publiceren
nu weten juist de inbrekers dat er een lek is?(degene die internet aftrollen)

imo had dit gewoon in stilte afgehandeld moeten worden

[MsG]

Met het nadeel dat bedrijven er laks mee omgaan en het niet snel dichten. Dit is in het verleden al regelmatig gebleken. En moet je nu eens kijken, dezelfde dag nog gemaakt, blijkbaar kan het dus wel .

[Verwijderd]

Handig om de URL op het forum wel te 'beschermen' maar vervolgens hier te berichten dat het om stayokay.com gaat! Inmiddels is er vast al een persoon bezig de volledige boekingsdatabase van hen te rippen!

[Exorcist]

Lullig, maar des te sneller doen ze er iets aan. In de post op GoT stond al dat er laks gereageerd werd. Tenminste, dat kon je eruit opmaken imho.

[Verwijderd]

Tja... je weet zelf hoe dit soort dingen gaat. Baas Stayokay belt boos met baas webbouwer. Baas webbouwer gaat boos naar z'n dev'ers toe... kortom denk dat dit redelijk snel opgepakt gaat worden, dat ze laks reageren zal meer te maken hebben met het feit dat ze niet graag met de spreekwoordelijke billetjes bloot gaan!

[Deem]

Nu kan het schijnbaar wel binnen enkele minuten opgelost worden Slordig hoor! Het moet eerst groot nieuws worden voordat men pas echt ingrijpt. Het is nu al te laat.

[Saturnus]

Nou dat is natuurlijk niet zeker. Het kan zijn dat ze een oplossing klaar hadden liggen (wat dus wel tijd heeft gekost) maar nog niet online hadden gezet. Als je dan in het nieuws komt moet je haast wel, zelfs als de code nog niet 100% getest is.

[leuk_he]

De oplossing is dus dat de gegevens niet meer online te zien zijn. Je krijgt gewoon een papieren brief ter bevestiging. Slopen is idd in minuten te implementeren.

Overigens zijn er dus nauwelijk gevolgen voor bedrijven die dit dus lekken, zelfs niet nadat ze geïnformeerd zijn. Consumenten zullen niet zo gauw natrekken of een bedrijf jouw persooninformatie vertrouwelijk behandeld.

Een bedrijf dat persoonsgegevens verwerkt heeft dus geen enkele motivatie om dit proces extra te monitoren. Grote bedrijven met veel reputatie willen niet dat dit op straat komt, maar bedrijven die vooral voor de winst gaan (....wie niet...) zullen hier vaak slordig mee omgaan. Hoewel het reputatie risico groot is is er geen economisch risico.

[NeoMe]

Inbrekers zitten tegenwoordig niet meer in de brievenbus te kijken of er nog post ligt maar zitten op hyves/twitter en andere soortgelijke pagina's te kijken wanneer mensen posten dat ze op vakantie gaan. Meestal staat er ook wel bij wanneer en voor hoelang, ideale informatie. Als het huis dan beetje inbraakgevoelig is en de omgeving het toelaat slaan ze simpelweg hun slag. Dit soort informatie maakt het nog makkelijker, en is betrouwbaarder dan die andere sites.

[Qwerty-273]

Of men maakt gebruik van de "Out of Office" berichten die veel mensen instellen op hun werk wanneer ze afwezig zijn. En als je daar vermeld dat je pas op dag x terug bent van vakantie heeft men weer een mogelijk doel te pakken. Let wel dit zijn dan vaak zeer gerichte inbraken.

[Bender]

Het CBP doet helemaal niks helaas, ze hebben hier ook geen bevoegdheden toe.
Maar ze geven ook aan dat indien het technisch niet mogelijk is het ook geen verplichting is, en die technische verplichting gaat net zo ver als hun technische kennis en dat is niet zo ver helaas.

[Arnoud Engelfriet]

CBP niet, maar mensen wiens privacy geschonden is kunnen een claim indienen. En dit lijkt me technisch zo triviaal om te fixen dat zelfs een rechter wel snapt dat dit dom is. Het zou wel tijd worden dat het CBP wat extra mankracht en bevoegdheden krijgt.

[Bilel]

Een week is wel heel lang. Ik (en elke andere programmeur) had zelf heel makkelijk een kleine bot kunnen schrijven die wilekeurig id's opriep en de data van de personenen eruit nam, waarna ik het verkocht aan de eerste de beste adres-databank.

[mjtdevries]

Wat een onzin zeg. Een week is helemaal niet lang.

Waarschijnlijk is het door een externe programmeur gedaan. Daar moeten ze dus eerst een afspraak mee maken.
Die heeft ook gewoon andere werkzaamheden, en moet hun er tussendoor zien te boeken.
Dan moet ie nog de boel gaan fixen.

Een week is dan heel kort!

[Verwijderd]

Leuk gevonden, maar de claim tegen het bedrijf zelf is wat over-the-top.

Je kan ook bij een beveiligingsfirma dagelijks gaan checken, uiteindelijk zal wel eens iemand een deur open laten en je hebt je practical joke. Voordat je moet gaan brommen want gelijk of niet, je bevindt je dan wel op verboden terrein. Of de deur nu openstaat of niet maakt geen verschil. Dus door met de URL te gaan knoeien gebruikt ie de site op een abnormale manier waardoor hij wel zelf het recht van hun privacy overtreedt.

Ook door het publiek gaan debatteren terwijl de firma gemeld heeft dat ze naar een oplossing zoeken verliest hij het respect van een dergelijk lek te vinden imo.

[bwerg]

"met de URL knoeien" ? Als je zomaar een adres intypt hoor je toch niet bij privegegevens te komen. Als ik een adres intyp en ik kom toevallig privegegevens tegen dan vind je dat ik "iemands privacy overtreedt"?

Achter URL's staan vaak getalletjes, paginanummers ofzo. Vaak gebruik ik die, als ik even niet kan vinden waar ik op de normale manier een pagina verder kan komen. Ik vind het wel erg ver gaan om dat "met een URL knoeien" te noemen.

Niet dat ik het met je oneens ben dat het wat ver gaat om hier groot nieuws van te maken trouwens, maar er is toch echt een grote fout gemaakt. Of de deur open staat maakt natuurlijk wel een verschil als je vertrouwelijke informatie van anderen in de open deur legt.

[Reactie gewijzigd door bwerg op 24 juli 2024 00:18]