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. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 35 reacties

Een beveiligingslek in de website van onderzoeksbedrijf Simstore maakte het mogelijk om op accounts van Motivaction-panelleden in te loggen. Daardoor konden privégegevens worden bekeken en konden cadeaus worden besteld.

Tweakers.net-lezer Thijs ontdekte het probleem. Motivaction werkt voor sommige enquêtes samen met het bedrijf Simstore, dat onderzoek doet naar e-commerce. Daarbij programmeert Simstore enquêtes, die aan panelleden van Motivaction worden verzonden. Aan het eind van de enquête worden de panelleden doorgestuurd naar Stempunt.nu, de enquête-site van Motivaction, waar ze worden beloond voor hun deelname.

Bij die koppeling ging echter iets mis; Motivaction authenticeerde de gebruiker niet zelf, maar liet de controle over aan Simstore. Dat bedrijf controleerde echter evenmin of gebruikers bevoegd waren. Door de id van een enquête aan te passen, kon deze worden ingevuld namens een andere gebruiker. Dankzij het gebrek aan verdere controle, was het opgeven van een ander id voldoende om op de Stempunt-website als een ander in te loggen. De id's waren opeenvolgend, waardoor het verhogen van het eigen nummer met een of twee cijfers vaak voldoende was om in te loggen als een andere gebruiker.

Eenmaal ingelogd konden gegevens worden bekeken en gewijzigd, waaronder adresgegevens, maar ook een indicatie van het inkomen en opvattingen over bepaalde zaken. Ook konden in de cadeauwinkel van Stempunt.nu items worden besteld met het puntensaldo dat panelleden hadden verdiend door enquêtes in te vullen.

Directeur Pieter Paul Verheggen van Motivaction laat weten het beveiligingsprobleem te betreuren. "Dit is nooit onze bedoeling geweest", aldus Verheggen. "Dat wij geld verliezen doordat cadeaus kunnen worden verzonden is één ding, maar dat privégegevens zijn in te zien is erg vervelend." Het bedrijf heeft Stempunt.nu een kwartier na de melding van Tweakers.net offline gehaald, hoewel het nog enige tijd mogelijk was om enquêtes in te vullen. Inmiddels is de koppeling tussen Motivaction en Simstore stopgezet, totdat de beveiligingsproblemen zijn opgelost.

Verheggen schat dat de accounts van enkele honderden panelleden te misbruiken waren, maar kan geen precies aantal noemen. Het lukte Tweakers.net echter om met diverse willekeurig gekozen id's in te loggen op accounts. Simstore verwijst voor commentaar door naar Motivaction.

Stempunt.nuStempunt.nuStempunt.nuStempunt.nuStempunt.nuStempunt.nu

Moderatie-faq Wijzig weergave

Reacties (35)

Ik programmeer zelf ook en dit soort foutjes zijn echt geen fouten.. Dit is gewoon luiheid geweest van iemand die dit even snel werken wilde hebben.
Heel slecht. Mooi dat ze zo snel actie ondernemen maar nog vind ik een kwartier erg lang :)
Ik vind een kwartier wel heel snel hoor, dat is even heel snel intern overleggen hoe aan te pakken en dan direct actie nemen.
En ze nemen het wel serieus in plaats van te doen of het om niets boeiends gaat zoals die bedrijven die pas in het nieuws waren.

[Reactie gewijzigd door Mr_x007 op 4 maart 2011 17:22]

Inderdaad. Bovendien is het net iets te makkelijk om de programmeur in kwestie de schuld te geven.

Mijn schoonvader zegt als iemand kritiek op de uitvoering van werk heeft, altijd: Wie werkt maakt fouten. De steek onder water is dat alleen als je geen zak uitvoert je ook geen fouten maakt.

Bij zo'n website komt een hele keten van mensen aan te pas. Je hebt de eigenaars / aandeelhouders van het bedrijf. Bij grotere bedrijven heb je dan iemand (directeur) die het dagelijks reilen en zeilen runt. Dan heb je een project leider die dit ene project aanstuurt. Dan heb je een team architect die de grote lijnen uitzet, de programmeur die het daadwerkelijk uitvoert en de tester die het test en goedkeurt.

Al deze mensen dragen een deel van de verantwoordelijkheid en de mensen hoger in de keten meer dan die ene programmeur, niet minder.

