Gegevens 20.000 autokopers waren in te zien door lek bij kredietverstrekker

Gegevens van 20.000 Nederlandse autokopers waren in te zien op de website van kredietverstrekker AutoCash, door na in te loggen een cijfer aan te passen in de url. AutoCash wordt door ongeveer tachtig autodealers in Nederland gebruikt.

Via het lek waren naw-gegevens, telefoonnummers, maandelijkse krediet- of leasekosten en rekeningnummers in te zien. In sommige gevallen was ook het netto maandsalaris of de hoogte van de huur of hypotheek van de klant te zien.

RTL Z heeft naar eigen zeggen in korte tijd de gegevens van minstens vierhonderd mensen ingezien via het lek. Een tipgever die RTL op de hoogte bracht heeft het lek naar eigen zeggen al maanden geleden aangekaart bij de softwareleverancier, maar met zijn melding zou niets zijn gedaan. Nadat RTL Z melding maakte van het lek, is het gedicht. Daarnaast wordt het lek bij de Autoriteit Persoonsgegevens gemeld.

Ook data van mensen die alleen een kredietaanvraag hebben ingediend, maar uiteindelijk geen klant zijn geworden, was inzichtelijk. AutoCash wordt door dealers gebruikt om financiering aan te bieden bij de aanschaf van een auto. Het is onderdeel van Volkswagen Pon Financial Services. RTL Z merkt op dat het moederbedrijf destijds een bericht op zijn website plaatst dat klantgegevens 'veilig zijn'. Dat was een reactie op het grote lek van gegevens van Nederlandse leaserijders. Het betreffende bericht is intussen verwijderd.

Reacties (160)

Responsible disclosure anyone

edit: met name:

Kwetsbaarheden in ICT-systemen van derden

Het NCSC hoort het ook graag als u een zwakke plek heeft gevonden in een systeem van de overheid of in een systeem met een vitale functie. Voor systemen van andere eigenaren/beheerders en of leveranciers dient u in eerste instantie de organisatie zelf te benaderen. Indien de organisatie niet of niet goed reageert, kunt u het NCSC op de hoogte brengen. Hierbij zal het NCSC een rol als intermediair op zich nemen om gezamenlijk tot een resultaat te komen.
Voor meldingen over systemen van derden:

Reageert het NCSC binnen drie werkdagen op een melding door contact op te nemen met de eigenaar en u een reactie te geven.
Is de eigenaar primair verantwoordelijk om de melder op de hoogte te houden van de voortgang van het oplossen van het probleem.
Zal het NCSC de eigenaar helpen met advies zodat het beveiligingsprobleem zo snel mogelijk verholpen kan worden.
Vraag het NCSC u om ons informatie door te geven of en hoe er al contact is geweest met de organisatie.

[Reactie gewijzigd door WeaZuL op 29 augustus 2017 20:45]

Ik weet niet of je ook op het NCSC doelt, maar het NCSC werkt vaak alleen voor overheidsinstanties. Zie ook deze afbeelding: https://ic.tweakimg.net/ext/i/imagenormal/2001488453.jpeg met het bijbehorende achtergrondartikel: reviews: Wat doet het NCSC, de 'digitale brandweer' van Nederland?

Het NCSC mag ook bedrijven tips geven op aanvraag, maar die aanvraag is dus nooit gedaan. Nu is het al te laat.

[Reactie gewijzigd door AnonymousWP op 29 augustus 2017 20:44]

Waarom zou je strafbare feiten (van jezelf) gaan melden bij de overheid?

Ook indien NCSC (die ambities schijnen ze te hebben) voor alle bedrijven beschikbaar zal komen, wil je verschoningsrecht iets wat ze je niet kunnen bieden.

Omdat dat sinds vorig jaar moet volgens de meldplicht datalekken. Doe je dat niet en het komt uit kun je een hele hoge boete krijgen van de autoriteit persoonsgegevens!

Ik weet het niet 100% zeker, maar volgens mij is het de verwerker die een datalek moet melden. Een derde die toevallig een lek heeft gevonden hoeft dat voor zover ik weet niet te melden aan de AP.

De site van de AP meldt: "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".

Ik lees dit als dat de eigenaar van de data moet melden, niet de ontdekker van de kwetsbaarheid.

Ik weet zo goed als zeker dat als een bedrijf bewust/op de hoogte is van een lek, het zijn klanten dient in te lichten en een melding te maken.

Hoe een bedrijf aan die informatie komt, kan door eigen tests zijn of door een 3e partij/white hat.

Maar de vraag is hier of een ontdekker van het lek verplicht is om het aan het AP te melden, en daarmee aan de overheid in feite aangeeft 'Hoi ik was strafbaar bezig met hacken, maar hier is het resultaat! kthnxbye'.

Dit met het risico dat deze persoon wordt vervolgd.

Overigens hoeft een bedrijf een datalek niet altijd te melden aan de betroffen personen/klanten. Dat is afhankelijk van het lek en de gelekte data.

Volgens het AP is de white-hat zelf in kwestie dat niet verplicht.

Maar als de white-hat dat meld bij het bedrijf is het aan het bedrijf hier wat mee te doen.
Als white-hat heb je dan het risico op vervolging wat het is een misdrijf wat hij/zij is begaan.
Het is in het geval van vervolging aan de rechter om te bepalen of het ethisch verantwoord was en/of de desbetreffende white-hat de gevangenis in moet. Hier kan bewijs van een melding aan het bedrijf mee wegen in het besluit van de rechter.

Dus stel een white-hat vind een datalek bij Bedrijf X. Doet een melding hiervan bij het bedrijf via een weg die betrouwbaar genoeg is voor het bewijzen van verzending en ontvangst (bijv. een aangetekende brief via de post, of een email naar hun 24/7 bereikbaar adres. Meestal een [e-mail]).

Dan heeft de white-hat zwaar genoeg wegend bewijs dat ie ethisch heeft gehandeld. Het bedrijf kan dit of in de doofpot doen. Maar in dit geval loopt het bedrijf risico een boete te krijgen voor het niet melden van de datalek.

Bedrijf X kan ook de white-hat voor de rechter slepen onder het mom van het wederrechtelijk binnendringen van het computersysteem van het bedrijf. Vanaf hier ontbreekt mij de kennis om te zeggen wie met zekerheid wint. Maar je zou kunnen stellen dat goede voorbereiding gewenst is

tl;dr: De white-hat is niet verplicht, het bedrijf wel. Aldus de informatie gevonden op de website van het AP.

note: met white-hat bedoel ik niet-ingehuurde hackers die een systeem binnendringen.

Bron: Zie eerste alinea of over hoe speciefiek ze bedrijven en organisaties bedoelen.


Disclaimer: Ik kan het ook totaal mis hebben

[Reactie gewijzigd door odiw op 30 augustus 2017 11:50]

Als jij wet overtreed heb je geen meldplicht.

Zou wel grappig zijn als iedereen zichzelf zou gaan aangeven.

"Ja geef me die boete ik heb gezondigd en 150 gereden terwijl ik wist dat ik maar 120 mocht"

