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 , , 26 reacties

Het bedrijf Verzuimdata heeft een lek in zijn systeem gedicht, waarmee het voor ingelogde gebruikers mogelijk was om de gegevens van andere klanten van het bedrijf in te zien. Daarbij ging het om bedrijfs- en verzekeringsgegevens.

Het lek werd door een anonieme partij gemeld bij Tweakers, waarna er dinsdag contact is gelegd met de organisatie. Een woordvoerder van Verzuimdata heeft het lek bevestigd en meldde verder dat de getroffen pagina's binnen een dag tijdelijk zijn uitgeschakeld. Uit onderzoek naar het incident blijkt dat er gegevens van zeven klanten ingezien zijn, waarschijnlijk door de melder van het lek zelf. De Autoriteit Persoonsgegevens wordt over het lek ingelicht, ook al zou dat strikt genomen niet nodig zijn. Daarnaast vindt er communicatie plaats naar de getroffen klanten. Woensdagavond heeft een nieuwe release van de software plaatsgevonden, waarin het lek is verholpen.

Het lek bevond zich in de omgeving voor ingelogde gebruikers op de site verzuimdata.nl. Daar krijgt een gebruiker een dashboard te zien met verschillende mogelijkheden. Zo zijn er knoppen om bijvoorbeeld de eigen verzekering in te zien en de contactpersoon van de eigen organisatie te wijzigen. Door een id in de url aan te passen, was het mogelijk om de gegevens van andere klanten in te zien. Bijvoorbeeld het e-mailadres, telefoonnummer, polisnummer van de verzuimverzekering, premie en andere bedrijfsgegevens. De woordvoerder van Verzuimdata legt uit dat het lek niet op alle pagina's aanwezig was.

Tweakers had in eerste instantie beperkte informatie over het lek aangeleverd in de vorm van een schermafbeelding die ontdaan was van identificerende informatie. Op basis daarvan kon Verzuimdata het lek al dichten. Op de vraag of er al een vermoeden bestond naar de oorsprong van het lek antwoordde de woordvoerder dat dit vermoeden niet aanwezig was, maar dat het soort lek bekend moest zijn omdat het op sommige pagina's niet aanwezig was.

Verzuimdata heeft verschillende klanten, waaronder werkgevers en verzekeraars. Het bedrijf biedt onder andere diensten aan om gegevens over verzuim van werknemers bij te houden en te delen.

Moderatie-faq Wijzig weergave

Reacties (26)

Pakken ze keurig op.
  • ze weten precies hoeveel klanten getroffen zijn
  • communiceren het richting de getroffen klanten
  • lichten de Autoriteit Persoonsgegevens in (ook al had dat niet gehoeven)
  • lek snel gedicht
Voorbeeld voor een hoop bedrijven.
Ik zie niet in waarom het melden van het lek niet nodig zou zijn. Volgens mij is de meldplicht gewoon van toepassing.

Verder inderdaad prima opgepakt.

[edit]
Dit zegt de Autoriteit Persoonsgegevens er over:
Bij een datalek gaat het om toegang tot of vernietiging, wijziging of vrijkomen van persoonsgegevens bij een organisatie zonder dat dit de bedoeling is van deze organisatie. Onder een datalek valt dus niet alleen het vrijkomen (lekken) van gegevens, maar ook onrechtmatige verwerking van gegevens.

We spreken van een datalek als er een inbreuk is op de beveiliging van persoonsgegevens (zoals bedoeld in artikel 13 van de Wet bescherming persoonsgegevens). Bij een datalek zijn de persoonsgegevens blootgesteld aan verlies of onrechtmatige verwerking – dus aan datgene waartegen de beveiligingsmaatregelen bescherming moeten bieden.
Ook als je de richtlijnen verder leest wijst alles er op dat dit onder de meldplicht valt.


[edit 2]
Het lijkt inderdaad alleen om bedrijfsgegevens te gaan en dus geen persoonsgegevens en hoeft dáárom niet gemeld te worden.

[Reactie gewijzigd door emnich op 29 september 2016 11:45]

Sterker nog: naar mijn idee moeten de klanten in het pakket ook op de hoogte worden gesteld.
Nee hoor, die meldplicht is pas een echte plicht als het datalek aan allerlei 'voorwaarden' voldoet, waaronder de soort data, de grootte van het lek en de 'misbruikbaarheid' van de data (d.w.z. contactgegevens van bedrijven zijn weinig bruikbaar in een lek; die zijn toch al openlijk bekend).
Van Autoriteit Persoonsgegevens:
U hoeft niet ieder datalek te melden aan de Autoriteit Persoonsgegevens. Volgens de wet moet u een melding doen aan de Autoriteit Persoonsgegevens als het datalek leidt tot een aanzienlijke kans op ernstige nadelige gevolgen voor de bescherming van persoonsgegevens, of als het ernstige nadelige gevolgen heeft voor de bescherming van persoonsgegevens.