Kan natuurlijk dat het een eenmasnbedrijf is en al deze rollen worden gespeeld door één en dezelfde persoon... maar ik vermoed van niet. ;)
Vergeet niet dat het ook een kwestie van tijd kan zijn. Heb zelf dagelijks met klanten en programmeurs te maken en tussen die 2 bestaat een enorm spanningsveld.

Klanten willen alles NU en goedkoop. Hanteer zelf altijd de gouden driehoek: Prijs - kwaliteit - snelheid. Klant mag 2 v/d 3 kiezen. En lage prijs + snelheid daar doe ik niet aan mee.

Vaak gebeurd dat wel. Dus lage prijs + snelheid = k*t kwaliteit
En als jouw bedrijf zegt 'slechte kwaliteit, daar doen wij niet aan mee' dan stapt de klant over naar je concurrent die er wel aan mee doet. En krijg je dit soort sites. Daarom is ook niet alleen die ene programmeur schuldig.

Wat we nodig hebben is een controlerende instantie (College Bescherming Persoonsgegevens?) die echt actief jacht gaat maken op dit soort privacy lekken en ook decht dikke boetes uitdeelt. En bijvoorbeeld een blacklist bijhoudt van bedrijven die het met de privacy niet zo nauw genomen hebben. Zo krijgen die klanten die alles alleen maar snel en goedkoop willen een extra motivatie erbij. Boete van het CBP ontlopen.
Jij weet helemaal niet hoe het gegaan is binnen dat bedrijf. Misschien heeft programmeur wel aangegeven dat het product nog niet af was en dat er nog authenticatie ingebouwd moest worden, maar had het bedrijf daar geen oren naar omdat dat bijvoorbeeld te duur zou worden.

Dat maakt het natuurlijk niet minder slordig van het bedrijf, maar het simpelweg afschuiven op een luie programmeur is wel erg kortzichtig.
De programmeur moest nog zijn bed uit kruipen :P Ik vind een kwartier best snel :P Hehe. Nouja ik geloof er gerust in dat het luiheid is geweest ja. De mensheid is nou eenmaal liever lui dan moe :P
Anno 2011 is dit gewoon schandalig. Als ik dit verhaal zo lees hebben beide partijen niet nagedacht over het beveiligingsaspect. Geen van beide partijen heeft zich er druk om gemaakt en afspraken gemaakt. Dit is zowel business als de technici te verwijten.

Dan werk je met zulke vertrouwelijke gegevens en dan ga je zo met beveiliging om. Dit is niet goed te praten. Ik zou ook graag zien dat als bedrijven dit soort beveiligingsfouten maken zij.

1. dit moeten melden bij een instantie
2. zij automatisch een boete moeten betalen.

Zolang we dat niet doen kunnen we wekelijks dit soort berichten lezen.
Ik denk dat het te makkelijk is om te zeggen dat iemand dan automatisch een boete moet betalen.

Zoals Dijkstra zei: Testing shows the presence, not the absence of bugs.

Dus dat zou betekenen dat veel mensen uiteindelijk een boete zou moeten betalen, naarmate de hoeveelheid mensen die de software gebruiken.

[Reactie gewijzigd door Meijuh op 5 maart 2011 09:43]

Nee,

Dat zou betekenen dat: mensen beter moeten nadenken voordat ze iets op het internet smijten.

We accepteren ook geen software bugs die vliegtuigen doen neerstorten.

Als dit betekent dat in het begin veel bedrijven een hoge boete moeten betalen, so be it. Dat heet leergeld.

Hoe gaan die bedrijven anders leren dat je privacy gevoelige informatie fatsoenlijk moet beschermen, dat dit in hun belang is?

Een berichtje op nu.nl of tweakers.net is snel weer vergeten.
je accepteert het misschien niet, maar die fouten in vliegtuigen zijn er wel. En komen soms pas aan het licht als het te laat is. Mensen maken nu eenmaal fouten, en mensen die beweren dat ze geen fouten maken... Welja je kent het gezegde.

Een dokter maakt ook fouten, een chirurg ook, dus waarom zou een programmeur (als die überhaupt al de schuldige is (organisatie, werkgevers, etc etc)) die niet maken?

Jij krijgt ook niet bij de minste fout een boete of vermindering op je loon?

[Reactie gewijzigd door white modder op 5 maart 2011 14:43]

Jij krijgt ook niet bij de minste fout een boete of vermindering op je loon?
Deze opmerking toont aan dat je het punt mist.

Ik heb het niet over het minste of geringste. Of je moet een neerstortend vliegtuig of het prijsgeven van privacy gevoelige informatie het minste of geringste noemen?

