Klantgegevens van boodschappensite Butlon waren in te zien door url te wijzigen

De bestelsite Butlon bevatte een lek waardoor eerdere bestellingen van klanten konden worden opgezocht door de url te veranderen. Daarbij was ook het adres te zien. Na een tip van Tweakers heeft Butlon het lek gerepareerd.

Butlon is een besteldienst uit Enschede waar klanten bij restaurants uit hun omgeving kunnen bestellen, maar ook bij Butlons eigen supermarktdienst. Tweakers kreeg een tip via Publeaks over een datalek in de dienst. Daarbij bleek het mogelijk de bestelinformatie van klanten die bij het supermarktgedeelte eten kochten in te zien. Daarbij hoefde alleen de url te worden aangepast. Die eindigde na een succesvolle bestelling met een uniek cijfer dat opliep. Door het cijfer te veranderen kon een andere order worden bekeken. Daarin stond het eten dat was besteld en het totaalbedrag, maar ook het adres van de klant.

Butlon datalek

Butlon reageert tegen Tweakers dat het het lek direct heeft opgelost. "We hebben extra beveiligingsmaatregelen genomen om onze data beter te beschermen", schrijft het bedrijf. "Een voorbeeld hiervan is dat we nu url's van bestellingen randomizen en het is verplicht om in te loggen om oude bestellingen terug te vinden. Daarnaast hebben we de url uit de bevestigingsmail gehaald die klanten ontvangen."

Een woordvoerder licht later ook toe: "We hebben inmiddels ook plannen voor maatregelen zoals het uitvoeren van een pentest. We zijn de afgelopen maanden ontzettend hard gegroeid en dan wil dit soort dingen er nogal eens bij inschieten."

Dit artikel kwam tot stand na een tip op Publeaks, het klokkenluidersplatform waar Tweakers ook bij is aangesloten. Ook anoniem een tip insturen? Doe dat dan via Publeaks.nl of via 5karyquenden4d6k.onion op Tor.

Door Tijs Hofmans

Nieuwscoördinator

21-10-2020 • 17:32

91 Linkedin Whatsapp

Reacties (91)

91
90
39
6
0
40
Wijzig sortering
"We hebben inmiddels ook plannen voor maatregelen zoals het uitvoeren van een pentest. We zijn de afgelopen maanden ontzettend hard gegroeid en dan wil dit soort dingen er nogal eens bij inschieten."
Sorry hoor, maar als je een website als deze online zet dan kan je niet aankomen met "oeps, we zijn de security vergeten". Of je nou 1 of 10000 klanten hebt, dat is gewoon een no-go.
Natuurlijk is het niet goed dat dit gebeurd. Maar je hebt duidelijk een te romantisch beeld van software ontwikkeling voor startups. Eerste prio is echt niet security... als je uberhaupt geen klanten hebt.

Daarna krijg je natuurlijk meer prio voor dit soort zaken, maar dan nog is het ook een kwestie van aan denken (en goed testen).

Natuurlijk is het niet netjes maar het is wel goed opgepakt. Snap alleen niet waarom dit een Publeaks verhaal is. Neem aan dat een belletje of mailtje naar Butlon voldoende had geweest.

Edit: typo

[Reactie gewijzigd door stefanhendriks op 21 oktober 2020 18:27]

Dat het in de praktijk vaak zo gaat is geen enkel excuus. Zelfs bij een startup hoeft het geen enkele moeite te kosten om vanaf dag 0 security mee te nemen in het ontwikkelproces. Of je nou automatische tools gebruikt om te scannen en testen of capabele developers hebben die hun werk snappen en met security in het achterhoofd ontwikkelen.

Hoe je het ook wendt of keert, security moet altijd aan gedacht worden. Ook bij een snelgroeiende kleine startup. Uit de reactie van Butlon zie ik dat Butlon dit enorm bagatelliseert, dat vind ik dubbel zo kwalijk.
Nogmaals. Security is wel nodig. Maar de mate waarin jij beschrijft is te romantisch in mijn ogen. Elk uur ontwikkeling kost geld. Zonder klanten zul je minimaal maar goed genoeg werken aan features.

Een niet voorspelbare url had beter geweest. Dan had zelfs met deze bug eea nog niet opgevallen.