Als ik het artikel goed begrijp, gaat het hier om bedrijfsgegevens en geen persoonsgegevens. Daarbij staan er nog een aantal schema's en andere richtlijnen waarmee je kunt beoordelen of het lek ernstig genoeg is, bijvoorbeeld aan de hand van de gevoeligheid van de informatie.

[Reactie gewijzigd door _gibeon_ op 29 september 2016 11:48]

Van: https://autoriteitpersoon...den/meldplicht-datalekken
Sinds 1 januari 2016 geldt de meldplicht datalekken. Deze meldplicht houdt in dat organisaties (zowel bedrijven als overheden) direct een melding moeten doen bij de Autoriteit Persoonsgegevens zodra zij een ernstig datalek hebben. En soms moeten zij het datalek ook melden aan de betrokkenen (de mensen van wie de persoonsgegevens zijn gelekt).
Kortom, ze werken gewoon zoals dat verplicht is. Ja, ze hebben het opgepakt, maar in principe is dit dus "gewoon" zoals het moet. Ik zou niet anders verwachten.

Wel +1 voor T.Net om het proces in gang te zetten!
Door een id in de url aan te passen, was het mogelijk om de gegevens van andere klanten in te zien.
Onder het kopje fouten, is dit dus hoe het "gewoon niet moet". Die staat in het lijstje van passwords unencrypted of met alleen een MD5 hash in een database opslaan, etc vrij hoog op de lijst van "nalatigheid" in mijn boekje. Helaas is dat niet strafbaar...
Kortom, ze werken gewoon zoals dat verplicht is. Ja, ze hebben het opgepakt, maar in principe is dit dus "gewoon" zoals het moet. Ik zou niet anders verwachten.
Het betrof geen persoonsgegevens en of dit nu ernstig is, valt ook maar te bezien, dus ze hebben wel degelijk meer gedaan dan verplicht. Achteraf bashen is altijd makkelijk, zeker wanneer je geen inside info hebt, de melding is via-via gegaan voordat deze bij Verzuimdata is terecht gekomen.

+1 voor Tweakers.net voor het melden van het lek i.p.v. het eerst openbaar te maken. Maar ook +1 voor Verzuimdata voor de adequate reactie.

[Reactie gewijzigd door slb op 29 september 2016 12:17]

Ik vind dit soort security issues eigenlijk nog wel zwaarder dan unencrypted passwords in een db (en dat vind ik al schrikbarend). Je kunt je hele infrastructuur nog zo goed beveiligen met ik weet niet hoeveel tiers, uiteindelijk ligt de data alsnog op straat omdat de softwareleverancier niet een beetje, maar echt extreem hard gefaald heeft. Dat is al erg genoeg, nog veel erger vind ik dat er OF geen audit op dit soort publieksgegevens is uitgevoerd, OF uit een eventuele audit is dit issue niet naar voren gekomen.

Het is echt schrijnend dat dit soort zaken anno 2016 nog voorkomen, ze mogen wel eens erg hard over hun bolletje krabbelen daar of die leverancier niet eens de deur gewezen moet worden en tegelijkertijd de bedrijfsvoering eens goed bekijken. Onkunde ten top.

[Reactie gewijzigd door porn* op 29 september 2016 12:08]

Eens. Je controleert toch of een gebruiker toegang heeft tot alleen z'n eigen id en niets anders? Dit is zo simpel in elkaar gedraaid... Het lijkt wel outsourcing naar India ofzo.
De ontwikkelaar had in elk geval verzuimt om enige vorm van beveiliging in te bouwen kennelijk. Amateurfout.
OF simpelweg tijd / geld gebrek? Vaak worden dit soort keuzes gemaakt op basis van urenschattingen en als die te ruim zijn dan moet er gesnoeid worden en dan worden wel eens de verkeerde keuzes gemaakt.

