Gegevens Blokker-klanten waren eenvoudig op te vragen middels aangepaste url

Namen, adressen, telefoonnummers en de inhoud van bestellingen van willekeurige klanten waren eenvoudig in te zien op de website van winkelketen Blokker. Een kwaadwillende hoefde alleen een url aan te passen door het bestelnummer te wijzigen, waarna de gegevens getoond werden.

Het datalek kwam aan het licht na een tip van een lezer van Opgelicht?!, dat de zaak daarna onderzocht. Ethisch hacker Sijmen Ruwhof zegt tegen Opgelicht dat het datalek zeker sinds eind oktober 2020 aanwezig is en dat er 720.000 verschillende bestellingen mee gemoeid zijn, hoewel er niet specifiek wordt vermeld hoe men tot dat getal komt.

Blokker zegt in een reactie de Autoriteit Persoonsgegevens ingelicht te hebben over het datalek. Verder stelt het dat het na het ontdekken van het lek, het probleem nog dezelfde dag opgelost had. Dat was vrijdag. Het bedrijf biedt zijn excuses aan en zegt er alles aan te doen om herhalingen te voorkomen. Een jaar geleden had Blokker ook een datalek. Toen werd er ingebroken bij accounts, hoewel niet duidelijk is of de logins ook van Blokker zelf zijn gestolen, of dat er gebruik werd gemaakt van credential stuffing.

Beeld: Opgelicht?!

Reacties (163)

[sverzijl]

Maar is dit nu een fout die in _alle_ Demandware/Salesforce webshops zit, of is dit gekomen door customizations die door de ontwikkelaars van Clockwork(Ordina) op blokker.nl is toegevoegd ?

[HouseL]

Dit komt niet door Commerce Cloud van Salesforce. Betreft custom code.

Waar lees je overigens dat dit door Clockwork / Ordina is gemaakt?

[Reactie gewijzigd door HouseL op 24 juli 2024 04:33]

[sverzijl]

Dat weet ik van de vorige partij die het beheer/onderhoud deed van de webshops van Blokker Holding (toen nog gebruik makend van WebSphere Commerce). Ergens vorig jaar is dit vwb blokker.nl overgenomen door Clockwork, die het naar Salesforce hebben overgezet.
(Je kan er ook wel iets over vinden op de linkedIn page van Clockwork, in ieder geval dat ze pas nog Blokker Express hebben toegevoegd op blokker.nl)

[Reactie gewijzigd door sverzijl op 24 juli 2024 04:33]

[jimshatt]

Aan de url en de layout van de pagina zou ik SharePoint gegokt hebben maar ik ken Salesforce niet.

[MrFax]

Meestal staan er wel hints over in in de page source. Als je vergelijkbare code ziet dan is dat een makkelijk gegeven.

[Reactie gewijzigd door MrFax op 24 juli 2024 04:33]

[RVervuurt]

hoewel er niet specifiek wordt vermeld hoe men tot dat getal komt.

Ik gok dat ie een crawler of robot heeft gemaakt, die een simpele "$bestelnummer - 1" doet, totdat deze een 404 tegenkomt. Zo wordt het toch vaker gedaan in het geval van zulke URL-aanpas-lekken?

[GertMenkel]

Het is natuurlijk ook mogelijk dat het puur willekeurige getallen zijn, maar tien miljard getallen opvragen over een periode van een week is niet meer zo duur als dat het tien jaar geleden was. Het kost je een rits aan VM's enzo voor je de data hebt, maar als je de data kunt verkopen of de winkel weet af te persen is het het natuurlijk dubbel en dwars waard.

Verifiëren dat het lek er is, is simpel: bestel twee keer iets met verschillende accounts bij de Blokker en check of je vanaf het ene account bij de order van de ander kan. Als dat mogelijk is, is je lek aanwezig. Hoe groot de kans is dat een aanvaller daar daadwerkelijk gebruik van maakt hangt natuurlijk af van hoe groot je identifiers zijn en hoe je ze genereert (oplopend is redelijk logisch, aangezien de belastingdienst bijvoorbeeld graag wil dat achtereenvolgende facturen stijgende factuurnummers hebben). Als je een GUID in de URL plempt is de kans dat die geraden wordt natuurlijk nihil, maar desondanks moet je je access control wel instellen zodra duidelijk wordt dat men elkaars links kan inzien.

[RVervuurt]

Als het inderdaad willekeurige getallen waren, dan was het niet zo'n groot probleem, want dan heb je "security through obscurity" (nog steeds niet goed genoeg, natuurlijk), gezien je dan wel heel veel geluk moet hebben om een juist ordernummer in te typen.

Het is daarom zeer waarschijnlijk dat ordernummers gewoon incrementeel zijn.

Maar inderdaad, zelfs als de getallen willekeurig waren, kan je voor een paar tientjes wel alle getallen checken denk ik.

[CodeCaster]

In het geval van GUIDs is het onmogelijk om ze allemaal op te vragen. Niet eens in een redelijke tijd wanneer je met alle computers van de wereld er duizend per seconde opvraagt.

Er zijn zo'n 2e120 GUIDs. Dat is een getal met 36 nullen erachter.

[MarcoC]

Exact. Alsnog moet je nooit een kwaadwillende kans geven een brute force aanval uit te voeren vanuit de client.

[Jeffrey_KL]