Al is dat nog steeds security by obscurity.
Als (mede) eigenaar van een startup en als ontwikkelaar ben ik het volledig met je oneens. Tegenwoordig is security onderdeel van alle moderne frameworks. Het is dus wel degelijk een gemakzucht/onwetendheid issue en zeer kwalijk dat het in de praktijk voorkomt.
Ik denk dat we het dan over 2 soorten van veiligheid hebben. Een framework is vaak inderdaad wel veilig, maar iets als het ophalen van een bestelling via een ID in een URL is niet iets waar het framework vanaf weet, dat is logica die de programmeur zelf moet integreren. Dat is gewoon het amateurisme van de programmeurs van deze website.

Maar ik ben het er helemaal mee eens dat zoiets super simpels als dit gewoon direct gecheckt had moeten worden, of direct al met UUID's om het raden van andere bestellingen te kunnen beperken.
UUID is geen security maatregel.

Letterlijk uit https://tools.ietf.org/html/rfc4122
6. Security Considerations

Do not assume that UUIDs are hard to guess; they should not be used
as security capabilities (identifiers whose mere possession grants
access), for example. A predictable random number source will
exacerbate the situation.

Do not assume that it is easy to determine if a UUID has been
slightly transposed in order to redirect a reference to another
object. Humans do not have the ability to easily check the integrity
of a UUID by simply glancing at it.

Distributed applications generating UUIDs at a variety of hosts must
be willing to rely on the random number source at all hosts. If this
is not feasible, the namespace variant should be used.
Dat zeg ik ook niet, maar dat had het minder direct een groot probleem gemaakt. Zo moeilijk is het niet om bestellingsnummers te koppelen aan gebruikers.

[Reactie gewijzigd door Bose321 op 21 oktober 2020 21:42]

Over het algemeen kun je middels 'site:xyz.nl' in google UUID's zo vinden, of via bv. urlscan.io. Je lekt immers een URL op vele plekken (doordat er altijd wel een 3e partij wordt ingeladen). Het probleem zou dan precies even groot zijn (datalek is datalek).

Laat dus vooral los dat een UUID iets verbeterd. Obscurity is geen security.

De kennis van alleen een URL dient simpelweg nooit toegang te geven tot prive data.

Meer info: https://cwe.mitre.org/data/definitions/598.html
Dat is ook wat ik zeg. ;)
Als je moet kiezen tussen een volgnummer of een UUID is een UUID de betere keuze. Defense in depth.
Zolang je programmeurs dan maar niet denken dat ze geen monitoring nodig hebben of authenticatie.

UUID maakt het soms wat lastiger een “volgende” te vinden. Niet meer, niet minder.

Genoeg implementaties gezien waar UUID werd gezien als de gouden bullet om iets te verstoppen. Dat is het verre van.
Niet lasteriger, praktisch onmogelijk. Een uuid is 16 bytes, of 32 hexadecimale 'getallen'. Wat is dan het aantal mogelijkheden? Dat is 32^16. Laten we eens uit gaan van een webserver die 1000 verzoeken per seconde kan afhandelen, wat niet erg realistisch is, maar om ergens mee te kunnen rekenen.

Dat zou betekenen dat je 38.334.786.263.782 jaar nodig hebt om de hele space door te lopen.

Ergo, theoretisch gezien is een UUID problematisch. Praktisch gezien, zelfs als je verder helemaal niks doet, is het voor bijna alle webtoepassingen voldoende.

Neemt niet weg dat een simpele check in de backend of een uuid aan een klant toebehoort wel aan te raden is.
Voor de hele space ja, maar een datalek kun je al hebben bij UUID+1 en de UUID's kunnen ook gewoon lekken.

Maar als je het beter weet dan de makers van het UUID, be my guest to challenge them :).

[Reactie gewijzigd door willyb op 22 oktober 2020 14:53]

Precies dat. Amateuristisch? Misschien. Ik denk dat de meeste programmeurs dit wel weten. De check lijkt me eenvoudig in te bouwen.

Het is (te) eenvoudig te roepen dat het broddelwerk is. Security is achteraf altijd makkelijk roepen. Vooraf het goed doen is moeilijk. 1 fout en je bent “amateuristisch”. En dan zegt dat niets over de “moeilijkheid” van de fout.

Ik ga liever uit van de goede intenties gecombineerd met de hectiek en realiteit van bedrijven die proberen het hoofd boven water te houden.
Oneens mag ;-).

Dus als eigenaar zet je security op 1?

