Onderzoek: vooral webwinkels bevatten veel beveiligingsgaten

Een gemiddelde website bevat 79 potentiële beveiligingsgaten, terwijl webwinkels de meeste kwetsbaarheden zouden bevatten. Desondanks zou het aantal lekken de afgelopen jaren zijn afgenomen, zo stelt onderzoeksbureau WhiteHat Security.

Volgens het jaarlijkse Website Security Statistics Report van WhiteHat, waarin meer dan zevenduizend sites zijn doorgelicht, blijken webwinkels met gemiddeld 121 potentiële beveiligingsgaten het meest kwetsbaar te zijn. Sites van financiële instellingen zouden met 17 lekken de minste kwetsbaarheden hebben, terwijl de gemiddelde website 79 zwakke plekken zou tellen.

Ondanks dat een gemiddelde site nog tientallen kwetsbaarheden bevat, stelt WhiteHat dat dit aantal in 2010 nog op 230 lag. In 2007 zou een doorsnee website zelfs 1111 potentiële lekken bevatten. Bovendien zou de tijd die het kost om een kwetsbaarheid te verhelpen, zijn verkort van 116 dagen naar gemiddeld 38 dagen.

De meest voorkomende kwetsbaarheid is volgens WhiteHat cross-site scripting: circa 55 procent van de onderzochte sites is hier gevoelig voor, terwijl information leakage en spoofing goed zijn voor respectievelijk 53 en 36 procent. Aanvallen door middel van sql-injecties zakten op de lijst en komen uit op 11 procent.

Reacties (50)

[Niemand_Anders]

Op zich is het enorme verschil tussen webwinkels en financiele instellingen wel logisch. Bij financiele instellingen is vrijwel alles maatwerk en de onderdelen welke vatbaar zijn zijn vaak platform gebaseerd en deze bevatten over het algemeen ook de security problemen.

Bij veel webwinkels wordt er vaak een standaard framework gepakt zoals osCommerce en worden er tientallen modules gedownload van vaak onbekende bronnen. Veel van die webwinkels starten vaak op een zolder kamertje. Het is niet zo moeilijk om iemand te vinden welke een website in elkaar kan zetten, maar iemand met ervaring op het gebied van beveiliging is niet zo gemakkelijk te vinden.

Vooral nummer twee vind ik wel interessant. Veel websites geven bij errors vaak informatieve foutmeldingen en in sommige gevallen zelfs enkele regels code.

Daarnaast ben ik op zich wel benieuwd hoe het aantal security issues zich verhoud tot de 'leeftijd' van de code. Over het algemeen zijn websites bij eerste oplevering meestal redelijk veilig. Echter vraag ik mij af hoe snel en hoe websites de frameworks waarop zij zijn gebaseerd up-to-date houden. Eigenlijk dus het patch management..

[Verwijderd]

Wat zou een goede remedie zijn om dergelijk fouten te voorkomen?

[Zerotorescue]

Als applicatie ontwikkelaar zelf leren de belangrijkste van deze exploits toe te passen. Pas als je weet welke manieren er zijn om een website te kraken en hoe deze toe te passen kan je iets fatsoenlijk (i.e. zonder dat de gebruiker er al te veel last van heeft) en voldoende beveiligen.

