Hoofdcategorieën
Device Settings

'Veel websites kwetsbaar voor hackaanvallen'

Door René Wichers, woensdag 14 februari 2007 10:36
Bron: Acunetix, views: 18.943

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-logo 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.

Volgende 11:42 Australische telco claimt afstandsrecord hsdpa-netwerk
Vorige 23:49 Kodak vraagt patent op eetbare rfid-tag aan
Advertentie

Reacties

«  1  2  3  »

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.

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

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, 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.

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 |:(

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, :D

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

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...

in mijn ogen wordt dit ook al tijden gebruikt in sommige warez scenes, daar gebruiken ze ook op grote schaal sql injection om servers te hacken voor eigen doeleinden, niet echt iets nieuws voor mij dus

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.

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...

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

Ik kan er van meespreken van fouten. In meen naam kom er een apostrof voor en ik kan zo enkele commerciële websites noemen waar zo een zwakke fout zit. Waaronder zelf 1 hosting bedrijf waar ik nog heb gezeten.

Ze mogen allemaal van geluk spreken dat ik zo een lieve jongen ben en niet heel hun db leeg maak.

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.


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).

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)

Uw WC is mogelijk smerig, wij van WC eend kunnen U helpen.

Oh, en verder is water nat en gras vaak groen.

Bij de eerste site die je tegen komt, typ daar
<marquee><b><h1>OWNED</h1></b></marquee>
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 11:42 Australische telco claimt afstandsrecord hsdpa-netwerk
Vorige 23:49 Kodak vraagt patent op eetbare rfid-tag aan
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011