Daarnaast. Een framework gaat dit *niet* automatisch voor je fixen. Het feit dat je denkt dat dit zo simpel te voorkomen is maakt dat ik betwijfel of je hier (technische) ervaring mee hebt.

Dit kan op verschillende vlakken mis gaan. Proces. Techniek. Testen. Etc.

En ik vermoed dat de techneuten dit wel wisten maar het fixen op de backlog staat en qua prio niet zo hoog stond.

Dit alles praat het niet goed. Maar het is te gemakkelijk om te roepen dat zoiets “zo simpel is en niet meer voor kan komen”.
Security staat niet op 1. Het staat ook niet op 0. Zolang het niet secure is kan je er vanuitgaan dat het gehacked word. Vroeg of laat kost dat dus meer dan het initieel gelijk goed en veilig doen. Security is dus een kwestie van opnemen in je definitie van 'af'.
Als de techneuten dit wisten hadden ze het direct mee kunnen nemen. Dit is laaghangend fruit van heb Ik jou daar
Die eindigde na een succesvolle bestelling met een uniek cijfer dat opliep.
Dit is dus een combinatie van slechte uri strategie en onwetendheid mbt security.

Waarom hier niet direct voor UUID is gekozen is mij een raadsel, een oplopend nummertje als ID is altijd fout. Een Integer is om mee te rekenen, niet om mee te identificeren. Zeker bij niet openbare data. Dat gaat ge-heid fout.

Hoeveel grote sites zijn hier al mee de mist in gegaan? 2 miljoen? Dit zou altijd op je DON’T lijstje moeten staan.

Overigens moet je natuurlijk wel acces control hebben op je Resources. Dat ontbreekt hier dus ook volledig.

[Reactie gewijzigd door supersnathan94 op 21 oktober 2020 23:55]

Zelfs met oplopende id kan dit gewoon beveiligd zijn. Maar ja een fout is zo gemaakt.
Ja in principe zou je sws een 401 moeten teruggeven, want niet geautoriseerd, neemt alleen niet weg dat een Integer als ID gewoon geen slimme zet is. Je hebt gewoon geen mogelijkheden voor iets als voorloopnullen of je moet weer ingewikkelde padding constructies gaan hanteren (wat je niet moet willen).
Nogmaals. Security is wel nodig. Maar de mate waarin jij beschrijft is te romantisch in mijn ogen. Elk uur ontwikkeling kost geld. Zonder klanten zul je minimaal maar goed genoeg werken aan features.

Een niet voorspelbare url had beter geweest. Dan had zelfs met deze bug eea nog niet opgevallen.

Al is dat nog steeds security by obscurity.
Fundamentele securitymaatregelen (denk aan een OWASP top 10) bij een publieke website zijn m.i. vergelijkbaar met ervoor zorgen dat er geen poep in de kaas zit als kaasproducent. Het is niet optioneel.

[Reactie gewijzigd door Sfynx op 22 oktober 2020 00:21]

Basis security hoor je gewoon op orde te hebben anno 2020, startup of niet. Een goed incident kan je gewoon de kop kosten. Ik zou me trouwens als klant niet echt serieus genomen voelen nu en me zorgen maken over mijn persoonsgegevens.
Je gaat er vanuit dat je dan al klanten hebt en een business. Een startup heeft dit nog niet. Is bezig zijn bedrijf levensvatbaar te maken.

Overigens , ervaring leert dat heel veel bedrijven wel eens data lekken. Dus 100% voorkomen lukt niet. Of het nu een simpele of ingewikkelde “hack” zou zijn.

Ik heb overigens niet de indruk dat men geen aandacht besteedde aan security. Maar dit was wel slordig - maar wel opgelost.

Een incident kan inderdaad je de kop kosten. Daarom zeg ik ook niet dat je “geen” security moet doen. Maar wees ervan bewust dat het een prioriteiten ding is. Een startup heeft heel veel andere belangen. Security is daar een van maar is in mijn optiek lang niet zo belangrijk als men denkt.
Security moet vanaf het begin in het ontwerp van je applicatie zitten. Als je wacht met security tot je klanten hebt, ben je gewoon te laat.