Hier ga je een beetje over het punt van een bruteforce heen. laten we zeggen dat de blokker 10.000.000 bestellingen in hun systeem hebben staan. Dan is de kans 1e+7 op 1e+36. Kort gezegd ongeveer een kans van 1 op 1e+29. laten we zeggen je kan 10.000 orders proberen op te vragen in een seconde(de blokker servers kunnen natuurlijk niet miljoenen orders per seconden teruggeven). dan ben je nogsteeds 1e+25 seconden bezig. oftewel een goeie 100.000.000.000 miljard jaren om 1 order te vinden.

Ik heb zo'n gevoel dat je sneller bent hun encryptie te kraken dan de orders op deze manier vinden.

[Reactie gewijzigd door Jeffrey_KL op 24 juli 2024 04:33]

[Macshack]

Ja maar je kan de pool behoorlijk verkleinen door eerst zelf een bestelling te plaatsen om te kijken hoe de GUID er uit ziet. Want GUIDs worden niet zo random gegenereerd. GUIDs zijn voornamelijk uniek en niet random.

[Argantonis]

Ja maar je kan de pool behoorlijk verkleinen door eerst zelf een bestelling te plaatsen om te kijken hoe de GUID er uit ziet. Want GUIDs worden niet zo random gegenereerd. GUIDs zijn voornamelijk uniek en niet random.

Dat is simpelweg niet waar voor een correcte implementatie van een moderne v4 GUID, die elke programmeertaal standaard heeft ingebouwd. En zelfs andere versies zijn niet zó makkelijk te raden maar die gebruiken wel bepaalde input die de range wat kleiner maakt. Maar v4 is veruit de meest gebruikte versie.

[sympa]

En wachtwoorden raden gaat ook een stuk sneller. Alleen heb je dan een lek als je op een andere manier aan die GUIDs kan komen.
Daarom is dit op zichzelf niet de aangewezen weg. Ook al omdat je dit niet naderhand kan rechtzetten, mochten de gebruikte GUIDs ooit uitlekken.

[djwice]

Niet eens meer een rits aan VM's
Waarom zou je 10 miljard requests doen?
Vaak zit er een patroon in de bestelnummers.

[Reactie gewijzigd door djwice op 24 juli 2024 04:33]

[jvo]

Ik gok dat ie een crawler of robot heeft gemaakt, die een simpele "$bestelnummer - 1" doet, totdat deze een 404 tegenkomt. Zo wordt het toch vaker gedaan in het geval van zulke URL-aanpas-lekken?

Dat ligt voor de hand, maar het order ID op de afbeelding bestaat uit 11 cijfers. Dan kan het nog steeds om een opvolgend blok daarbinnen gaan, maar er is ook een goede kans dat de nummers niet aansluitend zijn.

[Reactie gewijzigd door jvo op 24 juli 2024 04:33]

[a fly]

een factuurnummer
Gebruik opeenvolgende nummers voor uw facturen, met 1 of meer reeksen. Elk factuurnummer mag maar 1 keer voorkomen.

- Belastingdienst
Hierdoor zijn in de praktijk de meeste bestelnummers opvolgend.

[Alex3]

Het bestelnummer hoeft niet gelijk te zijn aan het factuurnummer.

[a fly]

Dat klopt, maar dat is vaak wel zo of het is een andere opvolgende reeks. Daarnaast is een N+1 makkelijker in een database dan iets anders verzinnen. Bij de meeste winkels waar ik vaker bestel is er duidelijk een opvolgende reeks in bestelnummers.

[Reactie gewijzigd door a fly op 24 juli 2024 04:33]

[Jeffrey_KL]

Wat is er lastig aan het gebruiken van een guid (unique identifier in sql)?
De enige reden die ik zou weten is dat het handig is om snel te zien waar de order vandaan komt zoals jaartal of ordertype maar dan alsnog kan je een ordernummer op basis van nummers maken en een Guid als indentifier gebruiken.

[ari]

Vanaf de andere kant geredeneerd, waarom zou je niet gewoon een oplopend id gebruiken? Een ordernummer is niet geheim, zodra je gaat doen alsof dat wel zo is dan ben je slechts bezig met security by obscurity. In sommige gevallen is dat handig (om het scrapen van openbare posts te voorkomen, zoals op Twitter), maar als je ingelogd moet zijn om de gegevens te bekijken zou een oplopend id gewoon moeten voldoen.

[riesm]

Goed punt hier. De bug is niet per se het kunnen wijzigen van het ordernummer in de url, maar het feit dat deze url leidt tot het zichtbaar maken van de bestelling terwijl de gebruiker daar niet toe geautoriseerd is. Door dat het opvolgende nummers zijn, wordt het vervolgens gemakkelijker om deze bug uit te buiten. Het gebruik van een guid maakt dus hooguit de uitbuiting van de bug lastiger.

[Jeffrey_KL]

Een reden om geen oplopen ordernummer id te gebruik is dat het meer informatie naar buiten gooit dan alleen het ordernummer. Zo kan je aan een oplopend id zien hoeveel er voor zijn geweest maar je kan ook zien wat er binnen een week is gebeurd.

Dan kan je nog slimmere dingen gaan doen door timings gericht te gaan kijken welke orders niet meer bestaan(een niet bestaande order kan langer of korter duren dan een bestaand order ophalen). Dit is misschien een indicatie van hoeveel orders geannuleerd worden.

