Actiesite Kleenex had datalek door debugbalk onder in beeld

Een actiesite van tissuemaker Kleenex had een datalek. Kwaadwillenden konden de gegevens van klanten onderscheppen doordat de ontwikkelaars van de site de debugbalk onder in beeld hadden laten staan. Inmiddels is dat niet meer het geval.

De debugbalk onder in beeld liet alle verkeer van en naar de server zien, zegt lezer Torrentus tegen Tweakers. "Zo kon je filteren op POST-verkeer naar de 'je-gegevens'-url en liepen de adresgegevens in platte tekst over het scherm." Tussen die gegevens zitten geen wachtwoorden, maar wel fysieke adressen en e-mailadressen.

De site MijnKleenex.nl hangt aan een actie, waarmee klanten een gratis verpakking van tissues kunnen krijgen. De actie is sinds donderdag actief en trok op het moment van schrijven ongeveer achtduizend geïnteresseerden uit België en vijfduizend uit Nederland. Die gegevens waren te zien, doordat de statistiekenpagina ook openbaar online stond. Ook dat is inmiddels niet meer het geval.

Backbone Marketing bevestigt namens Kimberly Clark, het bedrijf achter Kleenex, dat het lek bestond. "De debugbalk heeft inderdaad even online gestaan toen de actie live ging. Dat had niet moeten gebeuren."

Reacties (83)

[Barryvdh]

Komt van https://github.com/barryvdh/laravel-debugbar maar iemand heeft mijn instructies dus niet goed opgevolgd
Normaal gesproken installeer je hem als 'dev' dependency (composer require barryvdh/laravel-debugbar --dev) en installeer je die, net als andere dev-dependencies (phpunit etc) niet op je productieserver.

Daarnaast moet je APP_DEBUG instelling op 'true' staan, wat niet hoort op productie, want dan krijg je namelijk ook die mooie Whoops foutmelding, in plaats van een nette melding.

[juggle]

Zo te zien lijkt het erop dat op de productie omgeving de APP_DEBUG aan stond aangezien ook de Whoops foutmeldingen te zien waren. Ik dacht alleen dat Laravel deze Whoops nu vervangen had door de Symfony foutmeldingen dus Whoops is waarschijnlijk zelf door de programmeurs erin gezet (mits deze een recente versie van Laravel hebben gebruikt.)

Wat nog veel vervelender is dat Whoops ook alle ENV variabelen uitspuugt. Aangezien het een best practice is om API tokens, wachtwoorden voor services van derden etc in de ENV op te slaan waren deze dus ook voor iedereen zichtbaar die de Whoops foutmeldingen kreeg. Maw; ook alle wachtwoorden en andere services die de Kleenex website heeft gebruikt moeten de toegangsvariablen voor gewijzigd worden.

Ik lees hier verderop in de comments dat ALLE post requests zichtbaar waren? Dat gaat dan vermoedelijk via de log files die de debugbar kan uitlezen neem ik aan?

[Reactie gewijzigd door juggle op 22 juli 2024 13:30]

[Barryvdh]

Debugbar slaat de requests van de afgelopen 24 uur op, om ze eventueel terug te kijken achteraf (of als ze niet via die browser gemaakt zijn zoals webhooks en API requests). Via de debugbar kan je deze inladen, zodat je precies dezelfde informatie ziet voor een bepaalde requests, zoals je die ook ziet voor je huidige request (queries, post informatie etc)

[DJVG]

Ik mis even waarom de debug balk nu de reden van het datalek was, deze gegevens zullen waarschijnlijk ook in te zien zijn geweest bij de POST zelf. Het gebeurd dan weliswaar op de achtergrond, maar volgens mij is de debug balk niet meer dan een tool om het makkelijk inzichtelijk te maken. Het is niet netjes, maar volgens die logica betekend het dat elke POST een datalek is.

[Reactie gewijzigd door DJVG op 22 juli 2024 13:30]

[Torrentus]