Denk jij dat er geen consequenties zijn als door een software fout een vliegtuig neerstort?

Het punt is juist dat je weet dat mensen fouten maken en je daarom processen inricht om dat zoveel mogelijk te ondervangen.

Daarnaast is uit bovenstaand verhaal goed op te maken dat niemand van de 2 partijen zich blijkbaar druk maakte of verantwoordelijk voelde voor security.

Dit is nalatigheid, dit soort fouten zijn prima te voorkomen.
Het punt is gewoon. Software testen is moeilijk. Zie ook: http://citeseerx.ist.psu....10.2513&rep=rep1&type=pdf

Zelfs al bouw je een formele specificatie van een stuk software dat in een Boing 747 draait. Je kunt niet garanderen dat de implementatie ervan in zijn geheel voldoet aan de specificatie.
Ook jij ziet het probleem niet. Het gaat niet om testen. Want deze mensen hadden niet geweten wat ze hadden moeten testen.

Het is al fout gegaan op het moment dat geen van de partijen zich druk heeft gemaakt over security.

Er is overduidelijk geen risicoanalyse gemaakt. Toen is het al fout gegaan. En dit is het resultaat.
Meestal hoor je bij zo'n lek iets over controle, hoeveel accounts mogelijk aangepast zijn. Of een melding op de site (Motivaction, Stempunt: NIETS)

http://www.stempunt.nu/stempunt/privacy.asp
Bescherming van persoonsgegevens
Privacy en de bescherming van persoonsgegevens zijn van groot belang voor StemPunt. Daarom voert StemPunt een streng privacy-beleid.


Niet zo streng kennelijk.
Ondertussen zie ik wel een melding op de homepage: http://www.motivaction.nl...leem-vragenlijst-opgelost . Geen idee sinds wanneer deze melding er staat, maar wel goed dat dit niet doodgezwegen wordt. Denk dat er best wat partijen zijn die dit heel anders aangepakt zouden hebben.

[Reactie gewijzigd door spone op 4 maart 2011 19:48]

Het is helemaal verkeerd dat dit zo liep. Maar aan de andere kant, hebben ze wel erg snel gehandeld door binnen een kwartier de site plat te gooien. Kan me zo voorstellen dat er tig andere bedrijven zijn die daar langer over doen.
Allemaal reacties op basis van "programmeurs zijn de fout". Je moet nooit zomaar de schuld erbij leggen natuurlijk wil dat niet zeggen dat het niet zo kan zijn maar waar ik tijden gewerkt heb was het altijd dat er druk op je zat en testen mochten we nooit of het werd door een HTMLer gedaan die dus geen verstand ervan had.

Vind dat zo'n bedrijf die een product op de markt wil zetten wel moeite moet doen om te testen en niet half werk online zetten daar ben ik het helemaal mee eens. Door deze reclame word je naam er niet beter om. Kwartier voor het ingrijpen wel snel voor een bedrijf maar dan dat moet ook wel als er al 100de mensen slachtoffer zijn geweest/
Testen moet je ook laten uitvoeren door iemand zonder verstand van zaken. Als die dan zegt dat jouw product / website dan goed is, dan moet iedereen er toch mee om kunnen gaan?
Motivaction werd onder andere door de KvK gebruikt om de dienstverlening te inventariseren.
gelukkig zijn er nog mensen die een lek niet gelijk exploiten :)

op die manier wordt t internet toch weer een stukje fijner :)
Tsjah lekker makkelijk. lekker geen controle jongens dat kost alleen maar tijd :x. Nouja zulke foutjes zullen altijd blijven bestaan. Programmeren is een menselijke taak...

Overigens vind ik het best goed ingegrepen in een kwartier de site down en naar oplossingen zoeken. Hoeveel zullen er wel niet zijn. Die pas later actie ondernemen ?:P

@ tweaktubbie hieronder.
Ja daar heb je wel gelijk in! is niet zo heel streng :P Maar zoals ik gezegd heb fouten zullen altijd gemaakt blijven worden. Waarschijnlijk omdat men sowieso al weinig van dat soort diensten gebruik maakt word er geen melding gemaakt. Het zou alleen maar meer mensen afschrikken. En het is tenslotte opgelost toch ? :)

[Reactie gewijzigd door Clifdon op 4 maart 2011 17:14]

