Fox Sports dicht lek in website dat inzage gaf in facturen van klanten

De website van Fox Sports bevatte een lek waardoor het mogelijk was om facturen van willekeurige gebruikers op te vragen. Daarop waren naast het klantnummer gegevens te zien zoals naam en adres. Nadat Tweakers melding maakte van het lek, werd het gedicht.

Tweakers werd van het lek op de hoogte gesteld door een anonieme tip die binnenkwam via Publeaks. De tipgever toonde een aantal url's, waarmee het mogelijk was om facturen van klanten in te zien. Daarvoor was geen verdere handeling vereist en de factuur kon in de vorm van een pdf worden gedownload. Het was mogelijk om facturen van willekeurige klanten op te vragen door een identificatienummer aan het einde van de url steeds met een cijfer te verhogen.

De facturen waren afkomstig van het domein jouw.foxsports.nl. Tweakers heeft contact opgenomen met Fox Sports en het bedrijf op de hoogte gesteld van het lek. Vervolgens is dit binnen een dag gedicht, waardoor de facturen niet meer op deze manier toegankelijk zijn, zo bevestigt een woordvoerder. Het is volgens Fox Sports nog niet duidelijk hoeveel facturen inzichtelijk waren door het lek en ook is het onbekend of er misbruik van is gemaakt. De gegevens kunnen bijvoorbeeld gebruikt worden in gerichte phishing-aanvallen, oftewel spear phishing.

Op de vraag of zowel klanten als mogelijk de Autoriteit Persoonsgegevens op de hoogte worden gesteld, antwoordt de woordvoerder dat dit nog niet duidelijk is. "Wij zullen er eerst goed induiken en daarna vervolgstappen nemen", zo legt hij uit. Het lek zou ontstaan zijn ondanks verschillende beveiligingsmaatregelen, voegt hij daaraan toe.

Reacties (41)

[Verwijderd]

Het gaan om facturen van de FoxSport GO abonnees, niet om facturen van gekoppelde accounts

[HetBrabandertje]

Zou hiermee ook samenhangen dat FoxSports GO al het hele seizoen geen nieuwe abonnees meer accepteert, maar alleen in combinatie met het tv-abonnement? Ze spreken al die tijd al over onderhoudswerkzaamheden aan het systeem en de plek waar nu het lek zit had ook alleen gevolgen voor die groep abonnees.

[ToySoldier1992]

Op de vraag of zowel klanten als mogelijk de Autoriteit Persoonsgegevens op de hoogte worden gesteld, antwoordt de woordvoerder dat dit nog niet duidelijk is. "Wij zullen er eerst goed induiken en daarna vervolgstappen nemen", zo legt hij uit. Het lek zou ontstaan zijn ondanks verschillende beveiligingsmaatregelen, voegt hij daaraan toe.

Realiseren ze zich wel dat ze verplicht zijn om dit te melden, sinds 1 januari? Nogal een rare reactie imho.

[Zer0]

Niet elk datalek hoeft gemeld te worden, het is onder andere afhankelijk van het soort gegevens wat gelekt is.
Kort gezegt: U hoeft een datalek alleen te melden als dit leidt tot ernstige nadelige gevolgen voor de bescherming van persoonsgegevens. Of als een aanzienlijke kans bestaat dat dit gebeurt.
De lange uitleg: https://autoriteitpersoon...meldplicht_datalekken.pdf
Daarnaast is er een termijn van 72 uur na ontdekking voor het melden, en indien er goede redenen zijn mag het zelfs nog langer duren.
Zie art. 31, eerste lid, van de concept-Algemene Privacy-verordening, uit de tekst zoals
geamendeerd door de Raad van de Europese Unie: "In geval van een inbreuk in verband
met persoonsgegevens […] meldt de verantwoordelijke de overeenkomstig artikel 51
bevoegde toezichthoudende autoriteit deze inbreuk zonder onnodige vertraging en zo
mogelijk niet later dan 72 uur nadat hij ervan kennis heeft gekregen. Wanneer de melding
aan de toezichthoudende autoriteit niet binnen 72 uur plaatsvindt, gaat deze vergezeld
van een motivering."

Ik kan me dus heel goed voorstellen dat je als bedrijf eerst even goed nadenkt en je feiten op een rij zet voor je melding doen.