De reden is dat je niet alleen je eigen POST-request zag, maar alle POST-requests die op de server binnen kwamen. Dat waren POST-requests van alle mensen die het formulier invulden, maar ook van de ontwikkelaars die op de live-omgeving aan het programmeren waren. Middels die laatste set requests vond ik de URL's van de backoffice pagina's inclusief de sleutel die nodig was om die te benaderen. Toen ik die een paar keer F5'te kwam ik op een gegeven moment op de errorpagina uit de laatste screenshot (programmeerfout) waar de server alle environment-variabelen toonde. Die bevatten naast de inloggegevens voor de achterliggende database ook de AES-encryptiesleutel voor de data in die database. Daarmee lagen alle gegevens dus eigenlijk op twee manieren open en bloot 'op straat': enerzijds realtime door de sessies van anderen die voorbij kwamen, anderzijds alle eerder ingevulde formulieren via de database. Ik heb overigens geen poging gedaan die database te lezen, maar dat moet met bovengenoemde gegevens geen probleem geweest zijn.

[Aaargh!]

Dat roept meteen een heel aantal extra vragen op:

• Hoe komt die (client-side) debug balk bij de POST gegevens van andere users, dat kan dus alleen als de server een API beschikbaar stelt om deze te kunnen opvragen, blijkbaar ook nog eens zonder authenticatie.
• Waarom zijn er ontwikkelaars op een live omgeving aan het programmeren. En waarom kunnen ze überhaupt bij de live servers ?

[juggle]

1. Waarschijnlijk kan de debugbar de log files uitlezen en daarin stonden dus ook alle requests gelogd die uitgevoerd werden op de server omdat deze op debug modus stond. Nee, zie antwoord in reactie van Barryvdh
2. Vermoedelijk een foutje door de programmeurs in de deploy scripts. Of er is (lijkt mij sterk overigens) echt iemand handmatig wezen ftp-en van de dev omgeving naar de live server waardoor je dus een 1 op 1 kopie krijgt van de ontwikkelomgeving.

Vermoedelijk dus, ik ben geen ontwikkelaar voor genoemde website :-)

[Reactie gewijzigd door juggle op 22 juli 2024 13:30]

[Barryvdh]

Debugbar kan zijn requests opslaan op de server, zodat je bijvoorbeeld vorige requests kan bekijken als er iets fout ging, of om te zien welke queries er toen uitgevoerd zijn. Ook voor requests die je niet in de browser doet zelf (ajax/api requests, webhooks etc). Maar normaal doe je dat alleen op je ontwikkelomgeving, nooit op live.

[DJVG]

Kijk, dat is belangrijke informatie die ik mis in het artikel (ik ken de laravel debug env. verder niet). Bedankt!

[nickelz]

Precies. Je eigen POST-request is niet erg, maar dat je alle kon zien, vind ik absoluut een lek..

[Munters]

Heb je wel een poging gedaan om hun programmeerfout op te lossen?

[Fnatic]

Inderdaad, goede informatie voor leken onder ons!

Dank je wel Torrentus!

[YopY]

Ja wat er in het artikel mist is dat het om een debug optie voor het gebruikte back-end framework gaat, dwz een back-end debug tool, niet de front-end debug tool die in je browser zit. Ook voor het eerst dat ik zoiets zie trouwens.

[Aaargh!]

Waarom zit zo'n tool niet op een compleet andere URL en poort ? Waarom een balk in de normale pagina ? Ik snap dat een debug omgeving voor de server handig kan zijn, maar waarom moet dat als onderdeel van de front-end UI ipv dat je b.v. gewoon een debugger attached aan je server ?

[Noxious]

Dergelijke tools gebruik je enkel op testomgevingen en/of tijdens de ontwikkeling.

Enorm slordig en amateuristisch dus dat dit in productie gekomen is.

[Aaargh!]

Dergelijke tools gebruik je enkel op testomgevingen en/of tijdens de ontwikkeling.

