Gezien de gevolgen voor de nietsvermoedende klant zouden de (domein)namen van deze webshops eigenlijk bekend gemaakt moeten worden. Zodat mensen deze webshops kunnen vermijden.

Valt in principe onder de meldingsplicht datalekken. Afhankelijk van de jurisdictie moet dat naar de klanten, of alleen naar de toezichthouder.

Een andere lesson learned is (nogmaals) de class break. Je kan ook in een fysieke winkel inbreken, maar 7339 winkels is 7339x het werk. 7339x webwinkels is 1x het werk plus peanuts om het op te schalen naar nog meer met dezelfde kwetsbaarheid. Plus: Het kan op maximale afstand hele aardbol (vanuit Mars is voorlopig nog een beperking wegens minuten vertraging op de communicatie).

Geheel mee eens.

Wat kunnen criminelen doen met die gegevens? Aankopen met credit card gaat toch altijd samen met TAN codes?

Nee... Gewoon creditcard nummer en evt. code op de achterkant invoeren. Die laatste wordt hopelijk niet opgeslagen.

Niemand praat hier over de brakke techniek van de CSM software en plug/ins en het brakke en lamlendige onderhoud en configureren door de vele website admins en hosters e.d. Laten we hier weer een het woord PHP/gebaseerde CMS vallen, denk aan Word Press plug/ins, directorly listing op aan, user enumeratie op aan. Voorgekookte click _ paste prut. Prakkie onveiligheid.

Voor magento loop eens door wat mage rapportjes en schrik je een hoedje. Praatje pot, pleistertje, kleine update en upgrade en we gaan weer verder waar we gebleven zijn. De cybercrimineel maakt er dankbaar gebruik van, alsmede de ad/tracker en Big Tech. Gatenkaas op de infrastructuur. Het begint al aardig te stinken die gatenkaas. Net als dat bekende Zwitserse produkt uit het ronde kartonnen strooidoosje, sommigen maakte de gaatjes nog wat groter met een mesje. Goede kaas, bloedzuiverend! Ha, ha, ha. Moet ik hier nog serieus op ingaan. Men doet er toch weer niks ten principale aan. Doormodderen, mensen!

Ik wilde me eens inhouden. Maar natuurlijk is dit inderdaad weer een voorbeeld van op PHP-stacks gebaseerde baggerware!

Had je je nou ingehouden. PHP wort gepromoot vanuit het CERN. Je moet het wel veilig ontwerpen en veilig uitwerken.
OSS of Linux zit in die zelfde hoek, ook al is het open je kan er nog steeds een grote chaos van maken.
Sterker door het idealisme met een groei vanaf de garage en dat omdat iedereen het kan zien maar niemand er echt naar kijkt komen de fouten gegarandeerd. https://security.web.cern.ch/security/training/en/technical.shtml#php

PHP is slechts met een bepaalde duidelijk begrensde scope destijds ontworpen taal, vandaar.

Lees dit eens, zou ik zeggen: "https://security.stackexchange.com/questions/643/why-do-people-say-that-php-is-inherently-insecure".

Ik zal niet zeggen dat het onmogelijk is om PHP en JavaScript bijvoorbeeld zo veel mogelijk error vrij te maken, maar zo lang er nog 77% van de websites bijvoorbeeld tenminste 1 af te voeren jQuery bibliotheek bezit, heb ik er persoonlijk en na opgedane relevante ervaring een hard hoofd in.

Test maar een willekeurig website eens met Erlend Oftedal's online scanner: https://retire.insecurity.today/# voor af te voeren jQuery bibliotheken of doe een webhint scannetje met Nelly naar best practices: https://webhint.io/,
daar gebeurt hetzelfde met behulp van SNYK.

Dit na jarenlang op script errors te hebben gejaagd met unpackers als jeek en op stackoverflow gezocht, kan ik je ook nog vertellen dat developers niet met security als first thing op het netvlies worden opgeleid. Ja aftikken bij een toets na 1 endless loop, 41% van de vragen goed, dan nog even doorstampen dus.

Je ziet het echt te optimistisch, karma4, cern of geen cern,
Ik deel wat dit betreft mijn zakje gebakken emping wel met Krakatau ;).

luntrus

CERN biedt voor zowat alle bekende programmeertalen wel iets dergelijks aan. Soit...

https://security.web.cern.ch/security/training/en/technical.shtml

Er is al een heleboel onveiligheid bij PHP verdwenen, maar soms bleven oude onveilige methoden nog geruime tijd gewoon onder de nieuwe versie werken, hoewel ze al 'depreciated' waren.

Denk aan 'class constructor' na invoeren van '_construct' en het niet meer statisch mogen aanroepen;
Verder 'PASSWORD_DEFAULT = 1' met het tonen van de string na een refresh run, die een hacker aan het begin als 'buit' tussen de eerste $ en tweede $ het encryptie algoritme verschaft, vervolgens de cost (bijvoorbeeld 10, cost 16 laat de website wel zeer langzaam laden) en vervolgens de salt. Je kunt die nu niet meer uitschrijven, want de ingave van de developer is niet random genoeg. Het wordt nu voor je gedaan. Ook afgevoerd is 'stream_get_meta_data' wat via '$fp' allerlei file informatie kan vrijgeven.
Info source bron: Avelx.

Met het bovenstaande in gedachten naar aanleiding van de veiligheids transitie van PHP6 naar PHP7 in het achterhoofd, heeft Krakatau natuurlijk wel een punt.

Je kunt dus met PHP gemakkelijk van de regen in de drup raken, maar dat is in zekere zin inherent aan script en code.
Maar we blijven leren en veiligheid aanscherpen. Onderzoek alle dingen en behoudt het goede.

luntrus