Hallo zeg; het is 2011, welke serieuze web-programmeur houdt geen rekening met querystring-manipulatie en/of query-injection ? Het is niet een 'foutje'; het is gewoon een lompe fout. Een beetje proactief alert zijn bij dergelijke applicaties mag je best van een serieuze programmeur of tester verwachten hoor ...
welke serieuze web-programmeur houdt geen rekening met querystring-manipulatie en/of query-injection ?
de programmeur die dat niet mag, onder tijdsdruk van opdrachtgevers of managers die vinden dat dat teveel kost en/of niet direct zichtbaar resultaat geeft.

komt echt veel te vaak voor.
Vaak is het helaas ook gewoon een gebrek aan kennis hierover van programmeurs is mijn ervaring. Als je wat simpele richtlijnen gebruikt kunnen dit soort "fouten" echt niet zomaar voorkomen. Ik gebruik bijvoorbeeld standaard de richtlijn dat je NOOIT een ID uit je database direct gebruikt in parameters waar de gebruiker bij kan, maar in plaats daarvan bijvoorbeeld een random "access-key" die alleen intern (in de database) aan een account ID is gekoppeld.

Door deze simpele truck is er niet direct een groot lek zelfs als je totaal "vergeet" enige toegangscontrole uit te voeren...
En daar valt als nadeel bij te noemen van deze aanpak dat het veel lastiger wordt om juist op dit soort lekken gestructureerd te testen.

Bovendien is het bij applicaties waar een gebruiker vaker in werkt bijzonder vervelend als je geen bookmark kunt plaatsen.
Ik bedoel met random access-key een sleutel die eenmalig (bijvoorbeeld bij het aanmaken van een account) random wordt gegenereerd en dan in de database wordt opgeslagen als het ID dat voor de identificatie van een gebruiker wordt gebruikt. Dit is dus verder gewoon een vaste ID, die niet meer verandert en waar je gewoon prima mee kunt testen en ook een bookmark naar kunt maken. Het gaat er alleen om dat je dan dus geen opvolgende nummers hebt zodat een buitenstaander niet de ID van een andere gebruiker kan raden.
Ook voorkomt het het lekken van evt. bedrijfsgevoelige gegevens (zoals bijvoorbeeld aantal accounts dat per maand wordt gemaakt e.d.).
Het is dus eigenlijk gewoon een extra nummer naast het gewone volgnummer in een database, maar dan een nummer dat niet geraden kan worden. Is in gebruik net zo simpel als gebruik van volgnummer (in feite hoef je alleen een ander veld te gebruiken). Het enige extra werk is het aanmaken bij het aanmaken van het account, maar ook dat valt natuurlijk erg mee.
Bij een beetje database pakket kan je gewoon je attribuut zo configureren dat het automatisch een willekeurig getal of een string wordt gegenereerd om te gebruiken als sleutelattribuut.

Dat hoeft helemaal niet meer werk te kosten dan een optie van sequentieel naar willekeurig te veranderen.
Dan is het toch jouw taak als programmeur om rond de tafel te gaan zitten en te zeggen waarom het wel nodig is. Zij hebben de technische kennis niet en kunnen niet inschatten of iets echt nodig is of niet.

Zo zouden zo nog eens de handrem kunnen weghalen bij je auto want hoevaak heb je die echt nodig? Hoevaak parkeer je nu op een berg?
Het kan niet zonder, dus waarom zou een programmeur ueberhaupt denken dat hij dat kan doen zelfs als een opdrachtgever denkt dat het kan?
ja ja dat weet ik wel. Dat neemt niet weg dat fouten maken menselijk is? overigens denk ik dat het een communicatie fout is geweest tussen verschillende programmeurs. zo van niemand wist wie er nu eigenlijk voor beveiliging ging zorgen.
Absoluut niet mee eens clifdon. Als jij een serieuze web developer bent, dan maak je een dergelijke fout gewoon niet. Klaar. Dat is echt niet goed te praten.
Hij zegt tenmisnte nog *iets*.

ontopic:
Het bedrijf heeft Stempunt.nu een kwartier na de melding van Tweakers.net offline gehaald
Kijk dat is tenmisnte het probleem serieus nemen. Chapeau! Beter dan al die schurken die hun site gewoon online laten staan terwijl ze 'onderzoek' doen.
Verheggen schat dat de accounts van enkele honderden panelleden te misbruiken waren, maar kan geen precies aantal noemen.
Kijk dat is dan weer jammer. Elke enigzins technisch aangelegde lezer begrijpt meteen dat dit een generieke fout is en dat dus in principe de accounts van *alle* panelleden te misbruiken waren. Helaas.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True