Precies, en daarom zet je zoiets op een niet-standaard poort die op de productie omgeving dicht staat, zodat ALS er per ongeluk een debug versie gedeployed wordt er nog niets aan de hand is.

Je wilt voor dit soort dingen altijd meerdere failsafes.

[Noxious]

Zoiets kun je prima op een standaard poort draaien (dat heeft niets met veiligheid te maken), maar draai je simpelweg op een andere omgeving.

Je veiligheid door het niet 'per ongeluk deployen van een debug versie' haal je uit CI-technieken (dmv geautomatiseerde deployment naar live en tests).

[Aaargh!]

Je veiligheid door het niet 'per ongeluk deployen van een debug versie' haal je uit CI-technieken

Ook, maar niet als enige.

[Zoop]

De debug balk geeft ook uitgebreide informatie over exception errors, uitgevoerde queries (en welke dat waren), server side variables/directories/files/classes enzo die gepassed worden aan de template renderer, er vallen flinke stukken broncode uit te herleiden (zie laatste screenshot), etc etc

[Reactie gewijzigd door Zoop op 22 juli 2024 13:30]

[NielsNL]

De debug-balk onderin beeld liet alle verkeer van en naar de server zien

Oftewel niet alleen jouw POST, maar alle POSTs op de server.

[Neko Koneko]

8000 Belgen en 5000 Nederlanders die een gratis pak tissues willen hebben? En die Belgen altijd maar zeggen dat Hollanders zo zuinig zijn

[RangedNeedles]

Hey! Misschien liep de actie in België wel eerder dan in Nederland of is het bij ons gewoon meer gepromoot geweest

Maar even serieus, snap ook niet dat er 13.000 mensen al die persoonlijke gegevens afstaan voor maar één pakje tissues? Zoiets schreeuwt toch gewoon "wij gaan je vanaf nu continu spammen en bellen"?

[FreezeXJ]

Genoeg mensen die daar vrolijk in meegaan, vraag Albert Heijn maar (bonuskaart), of zat andere winkels en locaties die gegevens hamsteren in ruil voor cadeaubonnen, kortingen, zinloze hebbedingetjes of gewoon een winkans (van 0.0 ofzo).

Blijkbaar vinden genoeg mensen hun gegevens niks waard.

[YopY]

AH is best naar, die geven alleen korting met een bonuskaart. Je kunt een anonieme bonuskaart krijgen (gewoon vragen, hij werkt zonder dat je je gegevens achterlaat), maar dan nog kunnen ze meerdere aankopen aan 1 unieke gebruiker hangen.

[84hannes]

offtopic:
Ik heb die kaart een tijd lang bij het verlaten van de winkel weer teruggegeven aan de klantenservice. Maar wees blij dat het kan; in Zweden koppelt vrijwel elke winkel (tot de apotheek aan toe) je klanten'kaart' gewoon aan je persoonsnummer. Voordeel: je hebt geen honderd losse pasjes nodig. Nadeel: vul zelf maar in.

[.oisyn]

Dat kunnen ze ook zonder bonuskaart, als je met pin betaalt. Overigens mag je ook gewoon vragen om de bonus zonder kaart (in de praktijk betekent dat dat de cassiere zijn eigen/een speciale kaart gebruikt).

[Xfade]

Eigen kaart is verboden, mederwerkers krijgen nl. 10% van het betaalde bedrag terug. (tot een max van 75 euro per kwartaal). De code die daarvoor gebruikt wordt is een interne code, welke ze trouwens ook niet meer mogen gebruiken officieel.

[batjes]

Bij de AH hier pakken ze gewoon de eerste nieuwe bonus kaart uit het bakje voor hun, die elke kassa heeft.

[Xfade]

Dat is opzich wel een prima optie idd.

[Xfade]

Vraag gewoon een bonuskaart en vul verder niks in. Klaar. Ze mogen en zullen geen koppeling maken tussen jouw pinpas nummer en die anonieme bonuskaart.

[.oisyn]