Paar voorbeelden:
XSS: Vaak voldoet overal <noscript> invoeren al om dit te testen. Hier kan je echter veel verder in gaan (cheat sheet).
Cross-Site Request Forgery: Lokaal een formulier maken en daarmee belangrijke acties op je site proberen te doen. Denk hierbij aan een post maken op Facebook of een andere social media site, dit kan soms zo simpel als <form action="http://facebook.com/update.php"><input name="statustext"><input type="submit"></form>, of indien het via URLs werkt volstaat soms dit al: [img]http://facebook.com/update.php?statustext=HAX[/img] (dit is vaker te misbruiken dan je zou denken).
Brute force: Quote uit het artikel: "The bulk of these Brute Force vulnerabilities occur because a website login field reveals which entry of the username / password combination is incorrect." Daarnaast is de simpelste manier om dit te testen om gewoon tien keer binnen beperkte tijd een wachtwoord te proberen. Werkt dit zonder onderbreking? Dan is het goed mogelijk dat je site kwetsbaar is voor brute forcen (neem dit als voorbeeld, niet als regel).
Predictable Resource Location: Type /admin/ of /phpmyadmin/ of /sqladmin/, etc. achter je root domein. Als dit werkt heb je het zojuist een stuk makkelijk gemaakt voor een inbreker.
SQL Injection: Vaak voldoent '; of "; invoeren al om dit te testen; als er dan een (database) error wordt getoond is er vaak meer mogelijk.
Session Fixation: Type javascript:alert(document.cookie); in je adres balk op je website (werkt tegenwoordig niet meer in sommige nieuwe browsers), is de belangrijke informatie die wordt weergegeven leesbaar, voorspelbaar of logisch? Dan is je site mogelijk hiervoor kwetsbaar.
Session Expiration: Doe een javascript:alert(document.cookie);, log uit en zet je cookie dan terug naar de output van bovenstaande alert. Ben je nu weer ingelogd? Dan is je website hiervoor kwetsbaar.

[Feanathiel]

Gebruik maken van de oplossingen die er al zijn (prepared statements, escapen van usercode, etc.), beter bedrijfsbeleid (nu is er even geen budget voor security), methoden/functies gebruiken waar ze voor bedoeld zijn (php: mysql_real_escape_string vs addslashes), enzovoort.

Wat mij opvalt zijn de aantallen. Ongeveer 7000 websites zijn getest, waarvan 1111 potentieël onveilig. Retail zou met 121 lekken aan de top staan. Tot in hoeverre is deze informatie genormaliseerd? Kan mij namelijk voorstellen dat er véél meer retail is dan b.v. banken of medische websites. Dan vallen de getallen van de retail altijd hoger uit natuurlijk.

[tweakerss]

Plus de gemiddelde retailer heeft minder budget voor een website, vergeleken met een gemiddelde financiële instelling.

[Artimunor]

denken ze... maar ondertussen moeten banken wel overeind gehouden worden, en boeken ze toch record winsten.
ik hoor erg paradoxale feiten hierover moet ik toegeven.

[David Mulder]

Ach jah, de omzet van banken is groot en het is ook wel degelijk nodig voor bank producten om veilig te zijn, dus dat is gewoon een deel van die gigantische omzet en ook absoluut niet iets waar ze op moeten besparen. Ik heb 1 keer meegewerkt aan een platform voor een bank en die heeft dan ook z'n eigen protocollen en dingen uitgewerkt voor hoe er met security moet worden omgegaan (+altijd pentesten enzo).

[Verwijderd]

Ik weet niet hoeveel winst ING, SNS e.d. hebben gemaakt, maar meer dan ooit geloof ik niet.

[Arietje]

Alleen software gebruiken die goed in elkaar gezet is. Er zijn simpelweg te veel mensen die denken een beetje te kunnen scripten en dat wordt dan gewoon massaal gebruikt. Een beetje ervaring en know-how ontbreekt waardoor de simpelste fouten ontstaan. Het gaat hier echt om simpele lekken.

Als je nou gepakt wordt door 0days in bijv. apache/php etc dan is er vaak weinig aan te doen, maar over dat soort hacks hoor je vrijwel nooit iets.

[martin149]

Volledige systemen zijn vaak ook niet handig. In deze systemen komen vaak ook kwetsbaarheden voor, maar die worden veel sneller bekend. Je zult gewoon een goede beveiliging moeten hebben en hier de aandacht aan schenken. Dit is een punt waar gewoon nog steeds veel te veel op wordt bezuinigd.

[cyberstalker]

Output escapen voor het weergeven.

[RobIII]

En input escapen voordat 't naar elders (lees: bijv. DB) gaat, zorgen voor auditing, zorgen dat je gebruik maakt van een fatsoenlijk sessie systeem (en beheer) en ga zo maar door. Er is geen "one magic solution fits all".