Als je met de URL aanpassen andermans gegevens in kan zien heb je gewoon een fout uit de OWASP top 10. Dat is geen "oeps dat repareren we wel", dat is gewoon incompetentie van je ontwikkelteam. De oplossing is heel simpel (gebruik een GUID in plaats van een oplopend nummer) en als ze dit niet eens goed kunnen doen, denk ik niet dat ze het binnenkort de beveiliging nog op orde hadden kunnen brengen. En zelfs als ze het konden, was duidelijk de focus op groei in plaats van kwaliteit.
gebruik een GUID in plaats van een oplopend nummer
Security by obscurity is geen oplossing. Verder met je eens.
Ik ben het eens dat security through obscurity geen goede oplossing is, maar in de context van een webapplicatie kan het goed genoeg zijn. Een echt GUID brute-forcen is onmogelijk met normale rate limiting aan (122 bits aan randomness) en GUID's zijn, indien correct gegenereerd, een goede oplossing tegen het probleem zoals dat in de meeste webapplicaties voorkomt.

Het liefste heb je dit natuurlijk achter een sessieverficatie en een login zitten, maar accounts zijn barrières en steeds meer websites nemen liever eerst je bestelling aan en vragen je dan een account te maken. Als je business model gebaseerd is op accountloos bestellen, heb je weinig andere keus dan geheime links in e-mailbevestigingen.
Ik ben het eens dat security through obscurity geen goede oplossing is, maar in de context van een webapplicatie kan het goed genoeg zijn.
Geen goede oplossing, dus het is ergens wel een oplossing en geen probleem? 8)7

Het is een probleem en er moeten rechten ontleend worden aan alle bronnen die gevoelige gegevens bevatten en die rechten verkrijg je door jezelf te authenticeren (weten wie je bent) en authoriseren (weten wat jij mag zien/doen) dat is de eerste stap naar obscurity omvormen naar security. Verdere stappen vereisten nog wat meer inspanningen zoals audit trailing en non-destructive data manipulation. (i.e. een gebruiker kan een bericht aanpassen en zo het origineel laten verdwijnen.)
Het is een beetje dubbel. In principe zou kennis van de URI geen toegang moeten geven tot de resource als die niet voor jou bedoeld is. Echter hebben partijen als google allang aangetoond dat het goed genoeg is.

Zo hebben fotos die jij upload in google fotos verder geen enkele security maatregel anders dan dat er genoeg ID’s zijn om x jaar te kunnen brute forcen zonder dat je een foto tegenkomt. Zelfde geldt voor YT unlisted videos. Als jij de URI van de video weet dan mag je hem gewoon zien.

Dat is geen serieuze beveiliging in de vorm van accesmanagement, maar in de praktijk goed genoeg om geen misbruik van te kunnen maken.

Zo ook met GUIDs en UUIDs. No way dat jij er in afzienbare tijd een aantal goed hebt.
Maar wat is de impact van een check of de gebruiker ingelogd is en het ook zijn boodschappen order betreft? In het geval van Google Photos is dat vanwege de schaal iets lastiger en de URL's die je publiek deelt zijn maar beperkt houdbaar en terugtrekbaar.

[Reactie gewijzigd door GewoonWatSpulle op 22 oktober 2020 19:18]

Als je je design goed doet en iedere call bijvoorbeeld achter iets als een api gateway hebt hangen maakt het al niet meer zoveel uit. Je laat frontend als applicatie iedere keer een token meesturen en dat token kun je dan weer koppelen aan een resource autorisatie.

Inpact zou vrij laag moeten zijn aangezien het geen ingewikkelde structuren vereist.
Ik ben ook helemaal voorstander dat je in de basis eea opneemt en nadenkt over security.

Wbt uuids ipv oplopend id: dat is niet werkelijk het gat dichten maar wel moeilijker te vinden.

De owasp top 10 is zeker belangrijk om mee te nemen.
De kanttekening daarbij is dan wel dat “moeilijker” gelijk staat aan praktisch onmogelijk. Ja er is een kans dat je toevallig de eerste keer de juiste hebt, maar daarna zijn er zoveel meer dat de kans vrijwel nul is dat je toevallig direct de volgende hebt.

Maar dat is een risico afweging die je moet maken. Het is iig beter dan een oplopend nummertje.
Klopt. Mits je aan de uuids kan komen op andere wijze :)
True maar dan is er iets anders waarschijnlijk kompleet verkeerd gegaan ;)
Natuurlijk is het niet netjes maar het is wel goed opgepakt. Snap alleen niet waarom dit wen Publeaks verhaal is. Neem aan dat een belletje of mailtje naar Butlon voldoende had geweest.
Mogelijk was het een geval "ik weet niet hoe <partij> met deze responsible disclosure omgaat, dus dan meld ik het liever via deze weg om ze in ieder geval bewust te krijgen zonder dat ik repercussies hoef te vrezen".
Ik werk bij een startup, en wij nemen security en privacy zeer serieus. We gaan dan ook met gevoelige data om.
Natuurlijk neem je het serieus. Maar als je in een startup werkt weet je ook dat je heel goed de belangen afweegt om zo snel mogelijk te overleven. Dan kan je een prachtig secure app hebben zonder klanten... of een minder secure met klanten wat je uiteindelijk verbetert.