[Reactie gewijzigd door Zer0 op 24 juli 2024 13:47]

[ToySoldier1992]

U hoeft een datalek alleen te melden als dit leidt tot ernstige nadelige gevolgen voor de bescherming van persoonsgegevens. Of als een aanzienlijke kans bestaat dat dit gebeurt.

Uitgelekte facturen, NAW-gegevens, lijkt me toch een zeer ernstig nadelig gevolg.

[Zer0]

Het gaat niet om de gegevens die gelekt zijn, maar op het gevolg van het feit dat die gegevens op straat liggen.
Daarbij zijn twee vragen belangrijk:

Zijn er persoonsgegevens van gevoelige aard gelekt?
Dat lijkt me niet in dit geval, gegevens van gevoelige aard zijn dingens als geloofsovertuiging, sexuele geaardheid, gegevens over gezondheid etc.

Leiden de aard en omvang van de inbreuk tot (een aanzienlijke kans op) ernstige nadelige gevolgen?
Het lijkt er op dat er alleen NAW gegevens gelekt zijn, geen rekeningnummers of andere gegevens. Als dit het geval is zou je deze vraag met nee kunnen beantwoorden en is melding niet nodig.
Nu is die tweede vraag imo moeilijk te beantwoorden, en zelf zou ik ook eerst goed nadenken of melding wel of niet noodzakelijk is, maar daar heb je dan ook 72 uur de tijd voor.

[puntje013]

De definitie van gevoelige aard is ook subjectief, ik heb liever dat mijn geloofsovertuiging of sexuele voorkeur op straat liggen ipv mijn naw gegevens en rekeningnummer.

[Zer0]

De definitie van gevoelige aard is ook subjectief

Voor de meldplicht is die niet subjectief, maar gewoon vastgelegt, zie mijn eerdere reactie voor een link waar de definitie in staat. Simpele NAW gegevens vallen er niet onder, en afaik is er geen sprake van gelekte rekeingnummers.

[Asitis]

Niet persé, dus. Toevallig laatst ook een datalek gehad bij een klant, maar in dat geval was het ook niet verplicht om het te melden. Dat is afhankelijk van een aantal factoren en de gelekte data.

[Qauters]

Als je de regels van de AP doorleest dan zie je dat dit voor dit geval waarschijnlijk niet geldt:
4.2.1 geeft aan wat gevoelige gegevens zijn, de gegevens die op een normale factuur staan valt hier niet onder zolang je hierbij geen gevoelige informatie krijg zoals politieke / sexuele voorkeur etc.

Desalniettemin is het natuurlijk beroerd slecht geïmplementeerd, of je checkt of het factuur overeenkomt met ingelogde account of je zorgt ervoor dat het ID zodanig random is dat deze niet gokbaar is (guid of een simpele postfix dat random is per id) met uiteraard een check dat je niet meer dan X requests kan doen.

[cavey]

Oftewel, 0,0 authenticatie checks in de module die de PDF genereert. Geen cookie, sessie, of whatever. Dan kan je nog overal authenticatie schermen en checks inbouwen, als je PDF generator gewoon doodleuk niks controleert hang je.

Komt imho te vaak voor dit soort meldingen. Dit valt onder de categorie "security by obscurity". Omdat de URL normaliter niet publiekelijk toegankelijk is vanaf het internet (het zit achter een authenticatie scherm), vergeten ze gemakshalve maar een extra security check in te bouwen >_<

En dan ben ik al jaren niet eens meer een developer

[yeep]

Nummer 4 in de OWASP top 10: https://www.owasp.org/ind..._Direct_Object_References

[cavey]

Thanks! Mooie link, je zou toch denken dat dit ondertussen wel bij Web Dev Security 101 wordt onderwezen

[Rafe]

Was de PDF generator direct toegankelijk of alleen de directory waar de gegenereerde bestanden in stonden? De eerste is aannemelijk onderdeel van het klantensysteem en valt onder dat authenticatiemechanisme (de "verschillende beveiligingsmaatregelen"), dus het laatste lijkt me waarschijnlijker.

[Reactie gewijzigd door Rafe op 24 juli 2024 13:47]

[cavey]