[David Mulder]

Nee nee nee, input absoluut niet escapen voordat het naar de DB gaat, want dan krijg je een misinterpretatie van de input (bijv. tal van problemen in simpelere blog systemen met quote'jes). Wat je hoort te doen is input geparameteriseerd aan de DB doorgeven en escapen voordat je het output (indien van toepassing, wat niet eens altijd het geval is (in een text file bijv. niet)). True escapen tijdens input en output is makkelijker als je 'lui' bent, want stel je vergeet het aan de output kant dan gaat het toch niet mis, maar het werkt me altijd op de zenuwen als ik in DB's ge'escaped data zie terwijl ik zeker weet dat de gebruiker dat niet invoerde.

Hoe dan ook, het is wel degelijk goed mogelijk om een veilige applicatie te maken, belangrijkste daarbij is dat je GEEN OUDE CODE gebruikt (en sowieso geen externe code behalve als het van grote open source projecten is ofzo). Tegenwoordig als je een beetje goed bezig bent en vanaf scratch je goed bezig houdt met de security gaat dat echt wel goed en daarna auditen is wel zo handig als je er de juiste mensen voor hebt (of extern als je daar het geld voor hebt).

[pizzafried]

Wat is er Is met mysql real escape string? Geen problemen met de uitvoer hoor....invoer escapen en uitvoer htmlentities of gelijkwaardig gebruiken....formuliertokens gebruiken browser fingerprint tegen hijacking van de sessie!

[Quacka]

websites alleen door robots laten bouwen? Onee, want die zijn ook geprogrammeerd door mensen.
Waar mensen werken, daar worden fouten gemaakt. Gelukkig ook maar.

[MicGlou]

Ik kan mij voorstellen dat de centen aardig op kunnen lopen voor een kleine ondernemer met een webshop. Het is sowieso onmogelijk om zelf alle kennis in huis te hebben, je zal dus extra handjes daarvoor in moeten huren en dat is niet goedkoop. Maar dan ben ik wel iemand die dan eigenlijk zegt: 'dan had je er niet aan moeten beginnen'. Want uiteindelijk zet je op het spel waar je afhankelijk van bent: je klanten. Het is de complete backbone van je bedrijf en die moet vanzelfsprekend zo sterk mogelijk zijn.

Ik ben zelf best wel voorstander van het gebruik van webshops, maar ik wordt serieus wat voorzichtiger... maar eerlijk gezegd: hoe voorzichtig kan je eigenlijk zijn, want dat behoor ik toch niet te zijn? Is dat dan maar het eventuele risico waar ik rekening mee moet houden of goedkoper uit te kunnen zijn dan in de winkel... dat mijn gegevens wel eens op straat zouden kunnen komen te liggen? Als dat al niet gebeurd is?

[Zoijar]

Ik ben zelf best wel voorstander van het gebruik van webshops, maar ik wordt serieus wat voorzichtiger... maar eerlijk gezegd: hoe voorzichtig kan je eigenlijk zijn, want dat behoor ik toch niet te zijn? Is dat dan maar het eventuele risico waar ik rekening mee moet houden of goedkoper uit te kunnen zijn dan in de winkel... dat mijn gegevens wel eens op straat zouden kunnen komen te liggen? Als dat al niet gebeurd is?

Vergeet ook niet dat security bedrijven er altijd baat bij hebben om te laten zien dat dingen niet veilig zijn. Niet dat je dan niet uit hoeft te kijken, maar om sommige dingen een beetje in perspectief te plaatsen.

[jvd-nl]

Ik ben benieuwd welk soort webwinkels ze hebben getest (Amazon/Bol of de lokale bakker?) Ik ga er even vanuit dat het inderdaad de 'gemiddelde' webshop betreft. Dan vind ik deze constatering iig niet verwonderlijk.

Tegenwoordig wil ongeveer elk bedrijf vertegenwoordigd zijn op internet met een webshop. Waar waar je vroeg een website moest hebben (om er een te hebben), zie je nu een soortgelijke trend voor shops. Deze worden dan vaak belegd bij creatieve bureau's, waar de nadruk zeker niet op techniek/veiligheid ligt. Dat alles hangt vaak ook nog eens aan elkaar met verschillende in de community verkrijgbare of zelf geknutselde plugins en wordt verkocht voor minder dan 20k. Vaak kán er dus helemaal geen aandacht voor veiligheid zijn ('alles werkt toch...').

Voor bedrijven die het online-verkoopkanaal als primaire business zien zou je verwachten dat de veiligheid een stuk hoger ligt, maar helaas gaat het rapport daar niet erg diep op in.

[Reactie gewijzigd door jvd-nl op 23 juli 2024 03:21]

[Verwijderd]

Via Firebug of header editors winkelwagentjes en verzendkosten aanpassen, kan bij ongeveer 30% van de shops zou ik zeggen. SQL injection is een beetje aan het uitsterven vandaag de dag omdat dat alom bekend is. Heb ook bij verschillende grote GSM shops gezien dat het eenvoudig is om cookie hijacking uit te voeren. Wat enige veiligheid biedt hierin is de korte levensduur van sessies. Typhone bleek enkele tijd geleden relatief eenvoudig - en nog steeds - om klant info te ontfutselen, maar dat lek kan nu al gedicht zijn, heb het al even niet meer geprobeerd.

Wat veel website eigenaren niet realiseren is dat geen enkele input via formulieren vertrouwd kan worden op enige juistheid, zelfs niet als de velden verborgen zijn.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:21]