Dat je je persoonlijke gegevens bij de ah bonuskaart op kán geven wil niet zeggen dat dat ook verplicht is. Dat ze ondertussen een profiel maken adhv wat ik koop, tja, #care, zolang het maar niet naar mij terug te voeren is.

[Reactie gewijzigd door .oisyn op 22 juli 2024 13:30]

[Quacka]

je betaalt altijd contant?

[.oisyn]

De AH mag helemaal geen koppeling naar een persoon maken op basis van jouw pinbetalingen. Dus nee, dat doe ik niet en dat hoeft ook niet.

[Quacka]

Dat wist ik niet. Heb je meer info hierover?

[.oisyn]

Privacyverklaring van de AH zelf:

quote: https://www.ah.nl/privacy#2-3-privacy

2.3.1 AH Bonuskaart
Met een AH Bonuskaart kun je profiteren van de landelijke Bonusaanbiedingen. Je kunt een AH Bonuskaart verkrijgen aan de servicebalie van iedere winkel van Albert Heijn. Wanneer je een AH Bonuskaart ontvangt, kun je deze direct gebruiken en ontvang je direct de landelijke Bonuskorting aan de kassa. Een AH Bonuskaart die je direct in gebruik neemt, is niet herleidbaar tot jou, tenzij je je AH Bonuskaart persoonlijk maakt door 'm te activeren of je online hebt ingeschreven voor functionaliteiten of extra Services zoals online bestellen of de Sleutelservice).

Je hoeft geen persoonsgegevens aan Albert Heijn te verstrekken om de algemene Bonuskorting te krijgen. Wanneer je bij het betalen van boodschappen in een winkel van Albert Heijn je AH Bonuskaart laat scannen, dan verwerken wij de aankoopgegevens die op de kassabon staan, zoals het moment waarop de aankoop heeft plaatsgevonden, de betreffende Albert Heijn winkel, gekochte artikelen en bijbehorende bedragen, acties/verkregen kortingen, het AH Bonuskaartnummer en wijze van betaling. Deze aankoopgegevens zijn echter niet herleidbaar tot jou als persoon, omdat wij niet beschikken over je naam en adresgegevens.

Let op: als je met een vraag of klacht contact opneemt met onze klantenservice en je Bonuskaartnummer en contactgegevens opgeeft, beschikt Albert Heijn dan ook over je contactgegevens. Deze persoonsgegevens worden door ons in dit geval alleen voor het afhandelen van je vraag of klacht gebruikt en zijn alleen toegankelijk voor degenen binnen Albert Heijn die zich met de afhandeling daarvan bezighouden. Deze gegevens worden dus niet gebruikt voor het doen van aanbiedingen (tenzij je je daarvoor in ander verband specifiek hebt ingeschreven).

Let op: als je in verband met én vraag of klacht contact opneemt met onze klantenservice en je AH Bonuskaartnummer opgeeft, beschikt Albert Heijn nu ook over je adresgegevens. Deze persoonsgegevens worden door ons in dit geval alleen voor dit doel gebruikt en zijn alleen toegankelijk voor degenen binnen Albert Heijn die zich bezig houden de afhandeling van je vraag of klacht. Deze gegevens worden dus niet gebruikt voor het doen van aanbiedingen (tenzij je je specifiek hiervoor hebt ingeschreven).

Dat ze het niet mogen zonder vooraf gegeven toestemming volgt overigens gewoon uit het WBP.

[Reactie gewijzigd door .oisyn op 22 juli 2024 13:30]

[JustFogMaxi]

Precies, al die gegevens afstaan voor een pak tissues, nee dank je.

[-ION-]

Ik neem aan dat een beetje tweakers sowieso altijd nep-persoonsgegevens invult bij dit soort acties.

[S-Face]

Tja, en waar kom je dan uit?..

[YopY]

Schuldig

[bazs2000]

Even gelezen en verdorie, had ik dit jaren geleden maar geweten. Vele databases met testdata gevuld en ik weet zeker dat ik ook deze postcode heb gebruikt. De data kwam nooit in de echte omgeving terecht maar ik weet van situaties waar dit daadwerkelijk is gebeurd.

