Gegevens deel Bol.com-klanten waren toegankelijk via sql-injectie

Persoonsgegevens van 84.000 Bol.com-klanten waren toegankelijk via een lek in de site van een externe partij waar Bol.com mee samenwerkte. Het ging om een kwetsbaarheid voor sql-injectie. De gegevens zijn volgens Bol.com niet misbruikt.

De webwinkel heeft de getroffen klanten zelf geïnformeerd, blijkt onder meer uit een topic op GoT. Het gaat om 84.000 klanten die meededen aan de 'kennismakingsactie' Warm Welkom.

De klantgegevens stonden in een database van een externe partij waar Bol.com mee samenwerkte voor de actie, zegt Bol.com-directeur Daniel Ropers tegenover Tweakers.net. Van de klanten konden naam, geslacht, e-mailadres en geboortedatum worden achterhaald; betaalgegevens waren niet toegankelijk.

"We hebben gisteravond klanten geïnformeerd die eind vorig jaar hebben meegedaan aan de marketingactie", zegt Ropers. "Via het bureau dat de actie heeft verzorgd waren gedurende een bepaalde periode gegevens toegankelijk." Het lek zou in ieder geval vorig jaar zomer al in de software hebben gezeten. Sinds februari waren de gegevens versleuteld. Volgens Webwereld gaat het om een lek in de tool amfphp.

Bol.com ondernam actie nadat het bedrijf werd getipt. Ropers: "Buiten de tipgever is er niemand bij de data geweest; er is niets uitgelekt. We zijn de tipgever zeer dankbaar." Hij benadrukt dat Bol.com zelf niet is gehackt, maar zegt ook dat het bedrijf desondanks zijn verantwoordelijkheid wil nemen. "Voor alle bedrijven waar we mee samenwerken hebben we security-checklists. Daar moeten we dus een stap verder in gaan."

Reacties (45)

[Alfredo]

Ik betwijfel ten zeerste of het een bug was in amfphp, maar eerder een developer die de documentatie niet gelezen heeft. In al die jaren dat ik met amfphp werk, ben ik nog geen beveiligingsproblemen tegengekomen die SQL Injection mogelijk maken.

Wat bijvoorbeeld wel kan, is dat de ontwikkelaar de gehele map van amfphp geüpload heeft. Daar zit ook een debug tool in, namelijk de Service Browser. Dit is een interface waarmee verschillende services opgeroepen en uitgevoerd kunnen worden. De tool toont alle queries en laat je toe ze 1 voor 1 uit te voeren, met parameters indien nodig.
Heb je bijvoorbeeld in je service de query "SELECT * FROM users;" (selecteer alle velden van de gebruikerstabel), zal de tool een lijst van alle 84000 gebruikers teruggeven. Webwereld omschrijft amfphp ook als "een tool waarmee via de browser door data in een database kan worden gescrolled". Daarmee beschrijven ze niet amfphp zelf, maar wel de eerder genoemde Service Browser.

Als je de documentatie leest, staat daar duidelijk in dat je deze map niet moet uploaden naar productieomgevingen. Verder moet je ook nog PRODUCTION_SERVER op false zetten, zodat debug messages en remote tracing uitgeschakeld worden. Bij de oudere versies ( < 1.9) staan die standaard ingeschakeld.

[leenm]

Sql-injectie, hoe moeilijk is dat nou te voorkomen? Je zou van een professional beter verwachten.
Volgens mij moeten we 'privé data toegankelijk via sql-injectie' ook maar eens strafbaar maken ipv ons druk te maken over een (legale) ddos. Wie stemt voor?

edit: natuurlijk niet de hacker straffen, maar de verantwoordelijke voor de privé gegevens.

[Reactie gewijzigd door leenm op 26 juli 2024 11:12]

[Anoniem: 445717]

En hoe wil je die wetgeving gaan neerpennen dan? Het gaat hier om een consument die opmerkt dat SQL injectie mogelijk is, voert het uit om te testen en/of als 'proof of concept' en speelt deze informatie weer door naar Bol.com; welke op zijn beurt het lek weer (laat) dichten.

Ga je hier een specifieke wetgeving over schrijven dan criminaliseer je dus ook deze 'white hat' hackers, en dat lijkt me vrij onwenselijk. Zeker aangezien de meeste black hats zich echt niets aan zullen trekken van zo'n verbod.