Het is natuurlijk niet zo zwart wit als ik het stel. Maar keuzes moet je maken. Je hebt maar beperkte middelen.
Dit is echt wel een noop bug. Had nooit mogen gebeuren, toch gebeurt het nog veel te vaak.
Wat zegt dat? Is iedereen een prutser? Of is er wat anders aan de hand?
Het zegt kennelijk dat je van je fouten leert (maar niet van andermans fouten).

En dat er misschien nog te weinig bekendheid is van de OWASP top 10
Maar je hebt duidelijk een te romantisch beeld van software ontwikkeling voor startups. Eerste prio is echt niet security..
Sorry hoor, maar als je anno 2020 nog niet doorhebt dat de wereld niet uit imbecielen bestaat die dergelijke 'beveiliging' niet kunnen kraken, ben jij (de startup dus) het probleem, niet de mensen die dit raar vinden. Misschien omdat ze zo druk waren met hun briljante, unieke boodschappenbezorgidee, dat ze de afgelopen 5 jaar ofzo onder een steen hebben geleefd en alleen maar bezig waren met de 'customer journey' en 'experience' dat ze totaal niet na hebben gedacht over beveiliging.

Heden ten dage zou security je nr.1 aandachtspunt moeten zijn, startup of niet. Dat heeft niets te maken met een romantisch beeld, maar met de realiteit. We zien bijna dagelijks verhalen voorbij komen over ransomware aanvallen, diefstal van klantgegeven, noem maar op. Als je dán nog niet goed nadenkt over beveiliging, zou je van de overheid een boete moeten krijgen voor elk security incident dat er plaatsvindt.
Goed. Jij investeert 100k voor een startup. Je kunt er misschien 1 a 2 developers op zetten. En je wil 100% secure? Daar gaat je budget.

Een startup moet eerst uberhaupt geld verdienen. De meeste startups beginnen zelfs houtje toutje, lek als een mandje. Avg? Forget it.

Denk aan bijv een combinatie van verschillende Excel sheets en allerlei communicatie over whatsapp en weet ik wat.

Is dat veilig? Zeker niet.

De realiteit is dat jij (en ik) niet dagelijks in de startup wereld zitten.
100% secure is geen optie. Je zit namelijk met externe software en leveranciers. En die hebben geheid wel ergens een bugje oid wat tot issues kan leiden.
Startup of geen startup, checken of oplopende IDs wel beveiligd zijn is onderdeel van basis veiligheid, net als het instellen van een wachtwoord op je server en het hashen van je gebruikers wachtwoorden.

Het kost je bovendien nog geen 5 minuten.

Er is geen excuus voor onveilige code. Bij de 1e gebruiker moet het op orde zijn. Als een ontwikkelaar “hmm ja sorry ik had haast” als rede gebruikt, moet ie een andere baan zoeken.

[Reactie gewijzigd door Gamebuster op 22 oktober 2020 08:43]

Ben met je eens dat dit een wel heel eenvoudige casus is waar je snel wat checks kon maken.

Aan de andere kant ging dit om een succespagina. In een business case moet je eerst maar eens de klant zover krijgen. Maar alas, daar hebben we het al over gehad.
Ik snap echt niet hoe programmeurs anno 2020 zoiets over het hoofd zien, niet weten of niet hebben meegenomen terwijl ze het aan het maken waren.
Omdat je als programmeur waarschijnlijk een gigantische backlog aan tickets hebt om je doorheen te werken, en deze ook binnen een redelijke tijd wil afwerken. En code reviews lang niet altijd goed worden uitgevoerd. En er bij acceptatie tests niet op wordt gelet.

Welkom in de echte wereld.

[Reactie gewijzigd door Bas.Bas.Bas op 21 oktober 2020 17:42]

In de echte wereld weet je gewoon dat je NOOIT oplopende id’s gebruikt in urls of andere publiek inzichtelijke/manipuleerbare bronnen.