Mijn punt is dat een oplopend id meer informatie naar buiten gooit dan je verwacht.

[Reactie gewijzigd door Jeffrey_KL op 24 juli 2024 04:33]

[ari]

Dat is een goed punt. Dat staat in mijn ogen los van beveiliging van bestellingen op zichzelf, want in principe zou je dezelfde foutmelding moeten geven als iemand een ordernummer opvraagt waar die niet bij zou moeten kunnen. Dan zou je dus zelf actief bestellingen moeten plaatsen om te bekijken hoeveel het ordernummer is opgelopen. En als je iets bestelt dan krijg je ook een factuur, waar sowieso een oplopend factuurnummer op moet staan omdat de belastingdienst dat graag ziet. Ik denk dat het dus wel meevalt, maar het is wel een overweging om mee te nemen.

[sypie]

Helaas hebben factuurnummer en bestelnummer niks met elkaar te maken. Dit is gewoon gemakzucht van een devver geweest.

Men had ook prima de hash met een dat van een bestelnummer aan het eind van de URL kunnen zetten, dan was het niemand opgevallen...

[Tadsz]

Met een simpele hash is het enkel een kleine stap extra. 2 korte bestellingen achter elkaar laat zien dat je factuurnummer oploopt en je hashes overeenkomen. Dan maak je een lijst van gehashte factuurnummers en ben je weer terug bij het begin.

Je zou daar op zijn minst een account salt aan toe moeten voegen zodat je vooraf ook moet weten tot welk account het behoort; maar waarom zou je daar zoveel moeite insteken als je ook een goede authenticatie kan implementeren die verifieert of jouw account wel bij die bestelling hoort.

[vickypollard]

Je kunt over het algemeen ook zonder een account bestellen bij webshops, dus dan gaat zo'n authenticatie niet op (of ja, het kan natuurlijk alsnog wel voor accounts). Dan moet je volgens mij wel werken met een token?

[Reactie gewijzigd door vickypollard op 24 juli 2024 04:33]

[Xerxes249]

Laat me raden, de 991 is een prefix dat gebruikt wordt om een ordertype ofzo aan te duiden, de 00726710 is het daadwerkelijke id.

[Lennart221998]

Dacht precies hetzelfde, alleen jouw comment niet gezien toen ik die van mij plaatste.

[Lennart221998]

In de bijgevoegde schermafbeelding zie je het order nummer.
Haal je die 99100 ( wat waarschijnlijk een prefix ) weg, kom je ongeveer op die 720.000

[jpgview]

Misschien moet de wetgever hier maar eens ingrijpen. Bedrijven waar zo'n fouten worden gemaakt verplichten om hun hele publieke infrastructuur door te laten lichten door een erkende security auditor. Er zal waarschijnlijk nog wel meer mis zijn met de (IT) visie en methode, waarmee ze diensten aanleveren en jouw gegevens verwerken en opslaan...

[Mars Warrior]

De Blokker maakt in dit geval gebruik van het e-commerce cloud platform van Demandware, onderdeel van Salesforce.com. Dit zou betekenen dat de Blokker dit platform moet (laten) analyseren.

Als de verantwoordelijkheid bij de klant van de cloud dienst ligt, dan zou jij dus ook platformen als Magento, en WooCommerce moeten doorlichten voordat je deze gebruikt voor je simpele internet shop voor sokken.

[Gropah]

Om eerlijk te zijn zou Salesforce zo'n simpele enumeration attack niet moeten hebben. Dus of er is wat grofs mis daar, of het is custom code waar blokker dan (imo) wel deels voor verantwoordelijk is.

[Mars Warrior]

Wefashion had exact dezelfde bug, dus dat is dan of het platform, of een plugin.
Lijkt me sterk namelijk dat beide bedrijven exact dezelfde bug maken.

[taurgis]

Ben zelf Demandware (Salesforce Commerce Cloud B2C) ontwikkelaar. Dit komt door custom code, in de basis zit er een simpele check if(session.customerID !== order.customerID) --> go away.

Ook is er een optionele instelling om enkel orders toe te laten in de voorkant als de session/account de maker was van het order, die een error zou veroorzaken als iemand de API oproept om een order op te roepen waar ze geen eigenaar van zijn.
Maar dit zorgt voor een volledige pagina crash rather dan een mooie redirect, vandaar dat in de code die check er nog in zit.

De code is natuurlijk net iets anders, dit om het simpel uit te leggen.

[Reactie gewijzigd door taurgis op 24 juli 2024 04:33]

[Harrie_]

Dit inderdaad. De grote vraag is natuurlijk wie er verantwoordelijk is; degene die het platform aanbiedt (Blokker in deze) of de ontwikkelaar. De fouten bij het 737-Max vliegtuig is ook de verantwoordelijkheid van Boeing, niet van de luchtvaartmaatschappijen; ik zie niet in waarom dat met software anders zou moeten werken. IT en online dienstverlening is anno 2021 zo'n belangrijk onderdeel van de maatschappij geworden dat er wat mij betreft wel een zelfde soort systeem gehanteerd mag worden als bij artsen en advocaten; als een ontwikkelaar dit soort elementaire fouten maakt zou er dan een reprimande moeten kunnen volgen en in het ergste geval een soort 'ontzetting uit het ambt', dan ga maar fijn vakken vullen i.p.v. brakke software maken...