Vergeet niet dat een uitzondering voor dergelijke white hat toepassingen erg lastig te schrijven is. Je zult namelijk erg concreet en specifiek moeten zijn als wetgever, iets wat helaas tot op heden zelden goed uit heeft gepakt op het internet. Auteursrechtwetgeving om maar even iets te noemen. Of wat dacht je van het patentenrecht. En aan het einde van de rit is het dan ook altijd nog de rechter die een interpretatie van die wetgeving moet maken. Krijgen we dan ook Chris Hensen-praktijken, dat een white hat situatie als deze een boete van een paar tienduizend euro kan verwachten? Nee, dank je.

[leenm]

De tipgever hoeft niet strafbaar te zijn, die verdient een compliment. Het gaat mij erom dat bedrijven veel te laks zijn met de privégegevens van de consument. Bol.com of externe partner verdient punishment. En hoe dat dan precies geregeld moet worden, tja, ik zal niet ontkennen dat het erg lastig wordt om dat op een goede manier te regelen.

[Petertyuh]

Dat een tipgever een compliment verdiend, daar ben ik het helemaal mee eens, echter gebeurt dat zelden. Kijk maar eens hoe het met de meeste klokkenluiders afloopt.

Ze (zowel overheden als bedrijven) willen het liefste iedereen verplichten om alles maar te melden als het het zonlicht niet kan verdragen, maar een vangnet daarvoor maken doen ze niet. Als er dan plots iets openbaar over hun gemaakt wordt, dan moet die persoon gelyncht worden (en het liefste op alle mogelijke manieren). En de overheid doet hier net zo hard aan mee, zo niet harder.

[watercoolertje]

Ga je hier een specifieke wetgeving over schrijven dan criminaliseer je dus ook deze 'white hat' hackers, en dat lijkt me vrij onwenselijk. Zeker aangezien de meeste black hats zich echt niets aan zullen trekken van zo'n verbod.

Hij bedoelt ook niet de hacker maar het bedrijf wat zich laat hacken op de meest simpele manieren!

[Niemand_Anders]

Misschien is het tijd dat er naast de ISO 9001 certificatie (klant ondersteuning / klacht afhandeling) er ook een ISO standaard komt welke specifiek op development bedrijven is gericht en waarmee een aantal garanties wordt afgegeven over de manier waarop een bedrijf werkt.

Ook dit bied natuurlijk geen garanties, maar een bedrijf welke aan de ISO standaard wil voldoen (zorgt immers voor meer klandizie) zal aan dit soort punten meer aandacht besteden. Het mooie van de ISO 9001 standaard is dat deze ook bevroren (suspended) en zelfs ingetrokken kan worden.

Bij pitches zou bijvoorbeeld de ISO standaard als vereiste kunnen worden opgenomen.

Nu doe ik zelf een ICT studie aan de Open Universiteit, maar nog nooit heeft men mij gewezen op de OWASP top 10 welke aangeeft wat de meest voorkomende fouten (tekortkomingen) zijn bij online applicaties. SQL Injection staat als sinds het begin op nummer 1 op de voet gevolgd door XSS injections. En de docenten vertellen wel netjes dat je input en output moet controleren, maar als je bij een propedeuse het niet doet krijg je alleen een opmerking dat je het voortaan wel moet doen. En zo gaat dat bij veel meer punten en je moet het wel heel erg bond maken voordat je de module opnieuw moet doen..

[sys64738]

Ja, dit was ook meteen mijn gedachte toen ik de kop van het verhaal las. Hoe lang moet dit soort beunhazerij nog ongestraft door kunnen gaan?

De politiek is best druk bezig een inhaalslag te maken op het gebied van internet. Daarnaast zijn er genoeg andere bedrijfstakken en situaties waarbij vergelijkbare nalatigheid allang strafbaar is.

Probleem is natuurlijk zoals altijd op het internet weer dat de Nederlands wet alleen iets te zeggen heeft over activiteiten binnen NL. Dus zodra je je server ergens anders hebt staan of je geen NL bedrijf bent, wordt het volgens mij al lastig om sancties op te leggen.

@datafeest: Een professioneel framework met SQL Injectie lekken? Das een grap zeker? En nee, blijkbaar is dat geen goede keuze geweest. Ook het niet updaten is erg slordig maar dit soort grove fouten mag natuurlijk nooit in zo'n framework zitten.

[Reactie gewijzigd door sys64738 op 23 juli 2024 22:35]

[kamerplant]

Hoezo beunhazerij? Het gebruikte framework is een professioneel open source framework, dat is toch een prima keuze op zichzelf? Dat de update niet tijdig is geïnstalleerd is wel te verwijten natuurlijk.

[SuperDre]

Zal nooit kunnen, want dan moet je de wet zo maken dat elke nieuwe vulnerability afgevangen kan worden, doe je dit niet, is de wet nutteloos... Er zijn vele malen meer manieren om binnen te dringen en gegevens te jatten..