Dat heeft niets met backlogs te maken want het gebruik van bv een UUID kost echt 1 minuut meer van je tijd en helpt al enorm. Je ‘select’ pakt een ander veld en tijdens het opslaan geef je of een UUID mee of je laat je database deze automatisch zelf maken.

Nee dit ruikt gewoon naar amateurisme en mag al helemaal niet zo afgewimpeld worden als ze doen want ook dat is alles behalve professioneel
Al is oplopend niet handig. Het is zeker niet amaturistisch. Je moet meer checken. (Of ingelogde gebruiker bij een resource mag).

En dat heb je ook met uuids.

Dat je urls minder goed te raden zijn is goed. Maar maakt het niet veiliger. Hooguit obscuurder.
Een username mag geen wachtwoord zijn, daar heb je gelijk in. Het ID is in dit geval functioneel gelijk aan een password want het gaf toegang tot de data. Dat mag niet, en dat is punt twee dat hier fout liep. Security in layers zegt dat je beide goed moet doen. Dat is niet hetzelfde als security through obscurity.
Dat je urls minder goed te raden zijn is goed. Maar maakt het niet veiliger. Hooguit obscuurder.
URLs met UUID als id in plaats van oplopende ID's zijn niet "minder goed" te raden, ze zijn gewoon niet te raden.
Natuurlijk is een UUID ook te raden. Afhankelijk van de grootte can de UUID heb je meer missers voordat je een keer goed gokt, maar onmogelijk is het niet.
Wie zegt dat je ze moet raden? Mogelijk zijn er wel andere wijzes om aan de uuids te komen. Dan kan je er alsnog bij en is het nog steeds lek.

Een check of je bij een resource mag is de echte fix.
Zoals stefanhendriks al aangeeft, je hoort er ' in de echte wereld' gewoon voor te zorgen dat er correcte toegangscontrole zit op de relevante content. Of je daarvoor een oplopende id of een UUID gebruikt maakt geheel niets uit. Als iemand een URL met een UUID doorstuurt/deelt/gokt en er zit geen controle op heb je nog steeds een lek, dat gaat een UUID echt niet oplossen.

Als je niet wil dat gebruikers weten hoeveel entries er zijn kun je beter geen oplopende id gebruiken. In andere gevallen zie ik geen probleem dat wel de gebruiken. En in alle gevallen moet je sowieso correcte toegangscontrole implementeren.
Je kunt heus wel oplopende getallen gebruiken, maar niet voor afgeschermde content. Tweakers nieuwsartikelen zijn ook gewoon een oplopend getal.

Je maakt iets om snel te groeien en wat zo toegankelijk mogelijk is, een login voor een bevestiging is erg klantonvriendelijk en wil je dus niet. Misschien is het inderdaad door wat minder ervaren programmeurs gemaakt. Ze wimpelen het ook helemaal niet af, het is snel opgepakt en aangepast, en echt een groot probleem kun je het ook niet noemen.
Precies.

Men reageert alsof het nooit had mogen of kunnen gebeuren. Getuigt naar mijn mening van een erg naief en romantisch beeld.

En het is inderdaad goed opgepakt en opgelost.
Ik ben meer hobby programmeur maar als je tijdsdruk hebt kun je ook de pagina anders aanroepen.

Dan gebruik je als workaround iets van een willekeurig gegenereerde id die je gebruikt. Dan kun je in ieder geval niet meer (mijn id) - 1 doen.

Is minder ruk, maar nog altijd niet ideaal.
Precies. Geen voorspelbare url gebruiken is beter.
In dit geval zou ik eerder aan de server kant een check doen of jij als ingelogde gebruiker eigenaar bent van de boodschappenlijst. Dan hoef je ook niet met guids te werken, want sommige databases sorteren guids langzamer dan een normale integer. Ligt aan de gebruikte techniek natuurlijk, bij sommige databases kan je veilig een guid als primary key gebruiken. Het is nooit een makkelijke keuze, daarom verdient IT’er zijn zo lekker. :+
Tot op zekere hoogte, maar oplopende, publiek toegankelijke URL's? Nee echt niet. Dat is echt een gigantische fout die iedereen had moeten zien. Maakt niet uit hoe vol je backlog is. Zoiets als dat mag echt nooit gebeuren.