[Crim]

Denk dat Blokker er wel vanuit mag gaan dat het platform goed is, ze betalen er ook enorm veel geld voor.

[Harrie_]

Daar ben ik het mee eens maar in de praktijk zie je dat vaak de 'aanbieder van de dienst' de verantwoordelijkheid in de schoenen geschoven krijgt en niet de 'bouwer van het product'. Dit terwijl juist bij tastbare producten (Boeing 737-Max, de Stint, etc.) het volkomen normaal is dat de verantwoordelijkheid voor ontwerpfouten juist bij de producent van het product ligt.

@feuniks: Als Blokker ervoor zou kiezen om zijn data bij een externe firma neer te zetten en die zouden de data op servers in de VS of Rusland onder brengen, dan is Blokker daar volgens de AVG toch ook verantwoordelijk voor.

Het lastige aan zoiets is dat een aanbieder zoals Blokker prima kan een leverancier kan verlangen om de data op te slaan in Europa, je hoeft ook geen IT-specialist te zijn om wet- en regelgeving te kunnen interpreteren. Als het erom gaat of een product technisch goed in elkaar steekt (dus geen enumeration, geen sql injectie, etc.), lijkt het mij dat bijv. een Blokker er vanuit mag gaan dat de ontwikkelaar dit soort dingen tackelt. Wat is het alternatief? Dat Blokker zelf technisch specialisten in dienst neemt of iedere IT-oplossing laat toetsen door derden? Toen dat ongeluk met de 'stint' plaatsvond werd er ook niet gewezen naar het kinderdagverblijf (alsof zij op de hoogte zouden moeten zijn van technische mankementen in het product). Nadat bleek dat er technisch van alles niet in orde was werd gewoon de producent van de stint verantwoordelijk gehouden, en terecht. Op het gebied van software vind ik het lastig om precies te bepalen wie wanneer en waarvoor verantwoordelijk is, maar toch vind ik het wel vreemd dat bij tastbare producten vrijwel altijd de verantwoordelijkheid bij de producent ligt terwijl bij software de verantwoordelijkheid ineens bij de aanbieder van de dienst of het product ligt.

[DeCo]

Precies.. ik werk met een ander groot en kostbaar marketingplatform, waar behoorlijk onverschillig met dit soort zaken wordt omgegaan.. "ach, bugs heb je altijd". Onlangs een lek gevonden, wat gewoon hard terugegooid werd: los het zelf maar op met een workaround. Pas na escalatie werd er met tegenzin toch teruggekrabbeld en wordt het nu bekeken.

Ik denk soms dat dit soort platforms te groot en dus onbeheersbaar gaan worden.
Wat mij betreft heeft Salesforce hier een probleem, niet Blokker.

[sympa]

En waarschijnlijk ook nog een geheimhoudingsclausule waardor je niet in het openbaar over defecten van het product mag praten.
Ik denk dat een dwingende vorm van ketenaansprakelijkheid nodig is.
Al krijg je dan natuurlijk contracten waarin staat dat de internetfuncties van het product 'experimenteel' zijn en niet gebruikt mogen worden.

[feuniks]

Er is voor beiden wat te zeggen. Als ik met mijn nieuwe auto de showroom uit rijd en aan het eind van de straat in een politiecontrole rijd, die constateert dat er technisch wat mis is aan mijn auto, dan krijg ik daar een prent voor, want ik ben er uiteindelijk verantwoordelijk voor dat ik met een auto rond rij, die technisch correct is. Dat ik er wellicht met een waarschuwing van af kom, omdat de verbaliserend agent ook wel snap dat ik hier weinig aan kan doen is een tweede. Wat er bij die Boeing trouwens speelt is een "terugroepactie". Als blijkt dat de fabrikant van mijn auto een productiefout heeft gemaakt en dat er in de serie, waar mijn auto ook in valt iets structureel niet goed zit, dan zal de fabrikant de auto's moeten terugroepen voor reparatie (ook al is die van mij nu vijf jaar) en dat is normaal gesproken kosteloos voor mij.

In principe is (denk ik) de aanbieder van het platform verantwoordelijk. In dit geval Blokker dus. Ik ben geen jurist, dus ik zet bewust even denk ik erbij. Dan had je maar beter onderzoek moeten doen. Dat klinkt misschien hard, zeker als je bedenkt dat bedrijven als Blokker de klanten spullen willen verkopen en niet IT beheerder spelen. Als Blokker ervoor zou kiezen om zijn data bij een externe firma neer te zetten en die zouden de data op servers in de VS of Rusland onder brengen, dan is Blokker daar volgens de AVG toch ook verantwoordelijk voor. Dat Blokker zijn leverancier voor de schade aansprakelijk kan stellen, is overigens een ander verhaal.

[PTish]

Ik denk dat het probleem hem in custom code dan wel plugins zit. Ik ken een andere grote internationale retailer die al jaren alle orders lekt die ook gebruik maakt van DemandWare.

Begin januari gemeld. Wordt nog steeds gewerkt aan een oplossing....

Edit: En dit lek is iets anders en iets complexer dan het lek van Blokker

[Reactie gewijzigd door PTish op 24 juli 2024 04:33]

[vandijk]