Maarja, 'beunhazerij' komt in de IT heel HEEEEEEL vaak voor, ook bij de zeer gerenomeerde bedrijven.. Want wat voor jou als developer bekend is als een vulnerability wil nog niet zeggen dat dat voor anderen ook is (zeker voor een beginner), vergeet bv niet dat 80% van de .NET developers helemaal niet eens weten dat je hun applicaties gewoon compleet kunt rippen door gebruik te maken van een simpele tool en dus zo een 'cloon' kunt maken, of zo simpel de beveiliging er uit kunt rippen.. en dat is nog maar een heel simpel voorbeeld..
Tja, SQL-injectie is wel de meest bekende en zou je zelfs als beginnende developer redelijk moeten kennen, maar iedereen maakt wel eens fouten, zeker als het 'gister' klaar moest zijn van de klant...

[Countess]

dus jij wil dat bedrijven ipv dat ze naar buiten komen met dit soort informatie alles angstvallig verborgen houden en de hacker zwijg geld gaan betalen waardoor het vinden van dit soort lekken financieel heel aantrekkelijk kan worden?

wat dat zou het effect zijn van dat soort wetgeving.

[alienfruit]

En ik maar denken dat AMFPHP een open-source alternatief is om gebruik te maken van Flash Remoting.

[Anoniem: 445717]

Verre van. amfPHP is een kun je meer zien als een library om meerdere protocollen en devices te ondersteunen. Als je bijvoorbeeld een tablet app hebt (Objective-C), een smartphone webpage (HTML, PHP, jQuery) en een conventionele website (weer andere HTML/PHP/jQuery/AJAX/whatever als de smartphone webpage) dan ben je voor elke toepassing apart aan het programmeren. In plaats van dat je voor elk device aparte services in elkaar moet gaan flansen verbind je simpelweg met amfPHP, die er op zijn beurt weer voor zorgt dat de verzonden data juist wordt verwerkt. En die ook platform-afhankelijk weer eigen data terugstuurt.

Zie het als een bibliothecaresse. Een psycholoog en een hersenchirurg moeten beiden wat over het menselijk brein weten en willen een boek hebben. De bibliothecaresse interpreteert wat ze nodig hebben, en geeft hun, weliswaar, hetzelfde boek; maar de psycholoog krijgt mee dat 'ie bladzijde 315 t/m 412 nodig heeft, en de hersenchirurg bladzijde 450 t/m 519.

[Anoniem: 241683]

Dat is inefficient... Meer data terug krijgen dan dat je nodig hebt?

[tweakerss]

In dit geval worden de bladzijdes er waarschijnlijk uitgescheurd voordat ze worden verstuurd.

Ik kreeg gisteren ook een emailtje, deze wilde ik naar Tweakers op sturen maar het was alleen mogelijk om een link te sturen dus heb het maar laten gaan.

[Rafe]

GR FAQ en Beleid "Als je geen linkje hebt - bijvoorbeeld omdat je nog niet online hebt gezet dat je koude kernfusie aan de praat hebt - mag je ook een neplinkje invullen."

[PcDealer]

Of naar redactie@ sturen.

[bantoo]

Voor de verandering bedankt iemand een keer de persoon die hun vertelt dat er wat bij een bedrijf fout zit in plaats van hem proberen als dader te markeren.

[Iftert]

Dit komt ook omdat hij er waarschijnlijk niets met die gegevens gedaan heeft natuurlijk. Maar netjes dat BOL hier al zelf contakt opeemt met de getroffenen. al met al, lullig dat de gegevens zijn gelekt. maar op een prima manier is er mee omgegaan

[robvanwijk]

Voor de verandering bedankt iemand een keer de persoon die hun vertelt dat er wat bij een bedrijf fout zit

En ze informeren uit eigen beweging klanten. En ze doen er iets aan voordat het (bij mijn beste weten) in de publiciteit is gekomen. En ze hebben (zelf de indruk dat ze) genoeg logs hebben om na te gaan of iemand anders hier misbruik van heeft gemaakt.
Natuurlijk zou het beter geweest zijn als er geen lek was geweest, maar verder lijkt me dat ze het keurig hebben opgelost (kunnen de nodige andere bedrijven nog best wat van leren!).

[BlackMage]

Ik ben geen beveiligingsexpert, maar ben ik de enige die het raar vind dat er nog steeds lekken bestaan die doormiddel van SQL-injectie mogelijk zijn?

Het is zo'n breed bekende methode dat met één regeltje code af te vangen is.

[Zoijar]