Je leest het verkeerd, het gaat niet over een persoon maar een bedrijf, in dit geval een onderdeel van Pon. Of Pon er zelf achter komt dat ze een lek hebben of dat iemand ze het aangeeft is niet relevant. Pon was in dit geval zeker wel verplicht een melding te doen, het heet niet voor niks meldplicht datalekken. Als ze dit willens en wetens stil hebben gehouden krijgt dit echt nog een staartje!
Je voorbeeld van de boete gaat niet op, de meldplicht is juist een manier om minder/geen boete te krijgen en dus het melden te stimuleren. Het werkt niet net zoals bij verkeersovertredingen.

Tot aan het moment dat RTL het naar buiten bracht konden ze wetenschap ontkennen.

En neen ik zit niet fout lees geheel eens goed. Ik doelde op degene die misdrijf begin. En uiteindelijk RTL belde.

Vergelijk het met als je in een woonwijk met een graafmachine per ongeluk een gasleiding raakt. Het explosiegevaar is een bedreiging voor de wijk. De graver zou kunnen wegrijden en verder niets zeggen.
Het belang van de graver (niet beboet worden) is dan ondergeschikt aan het belang van de woonwijk (niet weggevaagd worden).

Ook al zou er geen wet zijn, je hebt in mijn ogen nog steeds moreel de plicht om alles te doen om de schade te beperken. Het melden is daarbij een kleine moeite.

Een ID veranderen in de URL is echt uit 2001, als je een goede programmeur hebt die een bewezen framework gebruikt hoef je niet eens na te denken over dit soort onzin. De site is waarschijnlijk of echt oud of door een beunhaas in elkaar gezet, wakeup call zou ik zeggen.

Dat gezegd hebbende, waar hebben we het over? Je moet sowieso een gebruikersnaam en wachtwoord hebben om in te kunnen loggen, dat is de grote lek hier. Ik ga er even van uit dat de dodo die dit aan RTL heeft gemeld zijn accountgegevens aan RTL heeft gegeven, anders weet ik zo even niet hoe RTL aan een account komt.

Het gaat waarschijnlijk om een autohandeleer of iemand de werkt bij een autohandelaar die even zijn elite hackerskills wilde laten zien, niet bij nadenkende dat hijzelf het grote leg is.

Een ID veranderen in de URL is echt uit 2001, als je een goede programmeur hebt die een bewezen framework gebruikt hoef je niet eens na te denken over dit soort onzin. De site is waarschijnlijk of echt oud of door een beunhaas in elkaar gezet, wakeup call zou ik zeggen.

Het is klassieke fout ja. Ze zouden dat op school moeten aanleren.
Ik wist niet dat frameworks dit automatisch kunnen verhinderen. Met ASP.NET Core zou je die fout nog steeds kunnen maken.

Als je "low level" te werk gaat, de waardes direct in een variabele stopt en dat verder gebruikt kan je zowat met elke taal dat doen. ASP.net Core ben ik niet bekend mee maar het zal waarschijnlijk minimaal een sanitizer hebben om waardes die je van de gebruiker krijgt schoon te poetsen. Denk aan CMS frameworks waar jezelf op verder kan bouwen, die hebben allemaal wel verschillende vormen van check ingebouwd.

/edit:

Snel ff Google gezocht naar "ASP.NET Core sanitize" en "ASP.NET Core XSS" en ASP.NET Core heeft standaard toch een paar libs die een hoop voor je doen. ASP.NET Core heeft standaard geen ID corelation zo te zien.

[Reactie gewijzigd door SizzLorr op 29 augustus 2017 21:35]

Je verwart nu verschillende dingen met elkaar.

XSS staat voor cross side scripting en dit is een type aanval waarbij iemand uitvoerbare code (meestal Javascript) verwerkt in een parameter, die dan onbedoeld uitgevoerd wordt bij het opvragen van informatie. Daar zijn de libraries voor je noemt: dit soort code is redelijk makkelijk herkenbaar en kun je botweg weigeren als het te veel op javascript of HTML code lijkt.

De bug die hier schijnbaar speelt, is niet zo gemakkelijk om met een library te voorkomen (zonder er zelf als ontwikkelaar verder over na te denken). Wat er zo te zien gebeurd is, is dat er in de URL een ID van de klant zat, waarbij verder niet gecontroleerd werd of de ingelogde gebruiker überhaupt toegang had tot die klant. Frameworks en libraries kunnen je het leven veel gemakkelijker maken voor het toevoegen van rechtenbeheer aan een applicatie, maar hier ging al het meest elementaire mis: een extra conditie op de databasequery die de klantgegevens opvraagt om te controleren of de gebruiker toegang heeft.

De bug die hier schijnbaar speelt, is niet zo gemakkelijk om met een library te voorkomen .....

hier ging al het meest elementaire mis: een extra conditie op de databasequery die de klantgegevens opvraagt om te controleren of de gebruiker toegang heeft.

Wat hier fundamenteel mis ging is dat er te veel vertrouwen op user input werd gelegd. Dat die input vervolgens gebruikt kon worden om een query te bouwen is vaak ook fout en dat er vervolgens geen controle was of die query uitgevoerd mocht worden is nog een fout. En dergelijke fundamentele problemen vallen afhankelijk van het ontwerp prima op te lossen met de juiste libraries of met voldoende verstand van zaken over de does and donts van gebruikers invoer en uitvoer. En aangezien we niet onder de motorkap kunnen kijken heeft het weinig zin om een discussie aan te gaan of een library of een query afdoende was geweest voor dit specifieke geval.

Hier valt prima over te discussieren. SizzLorr begon over XSS libraries. XSS is een subtopic van input validatie, en de waarde zelf sanitizen had hier niets uitgemaakt omdat het opgevraagde ID geldige user input was (ID van een klant). Het deel daarna ging in deze applicatie mis: er werd niet gecontroleerd of de ingelogde gebruiker geautoriseerd was om de klant in te zien.

SizzLorr gaf een voorbeeld van wat libraries kunnen doen en nam als voorbeeld onder andere een XSS library. Was wat ongelukkig gekozen, maar maakte wel een goed punt dat libraries een oplossing kunnen zijn afhankelijk van het soort library en de implementatie.

Wat je nu aangeeft wat mis ging is iets anders dan de stelligheid van die databasequerie. Daar reageerde ik op.

Ben je het op zijn minst met me eens dat het in eerste instantie al vrij onzinnig is om gebruikersinvoer te accepteren terwijl je bij een account vooraf al kan weten welke gegevens wel of niet opgevraagd mogen worden? De rechten kunnen dus al veel eerder worden toegepast, die userinput kunnen manipuleren is volstrekt overbodige luxe.

Wat je nu aangeeft wat mis ging is iets anders dan de stelligheid van die databasequerie. Daar reageerde ik op.

Ben je het op zijn minst met me eens dat het in eerste instantie al vrij onzinnig is om gebruikersinvoer te accepteren terwijl je bij een account vooraf al kan weten welke gegevens wel of niet opgevraagd mogen worden? De rechten kunnen dus al veel eerder worden toegepast, die userinput kunnen manipuleren is volstrekt overbodige luxe.