[Lisadr]

Wie is verantwoordelijk. De klant of programmeur?

Mijn ervaring is dat klanten kiezen voor de (naar hun mening) meest kost efficiënt oplossing. Er is zelden budget voor testen en veiligheidscontroles en daarnaast willen ze graag alles gisteren.

Ze kiezen de goedkoopste SSL certificaten en willen geen aanvullend geld uitgeven voor extra veiligheid. Althans dit is mijn ervaring bij klein en middelgrote bedrijven die een online webshop beginnen.

[Verwijderd]

De duurste certificaten zijn ook onzin. Die groene balk in bijv. IE is leuk, maar is meer een cashcow. Een certificaat zou standaard de veiligheid moeten bieden die nodig is, en niet tegen een meerprijs.

[JoepD]

Veel kleine e-commerce bedrijven gebruiken toch osCommerce, OpenCart, Magento, etc. Ik denk dat hier dan veel van deze beveiligingslekken te vinden zijn.

[biglia]

Ze zouden een onderzoek moeten doen welke programmeertaal gebruikt werd wanneer een lek werd gevonden. PHP > ASP.NET qua beveiligingslekken denk ik.

[Zoijar]

En dan? Correlatie is niet causatie. Stel dat (!) veel prutsers PHP gebruiken; dan bevatten PHP sites relatief veel lekker, maar misschien is de taal juist wel veel veiliger te gebruiken als je weet wat je doet. Een taal is maar een tool.

[biglia]

Je kan als programmeertaal de programmeur toch bepaalde dingen verplichten te doen. Programmeurs kiezen altijd voor de makkelijkste, snelste, en vaak onder druk ook de goedkoopste manier. Dwing het af dat ze dat niet meer kunnen.

[Sorcix]

Als de makkelijkste, snelste en goedkoopste manier niet meer kan, gebruiken ze gewoon een andere programmeertaal. ;-)

Een programmeertaal is een tool, en mag niets afdwingen.

[The Zep Man]

Een programmeertaal is een tool, en mag niets afdwingen.

Dus van een magnetron (een stuk gereedschap) mag de deur open gaan zonder dat deze afslaat van de magnetronfunctie?

Nee, afdwingen is goed. En degenen die veel werken met talen die dit doen hoor je er weinig over klagen omdat het wend en de kwaliteit omhoog gaat. PHP is op dit gebied erg brak in verhouding met (bijvoorbeeld) C#.

[Zoijar]

