'Veel websites kwetsbaar voor hackaanvallen'

Beveiligingsbedrijf Acunetix heeft onderzoek gedaan naar de beveiliging van websites. Zeven van de tien sites lopen een serieus risico, claimt het bedrijf; slechts negen procent van de onderzochte webstekken bevat geen bekende zwakheden.

De helft van de 3200 onderzochte nonprofit- en commerciële sites is vatbaar voor sql injection-aanvallen, zo toonde de Web Vulnerability Scanner van Acunetix aan. Dit programma, dat vorig jaar januari werd geïntroduceerd, vond daarnaast in 42 procent van de gevallen cross site scripting-lekken. Verder slaagde de software van Acunetix erin om van diverse sites de source code boven water te krijgen, maar ook sites die bestandenlijsten weggaven, werden als 'niet in orde' aangemerkt. Het bedrijf benadrukt dat een flink aantal sites een 'extreem grote kans' loopt om gehackt te worden.

Acunetix haalde niet minder dan 210.000 fouten en foutjes in de onderzochte websites boven tafel. Eerder onderzoek wees uit dat bijvoorbeeld het aantal sites met sql injection-lekken veel lager zou liggen, dus het is de vraag in hoeverre de onderzochte sites op het vóórkomen van beveiligingsgaten zijn uitgezocht: het bedrijf wil zijn kwetsbaarhedenscanner uiteraard graag verkopen. Toch geven de resultaten reden tot ongerustheid: 'Veiligheid wordt totaal over het hoofd gezien', aldus vice-president Kevin Vella.

Reacties (56)

Zoek vooral op .asp websites en doe dingen als %% op zoekvelden...