Dat hangt helemaal af van de implementatie, zoals je eerder schreef (nu in de juiste context, dank voor je toelichting ). Bij een redelijk gangbare implementatie in 3NF waarbij de klanten in een tabel zitten met een foreign key naar het account, en een URL waarin alleen het klant-ID verwerkt is, zul je uiteindelijk toch de match op het klant record moeten maken en checken wie de eigenaar van de klant is. Dat is lastig (en onnodig) om vooraf, tijdens de input validatie, al te checken zonder de data zelf op te vragen.

Ben je het op zijn minst met me eens dat het in eerste instantie al vrij onzinnig is om gebruikersinvoer te accepteren terwijl je bij een account vooraf al kan weten welke gegevens wel of niet opgevraagd mogen worden? De rechten kunnen dus al veel eerder worden toegepast, die userinput kunnen manipuleren is volstrekt overbodige luxe.

Nope, aangezien je totaal stompzinnige uitspraken doet.

Internet bestaat bij de gratie van gebruikersinvoer, zeggen dat het onzinnig is om gebruikersinvoer te accepteren is gewoon een totaal stompzinnige uitspraak.
Het is inherent en onoverkomelijk om bij een website gebruikersinvoer toe te staan.

Library had niets uitgemaakt. User input ook niet. Probleem lag in de rechten van een gebruiker.

Ik raad je aan om eens op OWASP.org te gaan lezen over de diverse componenten van security. Zelden is een oorzaak het probleem, zo ook hier niet alleen de rechten.

Mooi verhaal, als iemand naar een ander id gaat hoort die een forbidden response te krijgen, had je heel dit probleem niet gehad.

Je geeft nu de beschrijving van een response als gevolg van een of meer maatregelen. Het gaat om de maatregelen en die kunnen op meerdere plaatsen toegepast worden met meerdere technische maatregelen. De meest effectieve maatregel is om alleen specifieke invoer te accepteren voordat die verder ergens voor wordt gebruikt zoals het raadplegen van een database of het weergeven van de inhoud van bestanden. En of dat nou met een library wordt gedaan of een professionele eigen oplossing omdat er geen library is doet er verder niet toe.

Lekker duidelijk ook met al die maatregelen. Invoer accepteren gaat hier niet bij helpen, een rechten systeem wel.

True, maar je opmerking dat je dit met een library niet kan opvangen klopt niet. Spring Security is een voorbeeld waarmee dat prima mogelijk is.

Geen enkele library vang dit "zomaar" af. Je zult het toch echt zelf moeten doen. Er zijn security packages die helpen, maar ze zullen niet je werk voor je doen.

Nee niet "zomaar", maar een framework/library biedt vaak wel mogelijkheden om het met weinig moeite makkelijk te regelen. Spring Security voorbeeld:

@PreAuthorize("#userId == authentication.principal.id")

Eén regeltje. En het is meer een configuratie dingetje dan dat er echt code aan te pas moet komen, dus tja. Niet helemaal automatisch maar met zeer weinig configuratie bereik je precies wat er nodig was.

Overigens staat bovenstaande voorbeeld los van het feit of er uberhaupt de ID van de gebruiker nodig is in een URL als het gaat om gegevens tonen die behoren bij de geauthenticeerde gebruiker, maar dat terzijde

[Reactie gewijzigd door Ronnerd op 30 augustus 2017 11:06]

Mooi man, moet je wel ff Middleware van maken zodat je dit bij alle nodige urls toe kan passen.

Was deze sarcasme noodzakelijk?

Nee. Deze hele post was niet echt noodzakelijk.

Je verwart nu verschillende dingen met elkaar.

Dat doe ik helemaal niet, ik geef gewoon een paar voorbeelden van wat mogelijk is qua uitbereidingen.

Mijn punt is dat sanitizen in dit geval totaal niet had geholpen, want de XSS library ziet gewoon een integer en geen JS code en zal dat dus gewoon doorlaten.

Ja dat snap ik leuk allemaal, maar wat is de toegevoegd waarde? Het is toch duidelijk dat ik alleen maar uitwijs wat er standaard in ASP.NET Core zit? Een sanitizer is het minste wat je tegenwoordig verwacht van een taal. Om dan direct te zeggen dat ik in de war ben, nou dat is al heel wat hoor.

[Reactie gewijzigd door SizzLorr op 29 augustus 2017 22:31]

Snap het dan, een sanitizer has geen reet uitgemaakt.

"ASP.net Core ben ik niet bekend mee maar het zal waarschijnlijk minimaal een sanitizer hebben om waardes die je van de gebruiker krijgt schoon te poetsen"

Wat bedoel je dan met deze zin? Je doet het daar toch echt overkomen alsof het sanitizen verschil had gemaakt. Sanitizen heeft helemaal niets, maar dan ook niets, met deze bug bij AutoCash te maken. Ook al hadden ze de input gesanitized naar integers, dan nog was het lek daar.

Het gaat hier om een foute configuratie van een ACL of een variant daarop, dat is blijkbaar niet (juist) toegepast.

Nou vooruit:
"Als je "low level" te werk gaat, de waardes direct in een variabele stopt en dat verder gebruikt kan je zowat met elke taal dat doen"

Volgens mij valt hierover verder weinig te discussiëren, je reactie is in deze multi-interpretabel, maar aangezien je na die eerste zin direct over het sanitizen begint lijkt het erop dat je denkt dat dit een verschil had gemaakt.

Het gaat niet zozeer om het direct in een variabele zetten van een waarde, maar meer de controle stap die ontbreekt in de query zelf, of de ACL van de applicatie. Zoals @djiwie al aangeeft is een dergelijk probleem niet geheel automatisch te tackelen door een framework maar komt hier wel wat denkwerk van een programmeur bij kijken (al is het enkel het handhaven van conventies).

Waardes in een variabele stoppen is basis programmeren. Niks low level aan.

Onzin dat een framework #ID correlation voor je afvangt... er zijn scenario's waarbij #ID correlation juist niet verhinderd moet worden, omdat het soms wel handig is een numerieke logica te hanteren...

Faure
Anoniem: 105190
Anoniem: 105191
Anoniem: 105192
Anoniem: 105193
...etc...

Zou wat zijn als je framework aan de handrem trekt en dit soort geintjes onmogelijk maakt.

Beter match je de #ID in de URI gewoon tegen de #ID van de actieve sessie en exit() je als die twee niet overeenkomen... kan je het gewoon opeenvolgend maken, maar escape je de boel als er mee gekloot wordt.

[Reactie gewijzigd door b2vjfvj75gjx7 op 29 augustus 2017 22:16]

Exit()-en wil je ook niet. Stuur dan een forbidden response terug.

De exit wil je naast je statuscode in je header. Je wilt dat het script (uitgaand van php met exit..) stopt met de uitvoer. Zelf zou ik adviseren op geen kennis geven aan de gebruiker. Dus uniforme pagina teruggeven zodat je geen kennis geeft of id's bestaan. (id 1 bestaat dus 403, 2 bestaat nog niet dus 404, dan weet je wat volgend nummer is )