En C -- en daarmee zo'n beetje de hele linux kernel -- is ook erg brak omdat er niets wordt afgedwongen? Beetje vergezocht.Ik vind dit echt zo'n mijn-taal-beter-dan-de-jouwe discussie, terwijl het alleen maar een tool is om een probleem op te lossen. Er is brakke PHP en er is brakke C# code. Ik ben ook geen fan van PHP, maar je kan er prima hele goede en veilige websites in schrijven (tweakers.net bv meen ik me te herinneren)

[Reactie gewijzigd door Zoijar op 23 juli 2024 03:21]

[The Zep Man]

En C -- en daarmee zo'n beetje de hele linux kernel -- is ook erg brak omdat er niets wordt afgedwongen? Beetje vergezocht.Ik vind dit echt zo'n mijn-taal-beter-dan-de-jouwe discussie, terwijl het alleen maar een tool is om een probleem op te lossen.

Uit mijn post:

PHP is op dit gebied erg brak in verhouding met (bijvoorbeeld) C#.

Nergens geef ik aan dat een programmeertaal in het geheel beter is dan de ander. Alleen op het gebied van de programmeur beschermen tegen (beginners) programmeerfouten is PHP toch echt slechter dan C#. Op andere gebieden is PHP weer beter.

Er is brakke PHP en er is brakke C# code.

Nergens geef ik anders aan.

Ik ben ook geen fan van PHP, maar je kan er prima hele goede en veilige websites in schrijven (tweakers.net bv meen ik me te herinneren)

Nergens geef ik anders aan. Ik geef zelfs niet aan of ik wel of niet een fan van PHP ben. Impliceer niet dat ik dit wel doe.

[David Mulder]

Nee, de vergelijking gaat totaal mis, want een taal is geen stuk greedschap (ondanks dat die vergelijking soms wel opgaat). Het punt zit hem er in dat de *taal* (bijna) niks moet afdwingen, want dat moet door libraries worden gedaan. Neem php, als je het zonder library gebruikt en je bent een prutser dan ja, is de kans heel erg groot dat het totaal mis gaat, maar zodra je een library/framework zoals codeigniter gebruikt wordt je plotseling wel beperkt, maar kies je daarvoor afhankelijk van het project. Aan de andere kant heb je ook talen die zowel een taal als een library/framework proberen te zijn, waardoor je die keuze niet hebt; het resultaat: de pogrammeurs begrijpen niet wat ze eigenlijk doen (first hand experience) en voor applicaties waar het framework niet op past worden de ergste hacks voor bedacht (+de taal is vreselijk bloated).

[SmokingCrop]

Nee, dit is een slechte vergelijking..

Het gaat hier gewoon om de default beveiliging en niet wat de klant al dan niet bestelt.. (giftig iets in magnetron of verkeerde item/teveel items op de website)

[Verwijderd]

Ondanks dat de deur 'geforceerd' dicht moet zitten kan er toch alsnog een levend hondje/kat in worden geplaatst.

Lijkt me dus meer een kwestie van 'zelfbescherming' voor de programmeur.

Desondanks vind ik ook niet dat een programmeertaal een 'tool' is maar een library aan mogelijkheden. Het is aan de programmeur of hij er verstandig mee omgaat.

[Avalaxy]

Veiligheid heeft weinig met de programmeertaal te werken. Ja, ASP.NET MVC heeft een hoop dingen al ingebouwd (XSS protectie bijvoorbeeld), maar je kunt in PHP net zo goed een veilige applicatie bouwen.

Het hangt puur af van hoe je het gebruikt: oftewel, het hangt af van de ontwikkelaar(s).

Overigens is geen enkele aanval uit het rijtje in het plaatje moeilijk te voorkomen, ik vind het ongelooflijk dat er nog van die klojo's rondlopen die zichzelf programmeur noemen maar wel software schrijven die vatbaar is voor één van die punten.

[Verwijderd]

Die ontwikkelaar moet je uit de keten halen, die moet zich volledig kunnen concentreren op de gewenste business logic, en zich niet bezighouden met veiligheid. Dat is immers allemaal al uitgezocht en ervaren door anderen. Bouw dat in in de taal zodat de fout niet keer op keer gemaakt kan worden.