Dat van die callcentra herken ik ook. Ik heb eens in een callcenter gewerkt en daar moest je bij de training gegevens overnemen met deze postcode en T. Test. Brrrr, ik vrees dat deze mensen in het verleden weleens wat enveloppen hebben gekregen waarbij ik betrokken ben geweest.

[S-Face]

Inderdaad, ik had er ook nooit over nagedacht tot ik dit artikel las. Super triest voor die mensen natuurlijk dat hun diensten worden afgesloten tijdens vakantie.

Maar ik zou wel helemaal stuk gaan denk als er post voor Piet Piemel door de bus komt

[Verwijderd]

Daar heb je vrij weinig aan gezien ze het naar je adres toe sturen

[-ION-]

Uiteraard voor dit soort acties wel je eigen adres opgeven, maar mijn naam, emailadres of telefoonnummer krijgen ze niet.

[S-Face]

Ik vind dat ze de benadeelde mensen zouden moeten compenseren met nog 1 pakje Kleenex om hun traantjes te drogen.

[Anonymoussaurus]

En dan te bedenken dat België ongeveer 6 miljoen minder inwoners heeft, namelijk 11.491.346.

[RobinJ1995]

Ik herken direct Laravel debug bar, dus volgens mij betekent dat ook dat ze hun environment niet op production hadden gezet.

[Qoncritter]

Daarbij komt nog dat de error handler Whoops is welke in de dev dependencies staan. Op productie is het de bedoeling dat je "composer install --no-dev" draait.

[Olaf van der Spek]

Is dat een design bug in composer? IMO zou --no-dev de default moeten zijn.

[NMe]

Het probleem zit hem erin dat Laravel blijkbaar voor zijn environmentconfiguratie afhankelijk is van wat Composer zegt. Stiekem is dat gewoon debiel, je environmentconfig moet niet afhankelijk zijn van wat er geïnstaleerd is, wat geïnstalleerd wordt moet afhankelijk zijn van je environmentconfig. Dit is een van de vele dingen die Laravel gewoon verkeerd opgebouwd heeft, IMO.

[supersnathan94]

nee hoor, Op productie moet je gewoon altijd uitkijken wat je doet. Daar heb je immers environment profiles voor die je gebruikt voor het draaien van dit soort installaties. Zo'n deployment gaat ook niet via filezilla oid. Daar zit waarschijnlijk een buildserver achter met een knopje voor deployment. Dat knopje zou moeten weten dat --no-dev aan moet staan.

[Olaf van der Spek]

nee hoor, Op productie moet je gewoon altijd uitkijken wat je doet.

Natuurlijk, maar door deze keuze is er weer een extra iets dat fout kan gaan.. foute keuze dus.

[supersnathan94]

Nee niet. Dit stel je namelijk eenmalig in op je buildmachine terwijl je een nieuwe developer dan weer moet gaan uitleggen dat je --wel-dev oid moet gebruiken.

Composer is stiekem helemaal niet bedoelt voor dit soort dingen, maar juist voor development doeleinden een soort maven voor PHP waarmee je eenvoudig dependencies kan beheren om uiteindelijk je gehele package te bouwen die je naar productie zet. Al deze bouwtools zijn bedoelt voor ontwikkelaarsdoeleinden en niet per se voor productie omgeving. Zodoende bouw je een product java applicatie ook met mvn optie -`Dmaven.test.skip=true` Hiermee worden alle test packages niet compiled en toegevoegd. standaard wil je dit juist wel, omdat de tests ervoor zorgen dat er iets omvalt als ze per ongeluk gedraait worden en de code is nog niet klaar. Terwijl je anders doodleuk groen licht krijgt omdat je tests niet falen (omdat ze niet gedraait worden).

Het idee is juist dat je zoveel mogelijk analyses uitvoert bij default dat mocht er halverwege 1 uitklappen door een fout dat je dan niet per ongeluk toch doorgaat naar productie met die code.

