Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 56 reacties
Bron: Acunetix

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.

Moderatie-faq Wijzig weergave

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.
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, :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
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 |:(
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.
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
Ze hebben later zelfs Mambo omgedoopt naar Joomla om van de foute PR af te komen.
Wat? |:(
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...
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...
Dus ze hebben ongevraagt sites met scripts gebombardeerd.
Dus ze zijn eigenlijk bezig geweest als hackers.
Foei.
Ik mag toch alles wat wil sturen naar een webserver? Ik heb nergens een contract getekend waar staat dat ik alleen maar input van een bepaalde vorm naar dat ding stuur. Stel ik haal per ongeluk een webserver down, ben ik dan strafbaar?
Nee, dat is niet zo. Je mag ook niet maar aan willekeurige voordeuren of autoportieren gaan rommelen om te kijken of ze open staan.
En als je in een openbare bibliotheek gaat tellen hoeveel camera's er hangen?
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.
Is die zogenaamde Web Vulnerability Scanner van Acunetix voor iedereen beschikbaar?

Beetje raar als ze anders dit soort berichten de wereld insturen, ze hebben blijkbaar een methode om deze beveiligingslekken op te sporen maar stellen dit niet beschikbaar!

edit: Okee, hier moet je dus voor betalen zie ik alweer! Blijkbaar een software pakket waar een gratis trial voor te downloaden is. Toch jammer dat dit soort dingen niet tot het publieke domein behoren. Meeste websites die ik beheer zijn voor non-profit organisaties die niet kunnen betalen voor dit soort tools.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True