De meeste ecommerce oplossingen die ik gezien heb, zijn een samenraapsel van systemen van meerdere leveranciers. De integratie verloopt vaak via de voorkant (urls). Zelfs als de platformen zelf goed dichtgetimmerd zijn, dan zijn er nog voldoende mogelijkheden voor ontwikkelaars om daar een grote puinhoop van te maken. Grote boosdoeners zijn meestal de (re)marketing integraties. Wil je in je mailings gebruik kunnen maken van de bestelhistorie, dan moet die mailing tool wel bij de bestelgegevens kunnen. Die scrape je natuurlijk makkelijk obv een ordernummer uit de commerce omgeving.

[GertMenkel]

Maakt het uit waar de code staat? De Blokker is degene die de klantgegevens beheert. Dat ze Salesforce de opdracht geven om die gegevens voor ze te verwerken, betekent niet dat zij de verantwoordelijkheid hebben om te zorgen dat ze hun zaken op orde hebben.

Als ik iets bestel bij de Blokker dan is het het probleem van Blokker als mijn gegevens uitlekken. Of ze nu Salesforce of WooCommerce gebruiken kan mij geen zak schelen als klant; waarom zou het qua verantwoordelijkheid wel een verschil moeten maken?

Daarnaast is Salesforce natuurlijk niet één platform, het zit vol met plugins en custom logic die desnoods door onderondernemers in elkaar wordt gevlochten. Als alle Salesforcegebaseerde winkels dit probleem hadden, was Salesforce overal in de pers voorbij gekomen. Het lijkt tot nu toe alleen de Blokker-implementatie te zijn die dit probleem heeft, dus ik vind het niet onredelijk om Blokker dan te dwingen hier onderzoek naar te doen.

Verder neem ik aan dat als er een degelijke wet doorkomt, ieder contract met een softwareleverancier ook een clausule krijgt die bepaalt wie welk deel betaalt van een eventuele doorlichting. Als de kosten daarvoor bij het "klant"-bedrijf komen te liggen, moet dat maar een reden zijn om een ander bedrijf in de arm te nemen of om zelf een systeem te (laten) ontwikkelen als het niet naar wens is.

Ik vind "ja maar ik heb de software niet geschreven" een slap excuus, dat geeft alleen maar aan dat je als bedrijf niet de verantwoordelijkheid wil nemen voor je klantgegevens.

[Crim]

Dit is wel erg kort door de bocht, ze kopen deze software niet voor niks in. Deze kennis is bij Blokker niet aanwezig anders hadden ze zelf het platform wel ontwikkeld.

Het is ook belangrijk om rekening te houden met kleinere bedrijven die onder dezelfde regelgeving vallen.

[Groningerkoek]

Het is het bedrijf dat zijn gegevens laat bewaren dat hiervoor de verantwoordelijkheid draagt, het kan gelukkig niet zo zijn dat je als bedrijf elders een service afneemt en daarmee van je verantwoordelijkheid af bent. Wel kan het zo zijn dat je de zorgplicht dusdanig goed bent nagekomen dat er geen verwijtbare gedraging overblijft bij een lek, maar het blijft altijd de verantwoording van het bedrijf.

[twkr18526]

Op zich heeft @GertMenkel een punt. Voor GDPR blijft het bedrijf verantwoordelijk. Ook als ze een andere partij inhuren voor de verwerking volgens mij.

Zou je ook hiervoor een wet moeten optuigen? Is dit niet een data lek die ook gemeld moet worden?

[TheVivaldi]

Dat is vel erg kort door de bocht. Ik koop een auto bij mijn autodealer omdat ik niet weet hoe ik zelf een auto moet bouwen, maar als er iets gebeurt met mijn auto, ben ik nog altijd verantwoordelijk en niet mijn dealer. Dus is Blokker verantwoordelijk voor het platform dat ze gebruiken.

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 04:33]

[GertMenkel]

Ik zeg ook niet dat ze het in-house moeten ontwikkelen, ze kunnen ook een bedrijf inhuren om voor hun de ontwikkeling doen. Zo kunnen ze zelf hun eigen veiligheidseisen toe laten passen en desnoods in het contract vaststellen wat er gebeurt in geval van hacks.

Als een klein bedrijf data lekt, moet dat kleine bedrijf ook zijn infra doorlichten. Met "infra" wordt dan in de meeste gevallen "die webshop en misschien de webmail" bedoeld. Dat zal stukken goedkoper zijn dan wanneer een Blokker met al zijn systemen moet worden geaudit.

Als je voor kleine bedrijven geen uitzondering maakt, blijven die bedrijven ook gewoon lekken. Het maakt voor je klanten niet uit of je gegevens lekken via een groot bedrijf als de GGD of Joops Tegelzetterij BV, je adres- en bankgegevens liggen alsnog op straat. Als kleine bedrijven hun digitale infra niet op orde kunnen krijgen, moeten ze het maar op papier doen en de documenten in een kluis stoppen ofzoiets. Als de risico's eenmaal duidelijk worden, móet men er wel wat aan doen.

Van mij hoeft het ook niet preventief, gewoon achteraf als er eenmaal een (potentieel) datalek gevonden wordt. Waar rook is, is vuur; als je als bedrijf niet eens ongeauthenticeerde, incrementele identifiers in je URL kan pakken, zal er nog wel meer misgaan in je software. Hier gaan tenslotte met één enkel datalek gewoon twee items uit de OWASP top 10 fout.