Goede vraag, heb ik zelf niet bij stil gestaan dat dit ook nog gedaan wordt. De facturen kunnen inderdaad best al gegenereerd staan op die plek, puur vanwege audits en dat je niet zomaar even de factuur opnieuw kan genereren met vernieuwde opmaak, omdat het dan historisch gezien niet meer klopt.

[Verwijderd]

De facturen worden on the fly gegenereert

[Toet3r]

Toch wel opvallend en treurig dat veel grote bedrijven die geld zat hebben om een fatsoenlijke website te (laten) maken hun zaakjes niet op orde hebben. Vind dit toch wel in de categorie van ernstige lekken vallen als je leest wat er allemaal buit gemaakt kon worden.

[yeep]

Het kan verschillende redenen hebben: enorme druk om features op te leveren en security wordt nog steeds vaak niet als feature gezien. Is het eigenlijk ook niet. Het is een soort verzekering.
Of IT personeel dat misschien heel erg goed is in websites bouwen, maar het verschil tussen encryptie en hashing al niet eens snappen en denken dat Base64 prima encryptie is.
Of iets wat ik nog wel eens in mijn eigen organisatie zie: Grote druk vanuit management om even snel een fix of work-around of tijdelijke oplossing op te leveren en daarna nooit meer de mogelijkheid krijgen om het definitief goed te fixen.

[BarôZZa]

Het punt is natuurlijk dat security nog belangrijker is dan features, dus features zouden in geen enkel geval een hogere prio mogen krijgen zodra je met persoonsgegevens werkt.

Werk zelf ook als developer, maar als developer heb je zelf net zoveel verantwoordelijkheid. Hoewel herkenbaar, is management geen excuus en ben je zelf net zo fout bezig als je willens en wetens de gegevens van mensen in gevaar brengt. In dergelijke gevallen moet je simpelweg eisen dat de werkprocedures veranderen of simpelweg elders gaan werken.

Helaas zie je bij veel bedrijven dat ze voor de 'pragmatische weg' kiezen en dat 'developers' die snel en blind alles in elkaar hacken zonder zelf mee te denken vaak erg gewaardeerd worden. En developers hebben vaak geen ruggengraat om tegen management in te gaan.

[yeep]

Vooral dat laatste stuk ja :-)

[gigi71]

De tipgever toonde een aantal url's, waarmee het mogelijk was om facturen van klanten in te zien. Daarvoor was geen verdere handeling vereist en de factuur kon in de vorm van een pdf worden gedownload. Het was mogelijk om facturen van willekeurige klanten op te vragen door een identificatienummer aan het einde van de url steeds met een cijfer te verhogen.

Volgens Fox Sports:

Het lek zou ontstaan zijn ondanks verschillende beveiligingsmaatregelen, voegt hij daaraan toe.

Als de methode zo simpel is kun je je serieus afvragen wat de verschillende beveiligingsmaatregelen inhouden. IMHO een beetje een domme opmerking.

[cracking cloud]

Degene die dat ontwikkeld heeft zouden ze per direct achter de pc moeten wegtrekken en moeten verbieden om ooit nog aan de slag te gaan als developer.

Maar goed, iets constructiever, zou er geen certificering oid moeten zijn waar je aan moet voldoen voordat je je bezig mag gaan houden met klantgevoelige data op internet?

[HollowGamer]

Vergissen is menselijk, het kan altijd zo zijn dat er een authenticatie is vergeten.
Een URL zegt tegenwoordig niks meer, direct bestanden aanroepen zit er meestal niet meer in.
Niet goed natuurlijk, maar we zijn nu eenmaal niet perfect en er zijn genoeg voorbeelden waardoor dit kan gebeuren.

Het is maar de vraag of een certificaat een goed idee is, lijkt mij meer geldklopperij.
Alle huidige systemen bevatten gaten/omwegen om toch bij data te komen, ook al heb je de 'perfecte' policies opgesteld, en heb je als developer de beste beveiligingsmethodes geïmplementeerd.
Een persoon die toegang heeft tot gevoelige data kan deze nog altijd zelf lekken (zie Snowden) of getroffen worden door malware/hacker(s). Dan heb ik nog niet eens gehad over de marktplaatsen waar je exploits kan kopen die helemaal niet bekend zijn.

