Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 45, views: 21.827 •
Submitter: digitweak

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.

Bol.comDe 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)

En ik maar denken dat AMFPHP een open-source alternatief is om gebruik te maken van Flash Remoting.
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.
Dat is inefficient... Meer data terug krijgen dan dat je nodig hebt?
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.
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." ;)
Of naar redactie@ sturen.
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.
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
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!).
Daniel Ropers tegenover Tweakers.net. Van de klanten konden naam, geslacht, e-mailadres en geboortedatum worden achterhaald; betaalgegevens waren niet toegankelijk.
Hoe weinig ook het is altijd teveel, als er gegevens lekken. Mag niet voorkomen. Nu ging het nog goed en werd eea op tijd ontdekt en gedicht.
Maar een volgend keer hoeft dat niet zo te zijn
Ja, er valt veel voor te zeggen maar echt 100% dicht is moeilijk, niet onmogelijk.
Soms is er een hacker nodig om de puntjes op de I te zetten en gelukkig zijn er nog genoeg mensen die op zoek zijn naar kwetsbaarheden om deze vervolgens te melden samen met de instructies om het te verbeteren.

Bol.com zal hier sterker uitkomen en dat is positief. Dat SQL-injectie hier mogelijk was vind ik wel slecht want inmiddels moet het nu wel duidelijk zijn dat dit onmogelijk moet worden gemaakt.
Dat is onmogelijk, je zult toch zelf ook toegang moeten hebben tot de gegevens, en daarmee is er altijd een kans dat ook anderen er toegang toe kunnen krijgen.
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 2 juli 2012 08:46]

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.
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.
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.
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!
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..
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 2 juli 2012 09:40]

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.
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...
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.
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.
Het is af te vangen zolang het op een correcte manier gebeurd. We zijn mensen en maken allemaal fouten.
Legacy code... je gaat geen honderdduizenden regels vervangen die het nog gewoon (goed) doen.
De gegevens zijn nóg niet misbruikt.....Slaan die jongens even op en over paar weekje....Bingo...
"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...
Jawel, maar nu hebben ze in eens 84000 van die gegevens zonder er moeite voor te doen
Je denkt toch wel dat de serverlogs al bekeken zijn, en of iemand al een SQL-injection heeft uitgevoerd?
toch netjes dat Bol de tipgever hiervoor bedankt en niet zoals allerlei andere sneue bedrijfjes naar de politie stapt, of niets zeggen
that sucks, denk je shopt redelijk veilig, niet dusss
Ach ja, overal is dat zo..
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 2 juli 2012 09:18]

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

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneAsus

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013