[Crim]

Ik zeg ook niet dat ze het in-house moeten ontwikkelen, ze kunnen ook een bedrijf inhuren om voor hun de ontwikkeling doen. Zo kunnen ze zelf hun eigen veiligheidseisen toe laten passen en desnoods in het contract vaststellen wat er gebeurt in geval van hacks.

Ze huren toch een bedrijf in voor de ontwikkeling? In dit geval Salesforce, een gerenommeerd bedrijf waarbij ontelbaar veel audits zijn uitgevoerd. Ik verwacht dat Salesforce dit ook heeft gefixt voor ze. Software wordt gewoon steeds complexer waardoor dit soort dingen gebeuren.

Als je voor kleine bedrijven geen uitzondering maakt, blijven die bedrijven ook gewoon lekken. Het maakt voor je klanten niet uit of je gegevens lekken via een groot bedrijf als de GGD of Joops Tegelzetterij BV, je adres- en bankgegevens liggen alsnog op straat. Als kleine bedrijven hun digitale infra niet op orde kunnen krijgen, moeten ze het maar op papier doen en de documenten in een kluis stoppen ofzoiets. Als de risico's eenmaal duidelijk worden, móet men er wel wat aan doen.

Ik bedoel dat kleine bedrijven in de meeste gevallen ook gewoon software inkopen bij een software leverancier. Ze moeten er dan toch vanuit kunnen gaan dat dit goed is als de kennis niet aanwezig is binnen het eigen bedrijf. Anders kan je wel stoppen met ondernemen binnen de huidige digitale maatschappij. Het moet voor iedereen mogelijk zijn om online aanwezig te zijn voor een goede concurrentiepositie.

Als ze zonder kennis zelf iets in elkaar knutselen is het weer een ander verhaal.

Als een klein bedrijf data lekt, moet dat kleine bedrijf ook zijn infra doorlichten. Met "infra" wordt dan in de meeste gevallen "die webshop en misschien de webmail" bedoeld. Dat zal stukken goedkoper zijn dan wanneer een Blokker met al zijn systemen moet worden geaudit.

Hoe moet dat kleine bedrijf de infra van de leverancier doorlichten als de kennis niet binnen het bedrijf aanwezig is? Het maximale wat ze kunnen doen is switchen naar een andere leverancier.

[GertMenkel]

Als ze inderdaad de hele ontwikkeling hebben uitbesteed aan Salesforce, zou uit het contract duidelijk op te maken moeten zijn wie er verantwoordelijk is voor de audits om te zorgen dat klantgegevens niet in gevaar komen. Aangezien de klant van goede trouw moet kunnen kopen, zal dat bij gebrek aan duidelijkheid Salesforce zelf zijn.

Hoe moet dat kleine bedrijf de infra van de leverancier doorlichten als de kennis niet binnen het bedrijf aanwezig is? Het maximale wat ze kunnen doen is switchen naar een andere leverancier.

Een slager die zijn eigen vlees keurt, moet je sowieso niet willen. Die kennis hoeft niet binnen het bedrijf aanwezig te zijn, daar heb je externe partijen die je kan inhuren om dit soort dingen voor je te doen.

Ik vind inderdaad dat je als klant van een softwarepakket ervan uit mag gaan dat de software die je extern koopt of laat samenstellen veilig is. De kosten van zo'n audit verhaal je daarom bij het lekke bedrijf als de fouten daar zitten (aansprakelijkheid afschuiven voor je eigen beunhazerij is natuurlijk onzin), als zo'n audit bij wet verplicht is moet dat wel duidelijk te regelen zijn of ben je heel erg dom geweest bij het aangaan van het contract. Als Microsoft zorgt dat je software onveilig is, mag je Microsoft aanklagen voor de kosten die je daarom moet maken. Als Salesforce zorgt dat je software onveilig is, geldt hetzelfde.

Nogmaals, dit probleem is niet aanwezig bij elke installatie van een Salesforcepakket, daar is maatwerk aan gepleegd. Salesforce verkoopt producten die beginnen als CRM maar zijn uit te breiden tot webwinkels, supoortapplicaties, procesbeheerders, noem maar op, het spul is praktisch oneindig aanpasbaar. Als in jouw maatwerk een beveiligingsprobleem aan het licht komt, moet daar van mij een audit van komen om verdere problemen te voorkomen. Dat de software goed is, is de verantwoordelijkheid van het bedrijf die de data in de software opslaat en aanbiedt.

Een ander bedrijf inhuren kan inderdaad een manier zijn om geen audit van het oude systeem te hoeven doen. Dat is natuurlijk wel mogelijk nog kostbaarder dan de audit vanwege de migratiekosten.

Als de directeur van de Blokker volgende week wordt betrapt op het stelen van geld uit het bedrijf verwacht je toch ook dat er een bedrijf wordt ingehuurd om de schade te onderzoeken en uit te wijzen waarom het mis kon gaan? Als je als bedrijf geen (betrouwbare) accountant hebt, moet je daar ook iemand voor inschakelen of komt de FIOD zelf bij je langs. Als je als klein bedrijf bij een accountant aanklopt (omdat de kennis niet in-house aanwezig is) en daar gaat het is, accepteer je toch ook niet dat men roept "tja jammer, geld is weg, volgende accountant doet het beter, je volgende bestelling komt wel echt aan hoor!"?