[aikebah]

Ik hoop dat jij nooit mijn collega wordt.....

Voor het maken van de productie-versie van software met maven gebruik je absoluut niet de optie -Dmaven.test.skip=true... dat doe je hooguit tijdens development omdat je weet dat de boel nog niet helemaal compleet is en een aantal testcases de build zullen laten falen, maar je toch graag een binary wilt om jouw beperkte stukje feature even op je eigen dev-omgeving te testen.

@Olaf van der Spek heeft helemaal gelijk dat het moeten opgeven van een extra optie voor het productie-profiel een foute ontwerpkeuze van het build-tool is. De default moet zijn om productie-artefacts te brouwen. Een developer zet in haar/zijn IDE standaard een extra optie aan om in plaats daarvan een dev-time artefact te bouwen. Dat is hoe je een build-tool op een security-minded manier opzet.

[supersnathan94]

Ik hoop het eigenlijk wel. Kunnen we een hoop van elkaar leren en over dicussiëren. Waar werk je momenteel als ik vragen mag?

Nee dan heb je je bouwstraat verkeerd ingericht als dat je build laten falen op feature niveau. Unstable is dan de juiste manier. Falen vanwege unittests nooit. Je overige analyses worden dan nooit uitgevoerd dus je weet dan niet wat je wat je overige analyses voor resultaat geven. Maar dat is een ander verhaal.


Mijn productie container hoeft never nooit geen testcode te bevatten. En die hoeft dan ook nooit mee gecompileerd te worden. Waarom zou dat doen? De productie omgeving maakt daar geen enkele keer gebruik van en als mijn compilatie faalt doordat er bepaalde klassen in die testcode nodig zijn heb ik de dependencies verkeerd gezet.

Uiteraard ligt het ook aan je manier van ontwikkelen. Als je TDD gebruikt wil je juist dat er tests falen tijdens het draaien van je tests in je pipeline. Dan kan je namelijk met plugins bijhouden in diezelfde pipeline wat de voortgang van je feature is en hoe snel je mogelijk de complete feature kunt opleveren.

Builds falen op unittests is vrijwel nooit goed. Builds niet laten slagen is een ander verhaal.

Edit: als je wil weten waarom en hoe je die pipelines op een “juiste” manier kan inrichten kan ik dat best hieronder even neerzetten. Heb ik namelijk vorige week geheel uitgewerkt.

[Reactie gewijzigd door supersnathan94 op 22 juli 2024 13:30]

[aikebah]

Je hebt helemaal gelijk dat een productie-container geen testcode hoeft te bevatten (het is mijns inziens zelfs nog sterker: het mag geen testcode bevatten). Maar je had het over een Java-applicatie. En standaard-gedrag van Maven voor Java is dat er een losse applicatie (zonder testcode, gebaseerd op de src/main structuur) en een losse test-jar (de gecompileerde testcode, gebaseerd op de src/test structuur) gemaakt worden.
Een goede container pipeline zou naar mijn mening pas in beeld komen na een succesvolle build+unit-test van de java componenten en in het bouwproces gebruik maken van de (productie-code only) binaries geproduceerd door maven voor de java--projecten.
En een snapshot-build mag inderdaad unstable worden (doet hij bij ons ook) door een testfalen, maar een release-build dient te falen voor een 'unstable' build. Als je live wilt gaan met die fout als 'known-issue' dan hoort de test die dat issue aantoont gedisabled te worden in de productie/release-build.
Het skippen van de tests (-Dmaven.skip.tests=true) levert echter geen test-falen op (zonder extra maatregelen om vervolgens achteraf na de build alsnog de tests op de artefacts los te laten).

[supersnathan94]