Wat mij overigens hier verbaasd is dat iedereen het terug legt op het framework. Dit heeft totaal niets te maken met het framework. Het framework is een handigheid wat bepaalde dingen uit handen neemt, echter ben jij als programmeur de gene die aan de knoppen zitten.

Vergeet niet dat menig programmeur graag zelf wat maakt. Het is cool en "ik kan het beter" mentaliteit spelen hierin een grote rol. Daarnaast niet vergeten dat een framework voor de grote massa kan werken, maar in jou scenario net geen uitkomst biedt. We weten niets van de vereiste van de software, de versies die gebruikt zijn en waar de koppelingen in zitten. Zo kan deze database door 2 systemen gebruikt worden waarbij update op dat moment niet mogelijk is.

Terugkomend op mijn punt, als programmeur ben je verantwoordelijk voor elke stap in de beveiliging. authenticatie, authorisatie, validatie input, validatie output. Hiermee heb je een groot deel van je beveiliging geregeld met betrekking tot de software.

[Reactie gewijzigd door eL-Prova op 30 augustus 2017 08:47]

Eindelijk iemand waarbij het iig lijkt alsof ie weet waar ie het over heeft. Verstandig is idd altijd een 403 terug te sturen zodat de gebruiker niet kan zien welke id's wel of niet bestaan. En ook het framework klopt als een bus, een framework helpt je een handje, maar het zal niet je werk voor je doen.

Ik zeg toch ook niet dat alle frameworks dat doen en dat je dat altijd moet gebruiken, volgens mij verwijs ik zelfs specifiek naar CMS frameworks waar dat juist wel gewenst is.

[Reactie gewijzigd door SizzLorr op 29 augustus 2017 22:17]

Klopt, maar #ID's niet opeenvolgend maken is net zo onveilig als ze wel opeenvolgend maken.

Het is hooguit security through obscurity, maar er zal altijd een logica in je #ID opbouw zitten (anders kan je er niet tegenaan programmeren) en elke logica kan afgevangen worden...

Volgens mij heb ik ook niet gezegd dat je ID moet obfusceren maar dat je aan ID correlatie moest doen, maar goed.

ID correlatie == Obfuscating

cor·re·la·tie (de; v; meervoud: correlaties) wederzijdse relatie, onderlinge afhankelijkheid

Overal zit een vorm van logica achter. Los daarvan zou je ook iets compleet willekeurig kunnen gebruiken. Gewoon je waardes in je database knikkeren.

Nee, beter gebruik je een ACL en zorg je voor mandatory access control. Dat wordt door zo'n beetje elk framework in elke taal wel standaard meegeleverd. Niet gebruiken == beunhazerij.

Een framework kan dat wel degelijk voor je doen op een manier dat je er zelf gewoon controle over hebt. Voorbeeldje met Spring Security

@GetMapping(value="/profile/{userId}")
@PreAuthorize("#userId == authentication.principal.id")
public String userProfile(@PathVariable String userId) {
}

Je geeft zelf aan dat je die checkt wilt, framework regelt de rest. De vraag zou meer moeten zijn "waarom moest die ID uberhaupt doorgegeven worden in de URL als het gaat om een ingelogde gebruiker?" Welke gebruiker ingelogd is weet je in de meeste gevallen serverside allang. Dan heb je geen ID nodig.

Anyway, het blijft gissen, want we weten allemaal niets van de internals van die applicatie en de code, maar knullig is het uiteraard wel dat het wijzigen van een ID in de URL tot dergelijke situaties kan leiden. Die valt wel behoorlijk onder de categorie http://watbenjedan.nl

[Reactie gewijzigd door Ronnerd op 30 augustus 2017 09:41]

Het kan natuurlijk zijn dat er wel een gebruikersnaam/wachtwoord gevraagd wordt maar dat bij het ophalen van een aanvraag niet wordt gekeken of die specifieke gebruikersnaam hoort bij de specifieke aanvraag.

Nee, het betreft een account van een autodealer. Gisteren werd gemeld dat ongeveer 80 dealers deze software gebruiken. Een autodealer kan met zijn inlog dus zijn eigen klanten bekijken en met de url-'hack' dus ook die van andere dealers.

Het hele stuk van RTL voelt nogal als opgeblazen en sensatiezuchtig aan. De gegevens liggen niet op straat, maar bij een relatief select gezelschap.

Natuurlijk is dit lek een kwalijke en serieuze zaak en de oorzaak een enorm knullige/amateuristische fout, maar de soep wordt niet zo heet gegeten als RTL doet voorkomen.

Schering en inslag. Je klantnummer +1 doen en op sommige autoconstructeur sites kan je de persoonsgegevens inzien van de klant na je. Initieel paswoord: rara. Erger: Je meld het en een jaar of twee later kan je het nog. Gelukkig zijn de flauwe grappenmakers zeldzamer dan brakke sites.

Schering en inslag. Je klantnummer +1 doen en op sommige autoconstructeur sites kan je de persoonsgegevens inzien van de klant na je. Initieel paswoord: rara. Erger: Je meld het en een jaar of twee later kan je het nog. Gelukkig zijn de flauwe grappenmakers zeldzamer dan brakke sites.

Al gemeld bij de Autoriteit Persoonsgegevens?

Bewezen framework heb je toch niet nodig om deze blunder te voorkomen? Dit soort fouten maakte je misschien in 1998. Dit is gewoon schandalig slechte. brakke programmering, en nog erger is dat ze er niets mee hebben gedaan.

Noem eens een framework die dit automatisch voor je doet?

Ook in 2001 zou dit compleet not-done zijn. SQL injections zou je in 2001 nog als excuus kunnen geven, maar het aanpassen van een nummertje in een URL, das echt heel extreem. Het probleem is dat je dan zelfs niet eens een IT kennis hoeft te hebben om het te hacken, elke leek kan het doen.

Wat een bullshit, je zal toch ergens een variable moeten getten anders kom je nergens.. dat zal dus sessiebase of URL based moeten zijn... je zal toch echt iets via je URL binnen moeten hengelen.

Hoe je dat intern afhandelt met je sessie informatie is vele malen belanrijker hoewel dit voor mij altijd key is geweest:

http://blogs.perl.org/use...ncrement-ids-in-urls.html

Auto incrementing id is kan opzich wel, je moet alleen wel een goed rechten systeem hebben stsan. Als iemand id 3 heeft, moet diegene een forbidden response krijgen wanneer ie naar id 4 gaat.

Ja logisch maar dat heeft dan ook met je ACL/sessie/whatever, hoe je checkt of die user daar mag zijn of die records mag zien, te maken.

Mensen die meteen gaan roepen dat een ID of een GET niet kan is echt belachelijk, die developers zijn mijn inziens altijd hard aan het roepen wat alle hispters doen, een ander napraten