Als het om centen gaat, zijn dit soort dingen allemaal redelijk vanzelfsprekend. Dat komt, in mijn ogen, doordat het bedrijf wel wat te verliezen heeft als het gaat om eigen geld maar niet als het gaat om de privégegevens van hun klanten. Hang ergens een prijskaartje aan, en opeens gaan bedrijven er wel wat om geven. Dat is hoe het nou eenmaal werkt in het bedrijfsleven: risico wordt uitgedrukt in euro's vermenigvuldigd met de kans dat het misgaat.

[jpgview]

Het maakt mij niet uit of het bedrijf sokken, dan wel high end stuf verkoopt, als er een datalek is, liggen mijn gegevens op straat.

Als blokker gebruik maakt van Demandware, moeten ze het contract, dat ze afsluiten, maar zo opstellen dat eventuele data lekken, en de kosten (audit), nodig om dat wettelijk terug in orde te krijgen, op dat bedrijf verhaald kunnen worden.

Het lijk me sterk, dat een probleem bij Demandware, alleen bij blokker word opgemerkt, ik zou dan denken dat het bij alle afnemers van diensten bij Demandware een probleem zou zijn. Het probleem was dezelfde dag nog opgelost (zie artikel), dit lijkt meer op een blokker, dan wel Demandware probleem, maar dat is natuurlijk niet vermeld in het tweakers artikel, ook blokker geeft niet aan wat er mis was, heb gezocht op "blokker datalek", maar vind nergens een verklaring wat er precies mis was, en door wie het uiteindleijk gecorigeerd is...

[kftnl]

Denk dat Blokker dit zelf wel gaat onderzoeken nu. Als je wil dat er nooit meer datalekken zijn kun je het beste gewoon alle computers uitzetten, en zelfs dan kan iemand nog een papieren folder meenemen.

[cracking cloud]

Wat amateuristisch. En het is ook geen 1999 meer, het is 2021 en dit soort dingen gebeuren nog steeds!

[Blokker_1999]

* Blokker_1999 onthoud zich van commentaar

[FilipSP]

Haha.....toeval bestaat niet 😉

[Orgel]

Jij was het dus!

[cracking cloud]

haha, dit was echt onbewust

[Blokker_1999]

Kon dat inkoppertje gewoon niet laten liggen

[amx]

Nu ben ik wel benieuwd wat er in 1999 bij de Blokker is gebeurd haha.

[tweaknico]

Er studeren (of vallen omhoog) elk jaar verse programmeurs af.
die zonder enig historisch besef gewoon dezelfde fouten maken als hun voorgangers "want de oude legacy" daar moet je niet mee te maken willen hebben... De nieuwe methode is X... of Y...
met dezelfde kinderziekten als de 10 jaar oude legacy code 10 jaar geleden had, de 20 jaar oude legacy code 20 jaar geleden had, etc.

geschiedenis herhaalt zich.... Er moeten nu even heel veel Click & Collect site uit de grond gestampt worden... ergo over een paar maanden is dit soort zaken geen nieuws meer, maar aan de orde van de dag..? (ik hoop van niet).

[absrnd]

Ik snap niet waarom dit soort domme fouten niet zeer zwaar beboet worden,
Ze gooien de klant met bestel gegevens op de grabbel, die dan eenvoudig dmv fishing e.d. zeer veel geld afhandig gemaakt kan worden.

Hoe dommer de fout, hoe hoger de boete !

[Reactie gewijzigd door absrnd op 24 juli 2024 04:33]

[kodak]

Er zijn geen makkelijke omschrijvingen van dom waar iedereen het mee eens is. Het gaat er ook niet om of het dom zou zijn maar dat het niet is toegestaan en bijvoorbeeld of er genoeg is gedaan om te voorkomen. Helaas lijkt er hoe dan ook nauwelijks toezicht om boetes te geven, dan heeft het alsnog weinig zin.

[tweaknico]

Betaal historie?
Bank rekening? - voor vervolg phishing...
Andere data om social engineering mogelijk te maken?
opvolg mailtje u heeft nu xxx maanden geleden een broodrooster gekocht van het merk X hoe bevalt die u?... met wat malware erbij ... grotere kans dat zo'n mailtje gelezen wordt.

Waarom de PC's van een willekeurige gebruiker niet in een botnet hangen kan altijd handig zijn voor de volgende DDOS. etc. etc.

[BramV]

Tja eenvoudig een random id zoals uuid4: 1077415a-6df0-11eb-9439-0242ac130002 toevoegen en probleem opgelost. Dan moet de hacker al undecillion pogingen doen

Opeenvolgende klant,bestelnummers roepen 'hack me, hack me'.

[willyb]

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.

Nee dus, security by obscurity moet je niet willen.

[BramV]

wat is dan een oplossing?

[willyb]

Authenticatie toepassen op data die niet publiek is.

Dat je 1,2,3 intypt maakt niets uit als de data achter 2 en 3 niet op te halen is als je alleen bij 1 mag.

En met logging kun je dan nog altijd controleren als iemand toch 2 of 3 zit af te struinen.

[Reactie gewijzigd door willyb op 24 juli 2024 04:33]

[TheBoneJarmer]