Wil je makers van OpenSSL ook verbieden een systeem nog aan te raken omdat deze de Heartbleed bug niet hebben zien aankomen?
Mag ik jou dan ook aanklagen als er adresgegevens lekken uit je contactenboek (ook zonder jouw schuld)? Dat is immers ook 'gevoelige data'.

Het is allemaal zo makkelijk om te roepen om dit te roepen over developers, maar er bestaat geen bullet-proof oplossing en die zal er nooit zijn.

[Reactie gewijzigd door HollowGamer op 24 juli 2024 13:47]

[loordgek]

"identificatienummer aan het einde van de url steeds met een cijfer te verhogen"
dat is geen vergissing
https://www.youtube.com/watch?v=CgJudU_jlZ8

[mkools24]

Waarschijnlijk een index.html aanmaken met '<h1>hier is niets te zien</h1>'

[AW_Bos]

Dat beveiligt niks. Als iemand de juiste URL's weet die onbeveiligd publiekelijk staan, dan is het meer 'security trough obscurity'.

Oplopende (factuur)nummers in de URL is gewoon pijnlijk. Vermeng die nummers met een goede hash waaruit niemand kan achterhalen welk nummer erachter zat, en bescherm de facturen ook door alleen facturen van jezelf te laten zien.

[Kama]

Je kunt je afvragen waarom je uberhaupt klantnummers in een bestandsnaam stopt. De webserver weet (hopelijk) toch wel welke klant ie voor zich heeft en de klant heeft maar 1 factuur. Een datum in de factuur is voldoende zou je zeggen.

Een aardige vuistregel is om geen ID's te publiceren van zaken waaraan niet gerefeerd hoeft te (kunnen) worden.

[Blokker_1999]

Het zal in dit geval om factuurnummers gaan, geen klantnummers en klanten hebben over het algemeen een hele lading (historische) facturen die ze ook kunnen raadplegen op de website van vele dienstverleners.

[Kama]

Daar geldt hetzelfde voor. Geen enkele reden om dat in de URL of bestandsnaam te stoppen. Factuurperiode (datum) in combinatie met de gebruikersgevens die uit de sessie volgen is genoeg informatie om het juiste bestand te genereren/door te sturen.

[Verwijderd]

Dan werken zaken als bookmarks niet. De oplossing is om alleen de informatie te serveren als er is ingelogd.

[batjes]

Je kunt per klant de url van de facturen wel identificeren met cijfers. Gewoon bij elke klant met de eerste factuur bij nr 1 beginnen.

[Verwijderd]

Maar dat slaat eigenlijk nergens op. Er is geen enkele developer die een (web)applicatie vanaf scratch zo bedenkt. De enige reden om dat te doen, zou zijn om ofwel extra functionaliteit toe te voegen, of een of andere rare vorm van "security".
Als iemand die moeite wil nemen, kan diegene beter die moeite steken in het gewoon netjes beveiligen en (laten) testen van die beveiliging.

[mkools24]

Ehhh ja ik bedoelde dat ook gekscherend. Sorry als dat niet overduidelijk was

[DeathMaster]

Ik neem aan dat dit zich beperkt tot de klanten die apart een abonnement op Fox Sports hebben? Gezien de mensen die dit als onderdeel van een pakket bij hun kabelaar hebben hier, naar ik aanneem, niet apart voor worden gefactureerd.

Dit klinkt overigens wel als een ongelofelijk amateuristische fout.

[dutchgio]

Wel vrij slordig dat het zo makkelijk gaat, enkel een nummrtje van de link naar je eigen factuur veranderen en je ziet die van iemand anders al...

[Trommelrem]

Grappig. Dit doet mij denken aan de HoTMaiL hack van 2001, toen je door de URL te veranderen random emails uit mailboxen van andere personen/accounts kon openen.

-edit-
HoTMaiL hack van 2001, niet 2003.

[Reactie gewijzigd door Trommelrem op 24 juli 2024 13:47]

[biglia]

Het was mogelijk om facturen van willekeurige klanten op te vragen door een identificatienummer aan het einde van de url steeds met een cijfer te verhogen.

Hehe, een klassiekertje. Ze zouden dat als examenvraag moeten invoeren op school.

[Zidane007nl]

Zeker een URL als https://jouw.foxsports.nl/factuur?id=1 en dan niet controleren of de klant de factuur mag bekijken ...