Legacy code... je gaat geen honderdduizenden regels vervangen die het nog gewoon (goed) doen.

[Blokker_1999]

Het is af te vangen zolang het op een correcte manier gebeurd. We zijn mensen en maken allemaal fouten.

[kamerplant]

Het is ook wel moeilijk voor een organisatie als bol.com om alle partners waarmee data wordt gedeelt tot in het detail op securery te controleren. Misschien hebben ze wel 100 partners, ongetwijfeld zijn er nog wel een aantal die ergens een zwak punt in de beveiliging heeft zitten.
Maar het is alsnog natuurlijk niet goed dat dit is gebeurd. Maar hoe had bol.com dit echt kunnen voorkomen zonder alle partners tot in het kleinste detail met regelmaat door te lichten?

[BounceCloud]

Ja, dit had Bol.com moeten voorkomen, dat het via een partner loopt is mijns inziens geen excuus.
Partners die jouw eigen klantgegevens beheren zijn niet zomaar partners; zij beheren privacy gevoelige en daarmee waardevolle informatie. Als je dit uit handen geeft aan een derde partij, moet je er wel zeker van zijn dat zij goed omgaan met jouw informatie.

Ik ben het met je eens dat het voor Bol.com moeilijk is om hierop controle uit te voeren omdat zij een derde partij zijn. Maar; het mag geen excuus zijn om zich achter te verschuilen. Dergelijke informatie uit handen geven aan een derde partij biedt risico's; simpelweg omdat je hun infrastructuur niet 1:1 kent. Dat wist Bol.com vooraf, of had dit additionele risico kunnen inschatten.

Desalniettemin vind ik het wel netjes van Bol.com dat klanten proactief gereageerd heeft naar haar klanten toe. Dit gebeurt nog wel eens anders.
Professioneel dat ook de "ontdekker" bedankt is. Mijns Inziens ook terecht; hij heeft de informatie gemeld zonder hier zelf voordeel mee te doen.

[AW_Bos]

De klantgegevens stonden in een database van een externe partij waar Bol.com mee samenwerkte voor de actie

Dit verbaast me. Waarom zou een samenwerkend bedrijf een kopie van een deel van de klant-gegevens willen hebben? Kon Bol.com geen API in gebruik stellen om de nodige data bij hunzelf vandaan te halen voor op die website?

[ravenger]

Nou, dat is heel simpel uiteraard; als Bol.com die derde partij gebruikt om klanten te werven, dan is de database met gegevens van de derde partij. Kennelijk weten ze van die derde partij welke klanten op het aanbod zijn ingegaan, of hebben ze een check gedaan te kijken of er email adressen overeen komen ofzo (ik weet ook niet hoe dat gaat).

[bouvrie]

Wat ik mij afvraag is hoe streng/complex de versleuteling van de gegevens is. Is er een salt gebruikt, of zijn versleutelde wachtwoorden alsnog makkelijk te kraken met een rainbow table?

*edit*

Blijkbaar is cross-site posten niet echt slim: tweakers.net vermeldt niets over wachtwoorden, terwijl op fok te lezen is:

De wachtwoorden waren versleuteld en niet toegankelijk.

Laat dus maar.

[Reactie gewijzigd door bouvrie op 26 juli 2024 11:12]

[Countess]

er staat bij tweakers precies bij wat wel toegankelijk was. de rest dus niet.

[pep75]

De gegevens zijn nóg niet misbruikt.....Slaan die jongens even op en over paar weekje....Bingo...

[Ukijaki]

"Van de klanten konden naam, geslacht, e-mailadres en geboortedatum worden achterhaald" --> alsof dat allemaal niet al te achterhalen is op Facebook/linkedin/twitter etc...

[Anoniem: 424778]

Jawel, maar nu hebben ze in eens 84000 van die gegevens zonder er moeite voor te doen

[AW_Bos]

Je denkt toch wel dat de serverlogs al bekeken zijn, en of iemand al een SQL-injection heeft uitgevoerd?

[theduke1989]

that sucks, denk je shopt redelijk veilig, niet dusss
Ach ja, overal is dat zo..

[ashemedai]

Lekkere knee-jerk reactie. Bol zegt zelf toch al: "De klantgegevens stonden in een database van een externe partij waar Bol.com mee samenwerkte voor de actie, zegt Bol.com-directeur Daniel Ropers tegenover Tweakers.net. Van de klanten konden naam, geslacht, e-mailadres en geboortedatum worden achterhaald; betaalgegevens waren niet toegankelijk."

_{Edit: nadruk}

[Reactie gewijzigd door ashemedai op 26 juli 2024 11:12]