In elektrische gereedschap zitten ook allerlei beveiligingen om te voorkomen dat de man/vrouw die daar mee werkt zichzelf en anderen in gevaar brengt. Waarom dan niet in softwareontwikkeltools hetzelfde doen? Het is toch onzin dat iedere ontwikkelaar daar weer tijd in moet steken?

[Verwijderd]

Bouw van veel zaken is ook vaak al eerder gedaan, afgezien van wat kleine verschillen. Moet dan maar -alle- code online gezet worden onder Creative Common License of GPL ofzoiets?

Ook beveiliging is iets wat niet altijd gepubliceerd is, en je je dus wel mee bezig moet blijven houden. Ja, het is jammer dat we dat nu moeten, maar je zorgt ook zelf dat je voordeur op slot zit, terwijl je het liefst er gewoon wilt wonen, want daar is ie voor bedoeld.

[gertrudi]

Ben ik niet met je eens, talen zoals java en C waar je zelf de beslist of een variabele een string of een getal zijn een stuk veiliger dan talen waardat voor jou wordt beslist

[Bender]

Interessante informatie, het wijst er toch maar weer op dat je altijd moet controleren met wat je doet!

[Verwijderd]

:
Een eerste stap zou zijn.....
Een redelijke beloning voor de webmaster.....
:
Hoe waardevol zijn de documenten?
Hoe waardevol is de webmaster?
:
Hoe kun je de beveiliging verbeteren?
.. Huur een beter getrainde webmaster.
.. En die krijg je alleen voor een redelijke beloning, toch?
:

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:21]

[FireWood]

Dat krijgen ze al.
Dat wordt loon genoemd....

[Verwijderd]

:
Dus je doet je werk waar je te weinig tijd voor krijgt.
Taken blijven liggen .... en bugs overal.......
:
Gelukkig krijg je een baantje bij een andere werkgever.
Een werkgever die weet hoe waardevol je bent.
:
In je dromen.
:

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:21]

[Keypunchie]

Geen idee waarom je zo weggemod wordt. Misschien omdat je een wat vreemde opmaak gebruikt. Die dubbele punten zijn niet nodig op Tweakers, je kunt hier gewoon breaks met de enter invoeren

[on-topic]

Het is echt niet alleen een kwestie van geld. Sowieso is de functie van "webmaster" al een beetje achterhaald, tegenwoordig wordt een beetje website, ook qua veiligheid, beheerd door verschillende specialisten, uitbesteed of niet. De veiligheid ligt bij verschillende rollen: De hardware door fysieke beveiliging, OS en middleware door een systeembeheerder, de applicatielaag bij een developer, database bij een DBA en inhoud bij een functioneel beheerder. Netwerk is hopelijk ook door een specialist dichtgetimmerd.

Maar daarnaast is het ook veels te simpel om te denken dat het een geldkwestie is. De eerder genoemde specialisten worden vaak prima betaald, maar dan nog gaat het mis. Soms is het domweg een gebrek aan kennis. Aan de andere kant is ook een specialist maar een mens, en kan een steek laten vallen.

Het nadeel is: Er hoeft maar op 1 van de lagen iemand een steek te laten vallen, en ze zijn allemaal het haasje. Je moet defense-in-depth hebben, als onderdeel van een integrale beveiligingsstrategie, om te voorkomen dat dat gebeurt.

Dat is geen kwestie van de individuen beter betalen. Dat is een kwestie van goed beveiligingsmanagement en integraal veiligheid meenemen in alle fases. Bij het ontwerpen, ontwikkelen, accepteren en beheren van een site.

[Verwijderd]

Vroeger kostte een website goud geld, je betaalde dik 5000 gulden of meer voor een beetje website (althans, die mensen heb ik bij een werkgever langs horen komen).
Nu kun je een doehetzelfpakketje van internet plukken, eventueel door een bedrijfje laten opzetten die het voor een paar honderd euro doet (vaak exclusief alle persoonlijke wensen, dat dan weer wel).