Daarvoor maken wij gebruik van verschillende plugins. Want wat je zegt is helemaal waar. Een deployment moet falen op het moment dat er iets niet goed gaat. Echter hebben we dit al afgevangen voordat we uberhaupt mergen naar master. Door continues delivery en integration naar een hoger niveau te tillen kunnen wij iedere mogelijke fix als feature behandelenen kan dit via dezelfde pipeline lopen als een feature branch. Deployment is dan ook direct nadat een feature is opgeleverd. Zodoende leveren we dus ook nooit een bugfix op die automatish ook nieuwe code meeneemt. Die code is immers al gedeployed direct na inegratie. Master is dan ook puur een archief voor de huidige productie code.

[RoestVrijStaal]

Die zullen hun eigen tissues wel nodig hebben als ze het bedrag zien dat ze moeten ophoesten om hun boete aan ACM te betalen

[themac1983]

erm. volgens mij heeft het ACM nog 0 voor datalekken uitgedeelt hoor? tenminste, niet netjes gemelde incidenten. (zou wel moeten overigen imo)

[Bierkameel]

nieuws: AP: boetes geven voor datalekken is tot nu toe niet nodig geweest
Die authoriteit persoonsgegevens is sowieso 1 grote grap.
Ze hebben mogelijkheden genoeg gehad, oa de NS die mensen stiekem trackte met camera's in reclamezuilen en daarnaast bluetooth tracking.

Volgens mij is het een clubje dinosaurussen.

[David Mulder]

Zover ik weet sloeg ExterionMedia (bedrijf achter die reclame zuilen) totaal geen persoonsgegevens op, dus ik zie oprecht niet hoe de Autoriteit Persoonsgegevens hier een boete voor geeft. De vraag was vooral of ze beelden (<- gegevens die herleid baar zijn tot een individu) opsloegen, en dat bleek niet zo te zijn. Maar ik zou me kunnen vergissen hoor.

[Bierkameel]

https://autoriteitpersoon...wat-zijn-persoonsgegevens
De Wet bescherming persoonsgegevens (Wbp) geeft aan dat een persoonsgegeven elk gegeven is over een geïdentificeerde of identificeerbare natuurlijke persoon. Dit betekent dat informatie ofwel direct over iemand gaat, ofwel naar deze persoon te herleiden is.

Oftewel dit gaat om persoonsgegevens die ze opslaan, dit hoeft niet perse een voornaam/achternaam/adres te zijn.
Die systemen spugen dit soort gegevens uit: https://pbs.twimg.com/media/C_jqwcwXcAA8pDC.jpg en dat is te herleiden tot een persoon.

[supersnathan94]

"female-young adult, nice tits"

Wauw wat een representatief systeem.

Nee zulke systemen zijn bijna niet herleidbaar op 16 miljoen mensen. Dit is zo a specifiek dat gaat nergens over. ze kijken naar groepen en met die gegevens kun je wel herleiden naar groepen personen (dus idd vrouw of man en zelfs dat is al lastig de laatste tijd. Of bril of niet), maar in die groep dan 1 specifiek persoon eruit halen is vrijwel onmogelijk nu. Er wordt ontzettend veel gegeneraliseerd.

[Keuning Pils]

Hoewel het klopt wat je zegt, is het voorbeeld wat je geeft echt pijnlijk slecht. Lees het nog eens goed na. 'nice tits' als resultaat van een scan, een inlogpoging vanuit het kremlin... Niet erg geloofwaardig.

[silent785]

Dus die ontwikkelaars leveren het op maar kijken erna nooit meer naar? Bizar..

Als wij iets deployen dan controleren we het ook in productie, lijkt mij basiskennis...

[Reactie gewijzigd door silent785 op 22 juli 2024 13:30]

[unclero]

Niet als je gebruik maakt van een OTAP-straat, waarbij er acceptatietesten en smoketests gedaan worden.
Wij mógen niet alleen niets zelf deployen, maar ook niet testen (behalve vluchtig testen of story/ticket X of Y werkt). Testen, dat doen de testers met scenario's, tools en eventuele regressie-scenario's.
Als er iets mis is, is het "joh, schiet maar een nieuwe ticket in, dan zet ik de debug wel uit als ik een pull-request doe".

