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

Nederlands hackproject ontdekt kwetsbaarheden in vijf Wordpress-plug-ins

Het Nederlandse hackproject Summer of Pwnage heeft kwetsbaarheden in verschillende Wordpress-plug-ins ontdekt. Het gaat om WooCommerce, Ninja Forms, Icegram, Video Player en Paid Membership Pro. Er zijn inmiddels updates beschikbaar.

Het project heeft verschillende advisories gepubliceerd. Er zijn meerdere kwetsbaarheden gevonden, omdat Wordpress op dit moment het onderwerp is van Summer of Pwnage. De plug-in WooCommerce wordt door miljoenen websites gebruikt, zo stelt ontdekker Han Sahin. De kwetsbaarheid betreft een cross-site scripting-lek, waardoor een aanvaller door middel van een speciaal gegenereerde afbeelding sessietokens en login-gegevens kan stelen. Het lek is verholpen in versie 2.6.3 van de plug-in.

De Ninja Forms-plug-in is in gebruik op ongeveer 600.000 sites. Het lek in deze software betreft eveneens een xss-bug en stelt een aanvaller in staat om kwaadaardige javascript-code uit te laten voeren binnen de applicatie. Een oplossing is aanwezig in versie 2.9.52. Bij de minder populaire Video Player-plug-in gaat het om een sql injection-lek. De overige twee plug-ins zijn eveneens vatbaar voor xss.

Summer of Pwnage vindt gedurende de maand juli plaats in Amsterdam.

Door Sander van Voorst

Nieuwsredacteur

20-07-2016 • 14:42

97 Linkedin

Reacties (97)

Wijzig sortering
Ik denk dat men doelt op het amateur niveau van de codebase, die dramatisch is op gebied van zowel security als performance.
Tis gratis als je hosting neemt en makelijk dus wat wil je nog meer
Dat het veilig is?

(Echt. Het wordt eens tijd dat er wetgeving komt omtrent aansprakelijkheid van websitebeheerders voor schade opgelopen door het bezoeken van een gecompromiteerde site. Dan zal het snel afgelopen zijn met broddelcode.)

[Reactie gewijzigd door R4gnax op 21 juli 2016 09:25]

WordPress is niet mijn favoriete systeem, ik heb ondertussen een flink aantal klanten tot grote tevredenheid overgezet naar het modernere en krachtiger https://Bolt.cm

Maar het is niet te ontkennen dat in de afgelopen jaren WordPress zo'n fenomeen geworden dat mensen vaak niet beter weten. En we moeten niet vergeten dat er in de tijd vóór WP eigenlijk niets was wat eraan kon tippen.
Ik weiger XSS 'exploits' als 'exploit' te erkennen. Het is een front-end slordigheidje.
XSS is net zo'n 'slordigheidje' als dat SQL injection is. In de basis is het precies dezelfde fout die gemaakt wordt: namelijk de input van een gebruiker wordt klakkeloos gebruikt zonder deze onschadelijk te maken. Dat er daarbij wel een verschil in impact zit ben ik met je eens, maar XSS kan net zo goed een ernstig tot kritieke impact hebben.

Eén goedgeplaatst linkje naar een administrator, die voor het gemak zijn wachtwoord in de browser bewaard, is voldoende om administratorrechten te krijgen. Of een admin die niet uitlogt waarvan je zijn sessie kan overnemen.
Ik ben het er zeker mee eens, dat XSS per definitie opgelost moet worden.
'k Denk alleen terug aan de tijd dat een directeur van een of andere grote toko heel errug boos werd, want de website was gehackt! (oftewel, het doodshoofdje in de zoekresultaten).

Dat al hun core business processen zo lek als een mandje waren/zijn, boeit hem geen reet. Maar een 15 jarige, die een doodshoofd plaatst.. Oh jee.
Daarna werd een marketeer projectleider en faalde elk nieuw project.
Het is een front-end slordigheidje.
Dat maakt het veiligheidsrisico er niet minder ('erg') op. Met zo'n redenatie zijn alle security leaks 'een slordigheidje' namelijk. Ik heb echt het idee dat je security ernstig onderschat. Het voorbeeld wat je noemt kan iedereen inderdaad met een beetje Photoshoppen, daar kun je makkelijk doorheen prikken, totdat een dergelijk lek een keer wel voor problemen zorgt. ;)
Het maakt het veiligheidsrisico zeker minder. Gezien je er verder geen gegevens mee los kan futselen en wat dan ook.
Ik onderschat security niet, ik maak onderscheid tussen prioriteit/impact. (iets wat management/directie doorgaans niet kan en puur vanuit emotie stuurt)

Even los van het feit, dat je dit soort exploits niet hoort te maken, als je een ervaren developer bent. (beetje eerste jaars / junior foutjes zijn dit)

Exploits ala een algemene ingang in een media library, waardoor je bijvoorbeeld database credentials kan achterhalen. Die zijn wat ernstiger.
Meh. Ik weiger mee te doen aan dingen, waar 'pwn' serieus in gebruikt wordt.
Doet me iets teveel denken aan alle kinderen online, die constant (nieuwe) spelers verbaal lopen aan te vallen.