Mee akkoord. Je kunt gerust in je url een id meegeven maar de back-end moet nagaan of je wel de juiste rechten hebt daarvoor. Eigenlijk zou het zelfs beter zijn als er helemaal nergens een id aan meegegeven werd. Ik ga hier nu van uit dat de id een onderdeel is van de database record dat de primary key voorstelt ofzo. Daar heeft een user nu echt eens niks mee te maken. In geval van een factuur kun je het natuurlijk doen op basis van factuurnummer gezien dat wel info is die voor de user publiekelijk is.

Ik snap dit soort security problemen in elk geval niet. Dat waren de soort fouten die ik maakte toen ik nog 16 was en net een paar maanden in PHP lag te rommelen. Je zou voor een professioneel platform toch op zijn minst mogen verwachten dat het beter wordt gedaan.

[Erkens]

Gebruik van dergelijke UUID's lost slechts een klein deel van het probleem op. Je hebt volgt dan nog altijd het security-by-obsecurity systeem... Dergelijke informatie moet gewoon nooit inzichtbaar zijn met alleen maar een of ander id.

[BramV]

Nee maar het eenvoudig hacken dmv vervangen bestelnummer is wel te voorkomen in ieder geval ?

fece5a97-202b-477b-a65b-3082b1571df6
klant 1233
5280057a-1509-4f5f-bd7d-7d418c5d1719
bestel 5456
SHA256
BE5B566172B90B78228DC364CAD8CA49B85EE5C701AB6452112E357DC9C738BD

[Erkens]

Dan nog is de data te achterhalen met alleen een URL, dus gewoon authenticatie toepassen.
Als er echt een use-case is om bestelde gegevens zichtbaar te maken met alleen een URL, dan alleen als er geen persoonsgegevens of tot een persoon herleidbare gegevens zichtbaar zijn op die URL. Waarbij je dat dus ook in de toekomst moet bijhouden dat er niet per ongeluk iets in die view komt, kortom, voeg gewoon die extra authenticatie toe, dat scheelt een hele hoop problemen nu en in de toekomst.

[BramV]

Ik heb het over ingelogde klanten. Bij Blokker ging het ook om ingelogde klanten met authenticatie maar schijnbaar zonder aanvullende check of order/klantnummer bijelkaar horen. Random nummers geven in ieder geval heel veel vertraging voor hackers en bij honderduizenden verzoeken moet het toch opvallen en sowieso moet je rate limiting toepassen.

[pizzafried]

dan nog moet je voorkomen dat de klant met een aanpassing in de url de bestelgegevens van een ander kan zien. maw, je moet niet met een UUID gaan klooien, da's mooi spul en vertraagt wel, maar je moet gewoon in je code een check uitvoeren, mag de ingelogde klant bij bestelgegevens met het id 123.

Jou idee is het zelfde als een groot opslagcomplex waarbij random opslagruimtes de deur van het slot hebben. De deuren moeten gewoon op slot en de klant moet alleen de sleutel hebben van de opslagruimtes waar ze voor betaald hebben.

iig kun je beter het probleem verhelpen dan iets in te bouwen dat het vertraagd (en vermoedelijk ook veel meer werk is)

[Reactie gewijzigd door pizzafried op 24 juli 2024 04:33]

[BramV]

Ik zeg alleen maar dat je niet met bestelnummer moet werken als id maar een versleutelde combinatie. Op die manier is het 'eenvoudig' ophogen van een volgend nummer niet te hacken.Het is een van de vele extra's die je moet toepassen en kost qua opslag en berekening geen enkele moeite, maar maakt het de hacker wel extra moeilijk en is gewoon een extra beveiliging. Het kan altijd mis gaan, overal. Nu was het bij Blokker wel te kinderlijk eenvoudig.

[Erkens]

Kortom, als er gewoon een check was geweest tussen ingelogde gebruiker en of de betreffende bestelling bekeken mog worden was het probleem opgelost. Geen rare dingen moeten doen met "random" id's.

Overigens, hoe wil je dit dan gaan doen voor facturen? Die zijn bij wet verplicht om volgnummers te gebruiken, als je er eentje mist gaat de belastingdienst vragen stellen...

[bython]

720.000 verschillende bestellingen mee gemoeid zijn, hoewel er niet specifiek wordt vermeld hoe men tot dat getal komt

Je giet het URL aanpassen in een scriptje met een counter die ziet of je een page not found terugkrijgt of niet, en dat laat je los gaan op de site, et voila dan heb je het cijfer.
Of heb ik het mis?

[Accretion]

En voor elke 200, parse je de data en zet je in een databaseje.

[Scale]

WeFashion had precies hetzelfde probleem, Heb het bij ze gemeld en ze hebben het gefixed.
Heb niet eens een bedankt emailtje ontvangen van ze... Beetje jammer weer.

[Mars Warrior]

Logisch, die gebruiken hetzelfde platform - Demandware dus - als de Blokker

[DynalogicalMe]

Dit is simpelweg op te lossen door bijvoorbeeld een check te doen op het user_id voordat de view wordt terug gegeven. Dit is in mijn ogen toch echt wel één van de meest standaard dingen tegenwoordig en begrijp dan ook totaal niet waarom sommige grote organisaties dit, blijkbaar, nog steeds niet hanteren..

[deorder]

Het liefst op row level van de achterliggende database.

[HKLM_]

Mailtje sturen dat je gegevens mogelijk gelekt zijn is zeker teveel gevraagd voor Blokker...