Dus om nou iemand meteen als amateur weg te zetten is veel te makkelijk
Het genereren van een random ID en die mee opslaan zou echt basiskennis moeten zijn en als good practice worden toegepast. Je hebt geen excuses om het niet te doen, ook niet op gebied van kosten aangezien het je hoogstens enkele minuten extra kost in heel het ontwikkelprocess.
Plus een korte controle of de ingelogde gebruiker wel toegang heeft tot betreffende dossier. Dat is echt geen jaren werk en zelf standaard in vrijwel elk framework. Dit soort fouten worden in mijn perceptie meestal begaan door kleine webbedrijven met een hoop goedbedoelende stagairs.
Of als de boel outsourced is naar India of zo |:(
Dat is dus een amateuristische fout! Als je ook maar enig benul hebt van web development, dan check je dit en laat je een klant niet bezuinigen op zoiets.. Zelfs een slechte amateur maakt zo'n fout nog niet...
Het zijn amateurs, immers iedereen met een beetje kennis/ervaing met user input weet dat je deze nooit maar ook nooit moet vertrouwen. En of je nu simpele opeenvolgende/voorspelbare IDs of random/crypted IDs gebruikt, je zal altijd moeten controleren of een gebruiker deze mag benaderen.
Nope. Als je dit soort spul bouwt ben je gewoon een amateur. Te weinig tijd is geen excuus voor die soort nalatigheden. Geef het aan en vraag meer tijd. En als die tijd er niet is, ga je gewoon andere features droppen.

Van de andere kant is het echt niet zoveel werk om je ID's te hashen of nog beter, je requests te checken om te kijken of die klant wel bij die data mag komen.

Je validatie alleen front end uitvoeren is toch iets waarover we in 2004 het al eens waren dat dat een absolute no-go is. Jammer dat dit soort fouten anno 2016 nog gemaakt worden. Helaas was er blijkbaar geen geld voor een senior developers en/of security testing.....
Agree. Helaas zie je in veel systemen dit soort elementaire fouten nog voorkomen; ID in de url wijzigen en laat maar zien die data. Hulde voor het snel 'dichten' van dit lek, wat natuurlijk niets meer is dan het regeltje code wat de ID van de opgevraagde gebruiker aftoetst tegen het ID van de ingelogde gebruiker even copy pasten vanuit pagina's waar het 'lek' zich niet voordeed.
Door een id in de url aan te passen, was het mogelijk om de gegevens van andere klanten in te zien.
Lijkt er eerder op dat de ontwikkelaars onvoldoende hebben nagedacht over autorisatieschema's en gebruikersrollen. Nog steeds een beetje knullig, dat wel.
Klinkt als een systeem dat in eerste instantie alleen bedoeld was voor intern gebruik, waarbij iedereen die toegang had tot het systeem automatisch het recht had om overal bij te kunnen. Later is het dan uitgebouwd tot een online systeem voor meerdere gebruikers die strikt van elkaar gescheiden moeten blijven. Bij het ombouwen zijn dan een paar steken laten vallen.
Melding van dit lek als er NAW gegevens bij betrokken zijn is altijd verplicht.
Geen idee waar de stelling vandaan komt dat het eigenlijk niet zo hoeven. Of de gelekte data is niet te herleiden tot personen. Dat zou natuurlijk kunnen, maar dat had dan wel in het artikel moeten staan.
Link: https://autoriteitpersoon...den/meldplicht-datalekken
Bij een datalek zijn de persoonsgegevens blootgesteld aan verlies of onrechtmatige verwerking –

[Reactie gewijzigd door SED op 29 september 2016 11:38]

De woordvoerder van Verzuimdata legt uit dat het lek niet op alle pagina's aanwezig was
Dat is misschien nog wel het meest zorgelijke uit het hele bericht. Dus ze weten hoe het goed moet maar hebben dat niet overal gedaan. Dat zou duiden op slechte communicatie binnen het team, geen (of hele slechte) code reviews, geen architectuur en een puinhoop van een codebase. Nee, geef mijn portie maar aan Fikkie.
Op de vraag of er al een vermoeden bestond naar de oorsprong van het lek antwoordde de woordvoerder dat dit vermoeden niet aanwezig was, maar dat het soort lek bekend moest zijn omdat het op sommige pagina's niet aanwezig was.
Dat is een slecht teken, het suggereert dat iedere pagina anders is omdat ze allemaal met de hand worden gebouwd, er is blijkbaar geen onderliggend framework. Dat betekent dat je fouten niet centraal kan oplossen, je moet alle pagina's nalopen en controleren, daarbij moet je maar hopen dat dezelfde fout in de toekomst niet nog een keer wordt gemaakt.
Beter gebruik je een framework dat alle mundane taken (zoals het verwerken van formulieren en andere invoer) voor je doet. Als er dan een fout zit hoe je alleen maar de centrale procedure in het framework aan te passen. In weze komt het er op neer dat je zoveel mogelijk kennis van de programmeur naar de computer wil verplaatsen. De computer is nooit lui of vergeetachtig, mensen wel. Hoe meer de computer doet hoe minder de mens fout kan doen. Als mens kun je je dan richten op het ontwerpen ipv het schrijven van code.
Kan nog steeds framework zijn waar een deel nog legacy code bevat, grappig genoeg heeft zoiets ook nooit prioriteit bij een sprint planning :)
Zulke logica fouten hebben echt niets te maken met de taal waarin je programmeert.

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x 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