Dat soort titels helpen niet de evenementen serieus genomen te laten worden. Daarbij heb ik de tijd niet.
Zolang je maar wel de lekken blijft patchen die tijdens dat soort events gevonden worden ;-)

Niet serieus?:

http://www.securityweek.c...-earn-460000-21-new-flaws
Ondanks dat ik een negatieve vote kreeg, was ik best serieus en vind ik dat je een goede vraag stelt.

In de web frameworks zoals ASP.Net (*) zijn dit soort dingen vrijwel onmogelijk, simpelweg omdat het raamwerk al allerlei logica heeft om dingen als sql injection, cross side scripting, ellende als gevolg van escaping, etc, etc automatisch wordt opgelost. Natuurlijk kan je ook ellende krijgen zoals hier (en zijn er ook dingen waar je op moet letten), maar je moet er actief moeite voor doen. (*Note: er is best een hoop mis met ASP.Net, maar dit soort dingen zijn echt heel veel beter geregeld)

PHP is daarin precies omgekeerd. Je krijgt default mogelijk ellende en moet actief de juiste dingen doen om dat te voorkomen. Natuurlijk is het allemaal geen garantie, maar het maakt de kans op ellende wel aanzienlijk groter.

Om die reden exposed Wordpress ook allerlei functies, die als een soort van 'library' dienen en een deel van deze problemen oplossen. Een deel van de modules gebruikt deze, een deel niet... nergens wordt een goede manier van werken afgedwongen.

Combineer dat met het feit dat de meeste programmeurs echt niet weten welke risico's ze allemaal lopen met bepaalde code - en je komt vanzelf op mijn conclusie.

[Reactie gewijzigd door atlaste op 21 juli 2016 08:29]

Je vergelijkt hier een programmeertaal met een programmeer framework. Appels en peren.

Indien je ASP zonder .NET zou gebruiken dan zou je het kunnen vergelijken met PHP
Indien je PHP met framework zou gebruiken dan zou je het kunnen vergelijken met ASP.Net.
Nee, daarin zit precies de crux: Je kan ASP niet gebruiken zonder .NET. There's no such thing.

De vergelijking dat .NET zonder ASP hetzelfde is als PHP gaat volgens mij ook niet op: op het moment dat het primaire doel is van PHP om websites te renderen (lees: zoals iedereen doet), vind ik de vergelijking prima valide. Daar worden libraries voor gebruikt uiteraard; niemand gaat zelf een MySQL connector maken om een praktisch voorbeeld te noemen.

Vervolgens moet je m.i. kijken naar hoe mensen het gebruiken en kunnen gebruiken. Nogmaals, je kan er altijd omheen werken (je kan in ASP.NET ook een eigen HTTP handler schrijven en direct HTML emitten) -- maar niemand doet het, omdat goed gebruik min of meer wordt afgedwongen. Je kan er zelfs ook met heel veel truuks een console applicatie in schrijven... het is alleen complete waanzin.

Het zou m.i. accurater zijn om te zeggen dat ik: groene appels en rotte appels vergelijk. Van beiden kan je appelmoes maken en met voldoende smaakstoffen proef je het verschil vast niet als consument. Zelf eet ik echter een stuk liever appelmoes van groene appels.
In elke programmeertaal en framework kun je rotte applicaties schrijven.
In elke programmeertaal en framework kun je goede applicaties schrijven
Het hangt van de kunde en kennis van de programmeur af of de applicaties goed of rot is.

Je opmerking m.b.t. rotte appels is m.i. een troll-opmerking
Het hangt van de kunde en kennis van de programmeur af of de applicaties goed of rot is.
Ik dacht dat ik duidelijk ben geweest, maar blijkbaar niet...

Iedereen maakt fouten, ook de beste programmeur. In het geval van een goed raamwerk, is de kans op fouten klein. In het geval van een slecht raamwerk, is de kans op fouten groot. Zo je wilt vind ik PHP een slecht raamwerk, waar ik volgens mij goede argumenten voor heb.

Als je in een type safe language een variable gebruikt van het verkeerde type, kan je proberen wat je wilt, maar zal je nooit een website krijgen. Analoog daaraan zal je in Java en C# nooit een buffer overflow krijgen of een stuk geheugen wat je meerdere keren dealloceert (maw: issues in C/C++), omdat het framework je daar tegen beschermd.

Als je een ASP.Net applicatie maakt, kan je HTML content in een label gooien wat je wilt, met post data smijten naar de server, etc, etc. -- maar je zal daarmee nooit een security issue introduceren. En ook dingen als SQL injection zijn zo goed als onmogelijk; daar moet je echt code voor gaan schrijven (lees: je best voor doen).

Het gaat niet om dat het niet mogelijk is, het gaat erom dat je de (goede/slechte) programmeur beschermt tegen het maken van fouten. Want iedereen maakt weleens fouten. Daarin zit de crux.
Je opmerking m.b.t. rotte appels is m.i. een troll-opmerking
Welnee, ik maak gewoon de vergelijking kloppend, ik heb nergens iemand persoonlijk aangevallen imho.

Op dit item kan niet meer gereageerd worden.


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True