Komt vooral neer op rechten en sessies idd. Een actieve gebruiker heeft een sessie met een token. Via die token kan een gebruiker met zijn/haar rechten worden opgehaald. Als iemand op een andere pagina dat die van henzelf terecht komt moet er een forbidden response worden terug gestuurd.

Ik ben niet echt een web developer, maar je moet nooit get gebruiken voor gevoelige informatie aangezien het in de url staat. Makkelijke verbetering zou zijn om een post te gebruiken waarbij het in de body staat maar volgesmij gebruiken de meeste betrouwbare sites een cookie met unieke (niet opteppende dus) security-id.

Een id moet juist in een get. Een post kun je niet in je favorieten knallen of linken met je beste vriend. Zelfs refreshen wordt een dingetje.

Maar dan zou je dat toch altijd combineren met een security ID die in een cookie wordt geplaatst?

Bijvoorbeeld, meestal krijg je een token van ong 60 karakters die gebruikt wordt, die wordt dan weer aan een sessie gekoppeld.

Beetje onduidelijk wat je precies "bullshit" van mijn post vindt, ook is het onduidelijk op welk deel je precies reageert. Ik heb het immers niet over hoe het zou moeten. Ik zeg alleen dat de gemaakte fout, waarbij een leek een URL kan aanpassen en daarmee het systeem kan hacken, wel heel extreem is.

Spring Security:

@RequestMapping(value="/profile/{userId}", method=HttpMethod.GET)
@PreAuthorize("#userId == authentication.principal.id")
public String userProfile(@PathVariable String userId) {

Ok, toegegeven, niet helemaal automatisch, maar 1 regel (@PreAuthorize) is all you need, want de rest is de mapping van een url naar een controller functie.

[Reactie gewijzigd door Ronnerd op 30 augustus 2017 09:47]

Een cms of Laravel hadden ook niks uitgemaakt. RBAC misschien.

Wat als ik nou een CMS heb die RBAC implementeert? Misschien zoals Laravel?

Laravel is geen cms maar een framework

Ooit wel eens gehoord van de klepel? (pun intended. (hihi) klokkenluider. deze grap heeft veel kanten )

Daarnaast is RBAC (waarschijnlijk) niet voldoende in deze situatie, RBAC staat voor **Role** Based access controle, in essentie krijgt iemand alleen toegang door lid te zijn van een groep.
https://en.wikipedia.org/wiki/Role-based_access_control

In sommige artikelen word echter ook gesproken over toegang toekennen aan een persoon/instantie, maar dit kan een oprekking zijn van de definitie. Dan kan je beter spreken over algemene toegangscontrole, en dan voor de situatie zelf kijken wat beter werkt.

ACL (in de breedste zin) is een mooie techniek maar voor sommige toepassingen echter te zwaar, als iemand alleen toegang mag krijgen tot iets dat onderdeel is van hun profiel dan kan je gewoon controleren of het onderdeel dat ze willen bekijken onderdeel is van hun eigen profiel. Daar heb je geen ACL voor nodig.

Als je interessant wilt gaan lopen doen zorg dan te minste dat je informatie klopt.

En PHPMaker is nu bepaald iets dat zou adviseren, dit soort autobuild oplossing zorgt alleen maar voor vendor-lockin en maakt het onmogelijk om de code zelf te kunnen beheren. Dan zou je beter kunnen kijken naar een platform oplossing, zoals OroPlatform. Uiteraard is dit ook geen volledige oplossing, maar een framework is dat ook niet. Als je alles op het framework bezeerd krijg alleen maar op de lange termijn alleen maar meer problemen, een goede applicatie is (bij gebrek aan betere woorden) plug-in gebaseerd waarbij de applicatie logica ("application") volledig los gekoppeld is van het framework, vervolgens maak je een koppeling van de applicatie naar het framework zonder dat de "application" af weet van het framework.

Dit is wat o.a. in Clean Code, en andere boeken voor grote applicaties word besproken. Als je echter een kleine applicatie hebt met die alleen informatie aanbied (zonder echter processen en verwerkingen) is alles aan het framework koppelen sneller en makkelijker, maar alleen dan!

[Reactie gewijzigd door s.stok op 30 augustus 2017 13:30]

Yes! Iemand die weet waar ie het over heeft. 🙇

Het punt is dat je ergens in je code zal moeten aangeven dat een identifier in een url overeenkomt met een user (zoals @Ronnerd hierboven mooi laat zien met een Java oplossing), en dan alleen die user toegang mag hebben tot die url. (Even los van dat het gebruik van een identifier in een URL lijkt me sowieso fout is als het gaat om het tonen van prive gegevens van de ingelogde gebruiker aan diezelfde ingelogde gebruiker, tenzij die gebruiker meerdere gebruikers kan beheren.)
Een volledig of bijna kant en klare oplossing als een CMS kan dat al ergens in zich hebben. Maar een CMS is dan ook geen *framework*. Een framework is over het algemeen te generiek om dergelijke rules of code standaard aangeschakeld te hebben, dat wilt een developer zelf kunnen beslissen, ook al kost het maar één regel code.

Dan een CMF, jij je zin. Ik ben een beetje klaar met deze non-discussie, wat maakt het uit welke code je gebruikt of wat je doet, het punt is dat als de coder moderne technieken had gebruikt dat hij veel had kunnen voorkomen. Dat de ene dan linksom en de andere rechtsom wil, dat interesseert mij niet.

[Reactie gewijzigd door SizzLorr op 30 augustus 2017 10:53]

Je had als crimineel ook een account kunnen kraken...

Wat heeft dat met dit te maken?

m.a.w. RTL Nieuws toonden aan dat in feite iedereen toegang tot iedereens gegevens had.. je had maar 1 accountje nodig.

Dat wil niks zeggen, heeft te maken met de privileges van het account wat je hacked. Stel ze hadden account van tiepmiep Linda, die ervoor moet zorgen dat alle gegevens worden bijgehouden dan had je dat ook. Sowieso wat ik zei, het bedrijf moet eens goed na gaan denken over die site. Dingen als VPN een captcha oid, allemaal geen overbodige luxes.

Daarnaast is er een verschil tussen iemand die zijn account afstaat en een account wat wordt gehacked.

[Reactie gewijzigd door SizzLorr op 29 augustus 2017 21:40]

Hoe moet je dan klokkenluiden op een veilige wijze?

Nou niet zoals RTL het doet, dat is duidelijk. Denk aan NCSC, wat hieronder werd aangehaald. Denk aan direct inschakelen van CBP. Of, gewoon geen toegang geven aan RTL en zelf laten zien dat het zo is. Dat RTL ineens mensen gaat bellen om de gegevens te "verifiëren", wat een onzin allemaal.

begrijp me niet verkeerd, ik vind het sowieso een kwalijke zaak dat een bedrijf zo slecht beveiligd is en een dergelijk verouderde site gebruikt, maar hoe het nou is gegaan verdient ook geen schoonheidsprijs.

Wat moet je dan doen als bedrijf x NIETS met die melding heeft gedaan?
CBP is een trage slak.. gaat eerst kijken of er mensen beschikbaar zijn.. zo ja.. dan wordt er een momentje geprikt wanneer onderzoek kan starten.
NCSC is alleen voor overheden..

CBP is een trage slak..

Hier kap ik de discussie af want dit soort ongegronde claims ben ik niet van gediend. CBP is sowieso verplicht om binnen 2 weken te reageren, punt!

Jij niet weten dat CBP mensen te kort heeft?
Politie/Brandweer/Ambulance moeten ook wettelijk binnen 15 minuten bij de gemelde locatie zijn.. wordt ook vaak niet gehaald.

Er zijn zoveel (overheids) instanties verplicht om binnen zoveel tijd te reageren, 9 van de 10 redden het niet binnen die tijd.

Dwing het dan verdomme eens een keer af via de kantonrechter of de ombudsman ipv hier te zeuren erover. Man man man man wat zijn er op Tweakers toch veel mensen die het zo goed weten maar geen details weg willen geven want "privacy". Als je weet hoe de wet en regelgeving inelkaar steekt dan ben je toch ook slim genoeg om dat af te dwingen...

Als jij mij het geld zou geven om een rechtzaak aan te spannen, prima.

Zelf ben ik niet bij machte om dat te kunnen betalen.

Nu kun je wel op mij gaan lopen tieren, maar dat helpt niet.. Stel je zelf ook alles aan de kaak?

Wat kost het om naar de ombudsman te stappen? Wat kost het om naar een kantonrechter te stappen? Ik zal je een hint geven, de afschrijving van je laptop.

[Reactie gewijzigd door SizzLorr op 29 augustus 2017 23:15]

Als je dan toch graag het lek aan de media meld, dan eerder een site als Tweakers het lek melden dan een toko als RTL Nieuws, die gaan er een stuk verantwoordelijker mee om en hebben toch de media kracht om er iets geforceerd aan gedaan te krijgen.

Aan de andere kant, in dit geval bestaat dit lek al jaren, laten we wel wezen, die 2 a 3 weken meer of minder van het CBP maken dan toch ook geen fuck meer uit.

Heb eerder vertrouwen in RTL dan in Tweakers imho.

Toch gek dat in t verleden via tweakers gemelde lekken een keurig artikel en een gedicht lek opleverde en bij RTL er 400 persoonsgegevens opgevraagd worden en mensen zelfs voor de sensatie worden opgebeld... nee, echt, vertrouwenswaardig

Houd toch op zeg, dat zeg ik toch nergens... maar in t verleden hebben de acties van Tweakers een stuk meer krediet opgebouwd dan dit trieste gedoe van RTL nieuws.... maargoed, veel succes met je stage daar ofzo, je tenen zijn veel te lang voor deze discussie :-P

Ik viel ook bijna van de bank af...
Resposible was t niet echt nee...filmen wanneer iemand het voordoet online, mensen opbellen met prive informatie, RTL Nieuws slaat even de plank totaal mis hier.

Zij zullen wel toestemming hebben gekregen he?

Vpn is niet handig, kunnen je klanten er ook niet in. Of je moet hem open zetten, maar dan had je er nog niks aan gehad.

Captcha heeft hier niets mee te maken.

Dus wat je nou zegt is dat dingen als VPN en Captcha niet helpen met beveiliging of hoe moet ik dit lezen?

VPN werkt erg limiterend, alleen als je geen klanten hebt voor het produkt maar dat je het bijvoorbeeld alleen zelf gebruikt. Captcha werkt al helemaal niet voor dit probleem.

Ik denk dat jij echt even terug moet naar de basisschool.

Mooie woorden van iemand die de basis niet kent.

Een rechter heeft eerder het oordeel gegeven dat het vinden en melden van een lek proportioneel moet gebeuren en buitensporige inzage in persoonsgegevens strafbaar is. Ik zie in de mededeling van RTL geen zorgvuldigheid als ze de gegevens van minstens vierhonderd mensen hebben ingezien voordat ze het genoeg vonden om aan te tonen dat er een lek was. Teleurstellend dat er hier op Tweakers slechts een kopietje van het bericht van RTL staat en er geen vraagtekens worden gezet bij dit soort details.

Je mag best ver gaan als journalist zijnde.. je mag kijken hoever je qua gegevens kan inzien.

Een journalist heeft veel vrijheid om misstanden aan te kaarten die van publiek belang zijn. Maar ook voor journalisten gaat op dat ze voor dat doel niet onnodig de grenzen over gaan van wat strikt noodzakelijk is. RTL geeft aan dat ze alleen een nummer hoefde te wijzigen om bij gegevens van een ander te komen. Dat hebben ze ruim 400 keer gedaan om van 400 personen de gegevens in te zien. Dat is volstrekt overbodig om te bewijzen dat je bij de gegevens van andere klanten kan komen.

Helemaal mee eens. Dit gebeurde ook met die van 50 plus. Die ging naar meerdere patientendossiers toe terwijl rechter aangaf dat 1 voldoende was geweest.
Linkje

Een journalist heeft veel vrijheid om misstanden aan te kaarten die van publiek belang zijn.

Heeft een journalist een grotere vrijheid dan een burger? Strafbare feiten mag ook een journalist niet plegen. Ja deze mag met de perspas vooraan achter het lintje staan bij een brand om goed verslag te kunnen. Maar heel veel verder moet de persvrijheid nou ook weer niet gaan.

Het lek is zo knullig als ik het zo lees. Een ID aanpassen in de querystring en je ziet de gegevens van iemand anders. Dan ben je als software ontwikkelaar zwaar tekort geschoten.

Niet alleen als software ontwikkelaar. Volgens Pon werden er op hun systemen regelmatig penetratietests uitgevoerd door een gespecialiseerd bedrijf. Ik ben wel benieuwd welk bedrijf dat is.
https://www.rtlz.nl/sites...2017/08/29/ponvw-blog.jpg

Ik ben wel benieuwd welk bedrijf dat is.

Zal wel van het niveau "zoontje van de baas" zijn. Geen enkel professioneel penetratie-tester zou het fuzzen van tokens in het URL pad of in de query string overslaan in de test procedures.

[Reactie gewijzigd door R4gnax op 29 augustus 2017 21:18]

Ligt natuurlijk ook een beetje aan wat je die toko mee geeft wat ze moeten testen.
als je een inlog code had (die je niet zomaar willekeurig aanmaakt maar vermoedelijk vrij speciaal na een process krijgt) kon je alles inzien, zonder inlog zag je helemaal niets, het lijkt mij niet heel ongebruikelijk dat van buiten af er alleen een test gedaan word zonder credentials en dan hadden ze dit simpelweg niet gevonden.

Tja, je test penetratie met een speciaal voor jou gemaakte inlog. Lekker logisch

wat wil je zeggen Aadje? Penetratie testen kunnen op veel verschillende manieren gebeuren... het is zo algemeen dat het niets zegt... als jij een tent de opdracht geeft je bedrijf 100% te onderzoeken, van binnen buiten, met en zonder credentials etc,etc,etc dan is er slecht werk geleverd. Zeg je tegen zo een toko dat ze alleen van buitenaf zonder credentials mogen testen zouden ze dit lek niet gevonden hebben (want als je ingelogd was kon je alle data raadplegen, zonder inlog zag je niets), dat wil niet zeggen dat die toko opeens prutsers zijn natuurlijk.

Als je alleen mag testen op bepaalde onderdelen dan zou ik als "tester" die opdrachtgever keihard in ze gezicht hebben uitgelachen!!

Ja, want we hebben een wet die inbreken verbied, dus niemand zal het in ze kop halen om in te breken toch? Een boordje bij het open keukenraampje met de tekst "niet binnentreden aub" en waarom testen we alle auto's uitgebreid voor ze weg op mogen?? OMDAT HET NOOIT GAAT ZOALS GEPLAND! Criminelen houden zich niet aan de wet, daarom heten ook criminelen

Als zelfrespecterend security bedrijf zou je deze opdracht niet aannemen of verbieden jouw naam te vermelden, want dit komt je geloofwaardigheid als Penetratie tester nu niet bepaald ten goede.

Dit is onderdeel van elke standaard basis (web) security check-up, iedereen die echt verstand heeft van pentesting of web development had dit probleem met een (gratis) standaard tool gevonden!

Als het probleem complexer was geweest had ik het nog kunnen begrijpen, maar dit is wel zo basic dat er gewoon GEEN Penetratie testing gedaan is door wie dan ook... het bedrijf in kwestie is waarschijnlijk gevraagd om iets proberen, en op basis daarvan heeft de opdrachtgever gezegd. Oke het is goed zo.

Wat een onzin en dat zeg ik niet.

Dit lek vind je alleen wanneer je een inlog hebt, de voordeur door bent, de gegevens waren niet publiekelijk inzichtelijk, het probleem was dat je gegevens die andere bedrijven indiende kon zien buiten je eigen , een inlog code die je onder specifieke omstandigheden kan krijgen, niet even online next-next-finish.

Als jij een pen testing bedrijf de opdracht geeft om vanuit holding niveau van buitenaf je netwerk te testen (zonder dus een inlog code te geven) dan is de kans vrij groot dat ze dit gewoon niet zullen vinden, want je moet tenslotte eerst de voordeur door zijn, geef je die toko de opdracht specifieke een applicatie na te pluizen dan hebben die ook steken laten vallen.

Doet niets aan af dat t een blunder van jewelste is van die web ontwikkelaars, maar dat is een ander verhaal.

Zeggen dat er op die manier geen pen-test opdrachten gedaan kunnen worden gaat ook niet op, op die manier gaan er genoeg.

Ik bedoel maar, security stopt niet bij de voordeur gebruikers kunnen immers ook kwade dingen uithalen.

I stand corrected, pen testing gaat puur over hacking, security auditing is een andere afdeling. Excuses

Tja, je test penetratie met een speciaal voor jou gemaakte inlog. Lekker logisch

Ja, want daarmee kun je kijken of een ingelogde gebruiker wel alleen die dingen kan doen die hij ook mag doen. Als Marietje van de receptie zichzelf eenvoudig admin kan maken heb je ook een security-probleem

Een beetje ' ' ' penetratie-tester' ' ' zou dit nog geprobeerd hebben.

Het zou mij niet verbazen als dit ook gemeld is door de tester maar er niks meegedaan is. Tenslotte deden ze ook niks met het mailtje van de ontdekker, pas nadat het in het nieuws kwam.

Het kan net zo goed zijn dat het lek pas net geïntroduceerd is. Dit hoeft dus nog niet door een tester getest te zijn.

Helemaal mee eens, een Owasp test had dit gewoon aan het licht gebracht.

Ja de gegevens zijn gelekt, maar ik vond het niet normaal dat de journalist van RTL doodleuk mensen ging bellen om te vragen of ze inderdaad auto X reden en Y euro per maand verdienden.

Op die manier is het vooral sensatienieuws, dat is typisch RTL.
Het zou nog kunnen dat het op voorhand is afgesproken en voor de beeldvoorming is maar dat was uit de beelden niet op te maken en werd ook niet benoemd.

Hoor en wederhoor noemen ze zoiets, de gegevens had hij toch al...

Dat heeft niets met hoor en wederhoor te maken.
Hoor en wederhoor komt er op neer dat ze de melder horen en vervolgens met het bedrijf gaan praten. Dat hebben ze hier niet gedaan. In plaats daarvan zijn ze meteen publiek gegaan, lijnrecht tegen het principe van hoor en wederhoor in. Dit heeft, daardoor, dus niets met journalisme te maken en alles met riooljournalistiek.

Dan heeft RTL wel gedaan, alleen je hoort en ziet natuurlijk niet alles.. zij lieten dat enkel zien dat de gegevens valide waren.. dus 100% kloppen.

Daarvoor hoef je niet de privacy van minimaal 400 mensen te schenden.
Je kan ook na de eerste of tweede stoppen, als je weet dat het echt lek is.

Waar staat dat ze 400 mensen hebben gebeld? Ze hebben zeker gegevens van 400 mensen ingezien. Dat kan betekenen dat ze een lijst hebben ontvangen met zoveel records, wat niet per se betekent dat ze stuk voor stuk zijn nagelopen.

Inzien is ook schenden.
Om te schenden hoef je niet de mensen te benaderen.

"RTL Z heeft naar eigen zeggen in korte tijd de gegevens van minstens vierhonderd mensen ingezien via het lek"

Ze hebben het dus zelf gedaan.

De journalist is niet degene die schent en ook de hacker niet. Verder probeer je wat ik stel onderuit te halen door precies hetzelfde te schrijven.

De journalist is de hacker want hij gebruikt het lek.

Ook al zou hij een lijst gekregen hebben, dan had hij nog niet bij 400 accounts hoeven inloggen.

De manier hoe dit lek werkt hebben ze 400x een oproep gedaan en daar een onbekend aantal bestanden van gedownload (sommige zelfs nog geprint, over de redactie gegaan en nagebeld...) nee, nogal buitensporig checkje dit.

Als journalist wil je weten hoe ver je kan gaan.. toen ik x aantal jaren geleden een lek zag op de site van amsterdam testte Of ik dingen kon uploaden;
dat antwoord was ja, dus heb ik eerst een normale .txt en .jpg bestand geupload... hierna ging ik een nep-virus bestandje uploaden en ook dat bleek te werken.

Dat heeft niets met journalistiek te maken maar meer met het belang wat je als journalist wil dienen. Het belang wat RTL hier brengt is dat ze aantonen dat er een lek was. Daar hoef je niet van 400 personen de gegevens van te downloaden om dat te bewijzen. Als RTL wilde aantonen wat er lek was dan hoeven ze ook niet van 400 personen de gegevens te downloaden.

Dat slaat dus nergens op, wat ik verwachtte is dat bij het virus bestandje.. er wel alarmpje zou afslaan.. RTL wist toen de site zelfs te defacen.. want heb het toentertijd doorgespeeld aan RTL.
Je weet immers niet of de gemeente aangifte gaat doen tegen persoon x.

Tja, als jij een .HTML in de index kunt uploaden en de webserver niet helemaal lekker geconfigureerd is heb je al een 'deface' te pakken, dat hoef je niet daadwerkelijk met een index.htnl te gaan doen. Een PHP en HTML uploaden als check is dan voldoende

RTL is ook zielig naar mijn mening, ik kan ze niet serieus nemen. Er worden zo vaak artikelen geplaatst met (spel)fouten. Ook doen ze aan dingen zoals clickbaits enzovoort. Ja, ze zijn commercieel maar dat kan ook op een nette manier. (Sorry, beetje off-topic.)

Spel/ schrijffouten worden helaas overal gemaakt ook hier op Tweakers. Heb al een aantal keren met redactieleden van andere kranten discussies gehad waarom er geen spellingscontrole gedaan wordt gezien de vele schrijffouten. Vinden ze irritant. Ik erger me groen en geel aan die schrijffouten. Ik weet het ik maak ze zeker weten ook, maar ik ben maar een lezer, geen journalist.
RTL is een sensatie tv station.
Maar dat dit mogelijk is, is natuurlijk erg genoeg. Zeker ook dat er na een melding niets aan gedaan wordt. Wel weer als RTL het meldt maar dan is het te laat.

Op zich zijn spelfouten geen probleem, zolang er na (netjes) melden iets mee gedaan wordt.
Ik let er in een professionele omgeving ook op. Maar het gaat mij vooral om hoe met kritiek omgegaan wordt, dat zegt meer over iemand en hoe je hem/haar kan beoordelen.

Maar ontopic: dit is één van de redenen hoe belangrijk privacy dus is. Ik ben zelf helemaal niet spannend, maar ik zit er niet op de te wachten dat mijn naw-gegevens, telefoonnummers en maandelijkse krediet- of leasekosten en rekeningnummers in te zien zijn, laat staan mijn netto maandsalaris of de hoogte van de huur of hypotheek die ik betaal. Nee ik heb het (in principe) niet te verbergen, maar waarom zou je het moeten weten? Ga je er geld mee verdienen? Met mijn gegevens (ja, mijn als in: niet van iemand anders ?).

Privacyhonger is het laatste jaar een hele nare trend geworden. Facebook wil alles van je weten (let op, ze hebben Whatsapp...), bedenk je wel dat ze bijna 4 miljard dollar verdienen. Per kwartaal...
Google: maakt 70% winst op Android. Kost je wel je privacy en je mag reclame kijken in apps .
Microsoft? Tsja...Windows 10 is berucht om de privacyschending. Ik vermoedde al een addertje onder het gras dat gebruikers met een illegale versie van 8(.1) "gratis" konden upgraden.

Maar...wat dan?
Facebook zul je moeten schrappen. Sorry.
Google: neem een alternatief op Gmail en als je durft, ga binnenkort over op Sailfish van Jolla (ook veel Android apps kunnen daarop draaien).
Microsoft: Ubuntu?
Whatsapp: Signal.

Ik ben best wel klaar met de privacy en advertentiehonger. Hoe langer ik met een privacybril of advertentiebril kijk, hoe meer en meer het blijkt hoe ver we het hebben laten komen...

Ik erger me groen en geel aan die schrijffouten. Ik weet het ik maak ze zeker weten ook, maar ik ben maar een lezer, geen journalist.

De taak van een journalist is niet letten op een correcte spelling, maar feiten verzamelen over gebeurtenissen van algemeen belang. Schrijffouten die niet voor verwarring zorgen zouden geen probleem moeten zijn (al staat het netter om een correcte spelling te hanteren), ik vind het belangrijker dat zo'n persoon een juiste en complete verslaggeving verzorgt.

De taak van een journalist is niet letten op een correcte spelling,

Nee niet van de journalist op zich - hij kan wel zijn best doen-, maar van de redacteur.

[Reactie gewijzigd door Euronitwit op 30 augustus 2017 17:56]

Je kunt in ieder geval niet ontkennen dat ze niet aan verificatie van hun bron/gegevens doen

Leasemaatschappijen leken zeer slecht beveiligd en het interesseert ze weinig. Volgend jaar worden er miljoenenboetes uitgedeeld door de AP, kijken of er dan wel wat veranderd.

Veel leasemaatschappijen hebben een bankvergunning. Je zou verwachten dat die al langer aan strenge beveiligingseisen moeten voldoen en inmiddels de boel op orde hebben.

Alleen LeasePlan heeft naar mijn weten een bankvergunning. Zeker niet alle leasemaatschappijen hebben een bankvergunning.

RTL Z heeft naar eigen zeggen in korte tijd de gegevens van minstens vierhonderd mensen ingezien via het lek.

Kan iemand me uitleggen in hoeverre dit nog een geval van responsible disclosure is? Bij het melden van een lek lijkt het me niet direct de bedoeling om verder te gaan dan nodig is om het lek aan te kaarten. Wanneer RTL Z daarentegen gegevens van minstens 400 personen bekijkt via die manier lijkt het me al snel onder computervredebreuk te vallen aangezien 2 of 3 records al voldoende lijken om het lek te bewijzen.

EDIT:
Nog een leuke vanuit het RTL Z artikel:

Zo zien we bijvoorbeeld de privégegevens van een 41-jarige Amsterdammer. Hij verdient 1759 euro netto en heeft een huur van 572 euro per maand. Voor 186 euro in de maand betaalt hij in vijf jaar een Mercedes af, waarbij hij een aanbetaling van 5520 euro heeft gedaan.

In hoeverre valt dit wel of niet onder privacyschending door RTL Z? Hier worden namelijk behoorlijk specifieke gegevens over een persoon verstrekt (al wordt niet een naam of specifiek adres opgegeven).

[Reactie gewijzigd door stuiterveer op 30 augustus 2017 10:16]

Zag net ook deze voorbij komen mbt lekken: https://www.troyhunt.com/...ord-onliner-spambot-dump/

Ik had dit trouwens al een tijdje geleden gezien door een willekeurig Twitterprofiel dat ik tegenkwam op Google toen ik zocht op "Troy Hunt". Ik had overigens mijn ouders al ingelicht. Hier de Tweet waar ik het over heb: https://twitter.com/verheijenrob/status/894788832280948736
En hier een screenshot uit mijn chrome geschiedenis:
https://i.fl0.co/a4akkf.png

Backup van de screenshot is hier te zien, mocht de hoster ophouden met bestaan in de toekomst:
http://i.imgur.com/XU5WrsV.png

Ik vond het nogal raar dat het op Twitter, maar nergens op andere media, zoals op het nieuws, stond. Op zich best wel interessant hoe social media dat soort info eerder kunnen verspreiden dan andere media.

Moraal van deze comment: altijd social media afspeuren naar interessante content en als het nergens gemeld is melden.

Update: dit ging over een ander lek, dat overigens niet op Tweakers.net was gemeld.

[Reactie gewijzigd door TheRealProcyon op 30 augustus 2017 13:24]

Uiteraard wordt autocash opgenomen in m'n zwarte lijst - bij deze weten zij dat.