Maar soms weet je niet dat er op de achtergrond daadwerkelijk wel dingen gebeuren. Zo laat ikzelf altijd netjes een fake resultaat naar voren komen (met foutive informatie mocht iemand m'n auteursrecht willen schenden; later toch makkelijk via copyscape.com te zien), gaat het IP in een abuse-list en krijg ik een prachtige mail hierover wat hij allemaal wel niet probeerd.

Voor zover ik het weet is het overigens strafbaar tegenwoordig toch om dit te 'testen' zonder het van tevoren te vragen of het mag? Nou... laat de eerste rechtszaken maar komen tegen deze heren.

Overigens: wifi netwerken zijn ook zo lek al een klontje, dus prive gebruikers kunnen er ook wat van (beveiliging)

Alle input controleren blijft een hell of a job. Daarom heb ik voor PHP dit simpele stukje code geschreven, dat misschien bruikbaar is voor wat andere mensen

<?

foreach ($_GET as $var => $value)
$_G[$var]=htmlspecialchars(trim($value),ENT_QUOTES);

foreach ($_POST as $var => $value)
$_P[$var]=htmlspecialchars(trim($value),ENT_QUOTES);

foreach ($_COOKIE as $var => $value)
$_C[$var]=htmlspecialchars(trim($value),ENT_QUOTES);

?>

In plaats van $_GET, $_POST, $_COOKIE kan je dan in standaard gebruik maken van $_G, $_P, $_C. Wanneer je wel de normale variabelen nodig hebt kan je deze uiteraard altijd nog gebruiken. Tekens als % zou je eventueel nog kunnen filteren, maar dit houdt al een behoorlijk groot gedeelte tegen en spaart aardig wat werk uit(plus dat het korter is om te typen, voor de luie programmeurs).

Uiteraard is dit wel iets langzamer, maar zeker bij de minder grote/drukke sites zal je hier vrijwel niets van merken.

@ Bo-oz: in dat geval kan je ook gewoon rechtstreeks de $_POST etc aanroepen

Met de kanttekening dat er, indien nodig, weer terug kan worden geconverteerd met:

htmlspecialchars_decode();

Als je een content management pagina aan het maken bent, is het wellicht wenselijk dat er rauwe HTML naar je database (of waar dan ook naartoe) gaat.

edit: iets eenvoudigere code voor jouw methode, te vinden als reactie op de manual page van htmlspecialchars op php.net:

http://nl2.php.net/manual...tmlspecialchars.php#72752

Je methode is leuk tegen cross site scripting, maar wat heb je in hemelsnaam aan htmlentities in je database?
Daarbij, wat is er mis met de standaard input filters dan?

Ook is het niet per definitie korter omdat je in iedere functie ook nog global $_G moet zetten, dan wel $GLOBALS['_G'] moet gebruiken.

Zelf testen:
<span style=\"text-decoration:underline\">Sql injection test instructions</span>

Deze test alleen de GET variabelen in de url, aangepaste cookies of post variabelen test je niet op deze manier. De kans bestaat dan dus dat je denkt dat je een goed beveiligde website hebt, terwijl het omgekeerde het geval is.

hmm...daar gaat m'n goede tip (voor 2/3 dan)
Enig idee op welke manier je die dan wel kan testen?

Het beste is gewoon om er tijdens het scripten rekening mee te houden en standaard alles te valideren. Wil je het testen, dan is het enorm veel werk. Je zal anders met cookie editors aan de slag moeten gaan en allerlei variabelen in de inputforms moeten doen om het te testen.

Door op elke plek waar je een variabele kunt invullen (velden of variabelen in url's) een single quote ' of double quote " te plaatsen (hiermee test je dus ook andere server side talen zoals PHP).

SQL injection is gewoon het gevolg van slecht progammeren. Je moet data die door users ingevult kan worden gewoon ALTIJD controleren. Als je het gaat gebruiken in queries of files openen

ligt dit niet aan het type script dat je gebuikt icm je browser? want als er bugs in je browser zitten (bij de meeste is dit wel het geval) kun je er makkelijker inbreken op sites en andere PC's.

@reacties
t was ook maar een vraag

Een goede check op invoerwaarden, zoals switchboy als zegt, voorkomt SQL injection. Hoe lek de browser ook is, als je server-side scripts SQL injection afvangen zit je veilig.

Dat niet alleen. Je kan meerdere accounts aanmaken voor je db, waarvan elk een specifieke taak heeft met de juiste machtigingen. Nu moet je dat niet voor elke bewerking doen.

Maar voor een search qwerry bijvoorbeeld heb je nooit één nodig die rows moet verwijderen.

Mocht jij programmeur zijn, dan ben ben jij kennelijk zo'n brokkenpiloot ;-)

Bij goed geprogrammeerde webapplicaties vertrouw je geen enkele input en doe je enkel aannames wbt de client side als het het uiterlijk betreft. De werking van een goede webapp mag NOOIT worden beinvloed van buitenaf!

Je hebt het door,

In mijn webapplicaties bestaat mijn code voor meer dan 30% tot soms wel 80% uit het controleren van input van de gebruikers.

Alles alles, moet gecontroleerd worden.

Javascript (en andere browser scripttalen) zijn er niet voor om de gegevens te controleren voordat je ze opslaat, maar voor de gebruiksvriendelijkeid. Alles serversided controleren..

Hoe simpel is het om een formulier te kopieeren en zelf daar waardes in te gooien? hacker de hack

Ja of alleen al javascript uit zetten. Dan zijn ook alle client side beveiligingen weg

Server side controle van gebruikersinvoer heeft imo vrij weinig te maken met de gebruikte browser

Nee, een site moet er namelijk op gemaakt zijn dat hij op zichzelf veilig is los van hoe hij benaderd word. Namelijk als een browser er al voor kan zorgen dat er een veiligheids probleem ontstaat hoe kan een dergelijke site zichzelf dan staande houden tegenover de tools die hackers gebruiken of schrijven.

De browserveiligheid heeft niets te maken met de veiligheid van de server.

SQL insertion wil zeggen dan een deel van de SQL opdracht in de parameters van de website staan en dat hier geen extra controle op uitgevoerd wordt.

Op die manier zou je bijvoorbeeld via een lookup script een tabel uit de database kunnen legen...

Nee, niet bij SQL injection. Dat kan echt alleen als info niet op de juiste manier van controle-tekens ontdaan wordt voor gebruik in een query. Dat is overigens heel niet moeilijk, in PHP is er bijvoorbeeld de functie mysqli_real_escape_string($jeTeEscapenString).

mysqli_real_escape_string

Wat een functie-naam; "real" hoe komen ze erop

Het probleem zit hem niet direct in user input valideren maar in output validatie.

Veel sites en "security experts" zeggen dat je je user input moet valideren maar het is altijd veel beter om al je output goed te hebben.

Zie ook dit artiekel: http://scriptuncle.nl/node/3

En dan mag jij me uitleggen wat het essentiele verschil is

De ene noemt blijkbaar output wat de ander input noemt... dit artikel is echt totaal niets nieuws onder de zon! User input == Output van de requesting page

edit: waar slaat de overbodig mod nou weer op als CyaNox zn reactie interessant is?

Weer een goed argument voor open source vindt ik. Voor websites zeg ik altijd, pak gewoon een opensource portal pakket, hang er je eigen theme en je eigen modules in, regelmatig even controleren voor updates en je zorgen zijn de wereld uit. Snel, makkelijk, goedkoop en veilig.

Niet dat open source perse beter is dan closed source maar de fouten in open source komen iig aan het licht en er wordt iets aan gedaan.

Met closed source kan het zijn dat de programeur een foute dag heeft of dat er een deadline gehaald moet worden en dan wordt er foute code in gehangen waar niemand nooit meer naar kijkt tot het fout gaat.

Ach, het 'voordeel' bij open source is dat iedereen de code kan inzien en dus ook de mogelijke lekken. Als je het gevonden lek niet meldt en gaat gebruiken voor eigen doeleinden schiet het nog niet op.

Het ligt aan de gebruiker van het pakket om te updaten/upgraden als er een lek gevonden is.

En het halen van een deadline heeft niks met open/closed source te maken, dus dat argument gaat niet echt op.

Weer een goed argument voor open source vindt ik. Voor websites zeg ik altijd, pak gewoon een opensource portal pakket, hang er je eigen theme en je eigen modules in, regelmatig even controleren voor updates en je zorgen zijn de wereld uit

Een doorontwikkeld product is doorgaans veiliger dan een eenmalige custom oplossing. Daarvan wordt de code immers niet meer doorgekeken.

De Open Source paketten hebben wel als nadeel dat lekken bij een groter publiek bekend zijn. Ik heb een server gehacked zien worden omdat er Mambo op stond. Bepaalde request parameters gingen door een eval() heen, de hacker heeft d.m.v. de adresbalk in de browser willekeurige opdrachten op de server kunnen uitvoeren.

Zoals ik al zei open source is niet perse beter dan closed source. Mambo is daar een goed voorbeeld van. Ze hebben later zelfs Mambo omgedoopt naar Joomla om van de foute PR af te komen.

PHPNuke is ook een goed voorbeeld. Eerdere versies waren niet veilig en latere versies werden onveilig door verkeerde instructies in de handleiding of door admins die niet wisten wat ze aan het doen zijn.

We kunnen allemaal wel doen alsof alle websites worden onderhouden door profesionele teams en dat alle code wordt door ontwikkeld en de servers regelmatig onderhouden maar in de praktijk is daar helemaal niks van waar.

De MKB huurt een webcoder in die een eenmalige custom "applicatie" (meestal een paar losse pagina's die aan elkaar hangen met menus en sessions) inelkaar zet (meestal een kennis of een bekende). De MKB heeft geen geld om naar een groot bedrijf te stappen, we spreken hier niet over enkele duizenden euro's maar over enkele tien duizenden euro's en daar heeft de MKB geen geld voor. Die webcoder (student, zelf geleerd, etc.) maakt een leuke website, kleine demonstratie, mooi mooi mooi, er wordt ergens goedkope hosting vandaan gehaald, het wordt ergens op een server geflikkert en niemand die er er naar kijkt.

Een overgroot deel van de websites wordt beheerd door doe-het-zelfers die het doen puur uit intresse of gewoon omdat ze het leuk vinden om een website te hebben. Die mensen proberen een site aan de gang te krijgen, het wil maar niet lukken dus doen ze verkeerde dingen (zoals chmod 777) zonder het door te hebben dat ze hun server/site wijd open zetten.

Alleen grote bedrijven en/of corporaties hebben het geld om daadwerkelijk professionals in te huren die een fatsoenlijke webapplicaties in elkaar en welke ook regelmatig wordt onderhouden.

Het argument dat closedsource beter kan zijn gaat in dat geval wel op. Er wordt tijd genomen om het project goed in te plannen en er wordt geld vrijgemaakt voor onderhoud, dan kan closedsource beter zijn. Maar in de praktijk gebeurd dat gewoon niet.

Als een applicatie al qua ontwerp defectief is dan maakt het niet uit of het open of closed is. Maar met open code weet je iig wat je krijgt.

Ze hebben later zelfs Mambo omgedoopt naar Joomla om van de foute PR af te komen.

Wat?

Joomla is een fork van Mambo.

Mambo is niet Joomla gaan heten. En Joomla's ontstaan had niet te maken met slechte PR van Mambo, maar met de overname van de mambo foundation en daaropvolgende onenigheid over het te voeren beleid.

Overigens ben ik typisch iemand die van die sites maakt die jij (SizzLorr) beschrijft (ik ben net niet dom genoeg voor de chmod 777 acties). Mijn sites zijn ongetwijfeld makkelijk te hacken door een beetje hacker. Veiligheid is belangrijk, maar ik moet zeggen.... Het Is Nog Nooit Gebeurd. Het blijft beperkt tot wat spam via het feedback formuliertje.

Dat een site gemaakt is door iemand die geen proffesional (met diploma) is hoeft niet te betekenen dat de site waardeloos is!!

Je hebt gelijk dat er veel klunzen zijn die waardeloze code schrijven en die pik je er meestal ook direct uit door de site door een validitor te halen

Er zijn er ook genoeg webmasters(innen) die wel verstand van beveiliging hebben en waarvan de code (bijna) potdicht zit

Gaat niet steeds op. Websites zoals PHPBB die gebruik maken van zogezegde 'hacks' zo ik niet meteen als betrouwbaar noemen. Hiervoor pas je de code aan met scriptjes van de community, maar wie zegt dat de maker effectief goede code heeft geschereven...

Hoe kun je deze test zelf doen op je eigen site(s)?

Als je met zoiets afkomt, dan vrees ik dat je hier en daar een steekje al heb laten vallen.

Je moet maar eens zoeken via google naar enkele termen. Crosside scripting, SQL injection, ...

Als je met php werkt kan je hier al eens kijken.

Aparte conclusie die je trekt op basis van mijn vraag.
Het kan nooit kwaad om een check over je site te halen om te kijken of je nergens een klein foutje over het hoofd hebt gezien.

Hetzelfde geldt voor opensource CMS'en.
99% van deze systemen worden standaard geimplenteerd...

maw code downloaden, database structuur bekijken, zwakke componenten uitzoeken en proberen of je een adminstrator user kan toevoegen, sessie kan wijzigen, cookies kan aanmaken etc etc... Hoe moeilijk is dat... de code is zelfs nog vaak goed gedocumenteerd...

Is het ongevraagd testen van veiligheid trouwens niet illegaal? Een SQL injectie kun je eigenlijk alleen maar testen door een ongeldig stuk code in the querystring te plaatsen... wat dus eigenlijk al een poging is tot het aanpassen van de informatie op de website....

In dit geval zou open-source een nadeel zijn, maar de gebruiker van het CMS kan natuurlijk hetzelfde doen - en in dat geval zou men dankzij de open-source natuur van het CMS er weer een bug uit verwijderd hebben.

Bij 'closed source' websites kun je dit als gebruiker niet en moet je maar hopen dat de ontwikkelaar hier al rekening mee gehouden heeft...

Open source code goed gedocumenteerd... was het maar zo, maar als half onwetende snap ik er meestal geen hout van .. (wat mij tot geheel onwetende maakt?) Al te veel cms'n brengen zich aan de man als 'extremely flexible and easy to implement for everybody' en 'no need to know any code or even xhtml'. Helaas is dat zelden of nooit waar.

Open source is nu alleen in het nadeel als je gelooft in security by obscurity. Maar ik vraag me af of die 'slechte' websites in joomla of typo3 gemaakt zijn...

Ik vind de getalletjes wel wat overdreven die deze tester geeft. Hoe dan ook krijgen ze hier veel klanten mee .

De getalletjes zijn overdreven? Als die beste man of vrouw nu heeft getest, uitgaande van het feit dat het onderzoek correct is uitgevoerd is, en dat dit de conclusie is hoe kun je dan zeggen dat het resultaat overdreven is?

Klinkt als: Ik test onder 10000 vrouwen welke cupmaat ze hebben. De resultaten tonen aan dat van deze vrouwen er 5000 zijn die cupmaat B hebben. Vervolgens concludeer ik dat 50% van de vrouwen cupmaat B heeft. Overdrijf ik dan?

Geweldig! Het nieuwsbericht zegt niets maar dan ook werkelijk NIETS over open source of closed source. En toch gaat de discussie wat nu eigenlijk beter is open of closed source.

Ik zeg, wat betreft hackaanvallen op websites wordt niet gesproken welk van de twee veiliger is. Wat wel gezegd wordt dat 91 % van de websites kwetsbaar zijn voor hack aanvallen.

Ofwel stay to to topic!