[supersnathan94]

Niet als je gebruik maakt van een OTAP-straat,

hoho niet zo generaliseren AUB. .

Wij mógen niet alleen niets zelf deployen, maar ook niet testen

tsja bij ons is het precies andersom. DevOps FTW! Hiermee zouden dit soort dingen heel snel opgelost kunnen worden. Na livegang altijd ff checken vanaf een extern apparaatje of het allemaal een beetje fatsoenlijk werkt.

[FreezeXJ]

In dat geval hadden de testers deze flater eruit moeten halen, al dan niet met eyeball-testing...

Verder geeft een test-straatje niet aan dat devs niet (ook) moeten testen, ik krijg niks doorgeduwd zonder dat m'n ATDD-tests goed zijn (anders worden de testers heel boos)

[Puc van S.]

Vergis je niet, er zijn nog zat bedrijven waar het deployen niet door de ontwikkelaars gedaan word en die uberhaubt niet weten wanneer iets live gaat.

[nickelz]

Sorry maar ik vind dit wel een beetje slecht hoor. Bij het publishen of het online gooien check je toch nog altijd na die tijd de live situatie? Ik vind het ook altijd schrijnend dat bedrijven als ze gewezen worden op een lek, het maar bagatelliseren..

[sypie]

Niet op vrijdagmiddag half 5. Dan is het simpelweg tijdens de vrimibo even de boel live zetten, scherm uit Windows+L en op naar huis.

[iketot]

Maar de actie ging donderdag live, dus geen excuusjes hier! ;-)

[Hieronymuski]

Moet kunnen als je als zelfrespecterend bedrijf gewoon je deployment op orde hebt.
Deployment naar productie moeten gewoon geen development elementen bevatten. Hell, deployment naar acceptatie zal dit al niet meer moeten hebben.

[michaelboon82]

"Tussen die gegevens zitten geen wachtwoorden..."

Ik neem aan dat het minste wat de developers gedaan hebben dat ze de wachtwoorden gehashd hebben? Elke developer die dat niet doet moet op staande voet ontslagen worden en terug naar school!

En wat is "even" online? 5 minuten? een uur? Het lijkt allemaal wel alsof ze er erg nonchalant over zijn. "Het is gebeurt, tsja....sorry?" Je zou zeggen dat het voorkomen dat persoonsgegevens van je bezoekers/klanten/etc. prio 1 moet zijn of ben ik gek?

[Torrentus]

Voor de actie hoefden deelnemers geen wachtwoord aan te maken of achter te laten; daarom zaten er geen wachtwoorden tussen de gegevens.

Als dat wel gemoeten had, dan waren ze in plaintekst voorbij gekomen in het POST-request en daarna AES-versleuteld in de database opgeslagen. De AES-sleutel waarmee de data versleuteld werd was echter zichtbaar in de Whoops-errorpage die publiekelijk geserveerd werd; dus daarmee zouden de wachtwoorden, als die er geweest waren, ook daar te lezen zijn.

De debugbar stond voor zover ik weet ongeveer een uur aan; ik ontdekte hem om 9:50 en hij verdween weer rond 10:50. De sleutels zijn een dag later (kort voor publicatie van dit artikel) gewijzigd.

[Allovich]

Goede blur trouwens op de data in de tweede afbeelding. Kan echt totaal niet uitlezen wie diegene is die in Tilburg woont.

[arnoudwokke]

Dank, heb even extra geblurd. @Allovich en @sypie. Hoop dat jullie je reactie ook even extra 'blurren'

[The_Worst]

Laten wij vooral de gegevens nog een keer herhalen in de reacties. Wellicht de gegevens helemaal weghalen in plaats van alleen maar doorstrepen?

[Jan121]

Tsja, een foutje zit in een klein hoekje, maar dit is wel slordig.

Misschien was het allemaal wel goed bij oplevering maar een foutje in de .gitignore file o.i.d, waardoor naderhand bij een update door iemand opeens wel de .env file werd gesynchroniseerd.