Ook grappig hoe ze in hun statement zeggen dat ze nu 'beter' de data beschermen, ze bedoelen natuurlijk dat ze nu pas überhaupt enige vormen van beveiliging hebben toegevoegd. :+ De enige plek die ik kan bedenken waar (oplopende) ID's in een URL acceptabel zijn is waar je in de code ook checkt of de ID van hetgeen wat je opvraagt ook hoort bij de gebruiker die momenteel ingelogd is. Maar verder gewoon UUID's gebruiken mensen...

[Reactie gewijzigd door Bose321 op 21 oktober 2020 18:59]

Eh nee.
Als je jezelf programmeur noemt, en dit soort fouten maakt moet je gewoon echt of een cursus gaan volgen, of een andere baan zoeken.
Dit zijn fouten die we maakten in 1996
Jullie hebben allen gelijk dat het ophalen van data hoe dan ook gevalideerd moet worden op de rechten, en ja ook een uuid is ‘te gokken’ maar een goed uuid van 32 tekens is dermate random dat het niet zo simpel is als een +1 en vind dat IDs in dit geval vervangen door UUIDs het probleem enigszins hadden voorkomen (zei het tenzij je gaat brute forcen). In dit geval is huidige id -1 gewoon heel kwalijk
Nee, dan ben je gewoon een beunhaas die een andere baan moet zoeken.

Dit is onderdeel van basis beveiliging dat ten alle tijden op orde moet zijn. Foutje kan gebeuren maar “boehoe ik had haast” is geen goede rede.

Ik heb ook altijd haast voor mijn klanten (zoals je al zei: welkom in de echte wereld) en nooit bespaar ik op dit soort dingen. Voordat de 1e gebruiker erop gaat, wordt dit goed gecheckt, getest en nog een keer gecheckt door een 2e persoon.

Nooit is er zoveel haast dat je persoonsgegevens in gevaar kan brengen. Beveiliging is onderdeel van de planning en offertes die we aanbieden en ik vind het beangstigend dat er blijkbaar een meervoud aan collega developers hier het acceptabel vindt om beveiliging te negeren omdat klanten haast hebben.

[Reactie gewijzigd door Gamebuster op 22 oktober 2020 08:48]

echt he

je weet welke gebruiker er is ingelogd .. dus je weet welke bestelling bij die gebruiker horen,
andere data dan dat is niet beschikbaar, klinkt zo simpel.

Als die koppeling al mist ... 💣
Wat ik uit de reactie van Butlon begrijp was het eerst niet nodig om in te loggen en kon je met een directe link informatie van een oude bestelling inzien.
Jouw aangedragen oplossing is een van de maatregelen die ze nu genomen hebben:
"Een voorbeeld hiervan is dat we nu url's van bestellingen randomizen en het is verplicht om in te loggen om oude bestellingen terug te vinden.“
Ik lees dat anders
Ze zeggen dat ik moet inloggen "om oude bestellingen terug te vinden" .. het probleem was dat dát nou juist al kon.
Ze zeggen niet dat je ook daadwerkelijk jouw eigen bestellingen te zien krijgt.

Als ze dat namelijk zouden hebben opgelost zijn het randomizen van de url en het weghalen van de link uit de mail volledig overbodig, want het is net veilig gemaakt.

Overbodige dingen ga je doen als je tijd over hebt .. wat ik begrijp uit het verhaal is dat ze dat niet hebben .. dus ze hebben dat gedaan omdat ze het nog steeds niet waterdicht hebben kunnen maken.
Programmeurs. Testers. Etc.

Daarnaast is het simpelweg soms geen prio. Hoe kwalijk ook. Zonder klanten valt er niets te beveiligen.
Technologie wordt vaak als kostenpost gezien en wordt daarom uitbesteed. De contracten die daaruit vloeien worden gehonoreerd op basis van functionaliteit, niet op basis van veiligheid en andere technische specificaties. Deze contracten gaan naar de laagste bieder, en dat zijn geen personen met diepgaande kennis.

Het internet en technologie zijn zo belangrijk geworden, dat het helemaal niet gek zou zijn om hier officiële licenties aan vast te binden als je werkt met persoonsgegevens, vertrouwelijke data, financiële transacties, etc. Dat zorgt er in ieder geval voor dat grove nalatigheid zoals dit geval een stuk minder vaak zal voorkomen, en dat we de veiligheid van onze internet-infrastructuur op peil kunnen houden. De impact van een fout kan tegenwoordig net zo veel gevolgen hebben als een fout in rechtspraak of zelfs de medische sector, waar ook licenties voor moeten worden gehaald.
Dat is er al en noem je o.a. ISO-certificering. Waterdicht is zoiets helaas nooit.
Had het recent nog bij een hostingboer, als je in het dns paneel was ingelogd kon je iemand anders de url sturen die op hetzelfde ip zat en die kon dan ook alles.
Kwestie van zo snel mogelijk "hippe/makkelijke" websites/apps de lucht iin gooien, in de hoop goed te scoren. Zou eigenlijk een soort van certificaat moeten worden uitgegeven door de overheid waarmee je je als developer en/of bedrijf kan aantonen dat je enigszins geschikt bent om data van personen te behandelen.
Ik ga morgen een keurmerk opzetten, doe je mee? Gaan we 10k inschrijfgeld, en 750 euro per maand per lid vragen, iedereen die niet meedoet programmeert slecht, en is gevaarlijk voor uw privacy
geen tests geschreven zeker...DIt kan toch niet? Je hebt toch een algemene auth laag die overal overheen zit, en je test of dit daadwerkelijk zo is? Ik word nog wel 'ns midden in de nacht wakker om dit soort dingen..
Er zijn echt belachelijk veel web dev bedrijven waar 0 unit of integratie tests worden geschreven. Het kost teveel tijd en uren/geld is er niet is altijd het excuus. Het is echt bedroevend. Ik kan er echt niet bij dat bij web development tests opeens optioneel zijn terwijl het gewoon onderdeel van de software hoort te zijn. Daarnaast zijn er teveel junior,medior of zelfs seniors die geen idee hebben hoe je uberhaupt tests schrijft.
heb dit persoonlijk meegemaakt; producten worden afgelverd zonder tests, en zijn niet te onderhouden.
Een auth laag handelt niet altijd alles af. Te naief gedacht helaas.
wanneer zou dit niet alles afhandelen?
Hangt van je urls af. En of je iets dergelijks middels een AOP achtige oplossing kan doen. Vaak zijn er toch uitzonderingen die je over het hoofd ziet.

Maw alles kan. Maar simpelweg roepen: auth laag! Is te kort door de bocht.
dan maken jij en ik hele andere applicaties, want dan vergeet je dus gewoon je tests te schrijven, laten we hopen dat je nooit wat voor mij maakt :)
Ongeacht wat voor apps je maakt heb je te maken met dat niet alles in een “auth laag” opgelost wordt. Te kort door de bocht.

tests schrijven heeft er ook weinig mee te maken.

Zelfs met tests kun je fouten maken.
heel veel "dat is het niet" en "dat is het niet" maar weinig voorbeelden.

Tests zitten vol met fouten, maar als je je authenticatie/authorizatie niet goed hebt staan heb je wat mij betrefd een groter probleem.
Goed dat deze lek zo snel gevonden is dan.. ik zie dat daarnaast de frontend ook wat werk nodig heeft..

[Reactie gewijzigd door RCKD op 21 oktober 2020 20:30]

Oftewel. Het lijkt een beetje snel in elkaar gezet te zijn..

[Reactie gewijzigd door RCKD op 21 oktober 2020 20:19]

Beginnersfout dit. Hier zou een developer een hele groot schop voor onder z'n hol mogen krijgen.
Precies, ongelofelijk dat dit nog steeds gebeurd.
De zoveelste keer dat zoiets gebeurt en er op Tweakers een artikel over verschijnt.

Is dit niet een datalek wat ze ook verplicht bij de Autoriteit Persoonsgegevens hebben moeten melden? Je kon immers privégegevens van andere klanten inzien, inclusief hun adres.

Ik zou het niet erg vinden als bedrijven voor dit soort slordigheden een boete zouden krijgen. Je hebt als bedrijf een verantwoordelijkheid om klantgegevens veilig op te slaan. Daarbij maakt het niet uit of je een startup bent die probeert alles snel en goedkoop te doen, die verantwoordelijkheid heb je gewoon.

Boeten en ook publiceren wat er is gebeurd, zodat hopelijk in de toekomst dit beter tussen de oren komt te zitten van de managers en ontwikkelaars van alle bedrijven die met klantgegevens werken.

[Reactie gewijzigd door jj71 op 21 oktober 2020 19:59]

Ook niet onbelangrijk is of ze melding hebben gemaakt van een datalek bij de autoriteit persoonsgegevens.

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee