Meer dan 70.000 WordPress-sites zijn onveilig door lek in plug-in

Door een kwetsbaarheid in de plug-in ThemeGrill Demo Importer loopt een groot aantal WordPress-sites het risico op verwijdering van inhoud. Onder bepaalde omstandigheden kunnen aanvallers beheerdersrechten verkrijgen.

WebARX, een beveiligingsbedrijf dat gespecialiseerd is in WordPress, meldt na onderzoek dat de versies 1.3.4 tot en met 1.6.1 van ThemeGrill Demo Importer kwetsbaar zijn. De kwetsbaarheid zat daarmee ongeveer drie jaar in de code. Aanvallers kunnen bepaalde code sturen naar WordPress-sites met de plug-in en zo de database terugzetten naar de beginstatus, waardoor alle inhoud verwijderd wordt.

De ThemeGrill Demo Importer wordt gebruikt door klanten van ThemeGrill, dat thema's levert voor WordPress-sites. Als een site met zo'n thema een gebruiker met de naam 'admin' in de database heeft, is het voor een aanvaller mogelijk beheerdersrechten te krijgen en zo de site over te nemen.

WebARX heeft de kwetsbaarheid op 6 februari gemeld aan ThemeGrill, dat tien dagen later een nieuwe versie met een patch vrijgaf. Die versie is inmiddels zo'n 28.000 keer gedownload en volgens de plug-instatistieken zijn er meer dan 100.000 installaties actief, wat het aantal kwetsbare websites op zeker 72.000 brengt. Volgens ThemeGrill zelf zijn de thema's van het bedrijf zelfs op meer dan 300.000 sites actief.

Door Olaf van Miltenburg

Nieuwscoördinator

18-02-2020 • 11:45

58 Linkedin

Submitter: TheVivaldi

Reacties (58)

Wijzig sortering
Man man man, wat een basale en makkelijk-te-voorkomen bug weer.

Om het even heel kort samen te vatten voor mensen die niet het hele verhaal willen lezen: het lek is dat er bij een administratieve functie helemaal geen toegangscontrole plaatsvindt, nul komma niks.

Dit is overigens ook wel een mooi voorbeeld van hoe het ontwerp van WordPress zelf (en in het bijzonder de plugin API) bijdraagt aan de constante stroom van beveiligingslekken in WP plugins, en WP core dus wel degelijk een beveiligingsprobleem heeft; een veilige plugin-architectuur zou bijvoorbeeld van hogerhand standaard toegang tot alle administratieve interne functies weigeren als de gebruiker niet ingelogd is met de juiste rechten.

Edit: oeps, Tweakers doet geen Markdown.

[Reactie gewijzigd door svenslootweg op 18 februari 2020 12:13]

Helaas geld dat voor elk open ecosysteem. Op Android kan je ook eenvoudig slechte apps instaleren. WordPress heeft, net als Android, een heel laag instapniveau en lang niet iedereen die aan WordPress sites werkt heeft de tijd en kennis om zelf plugins door te lichten. WordPress zou er goed aan doen om gebruikers duidelijk te maken dat het gevaarlijk is om plugins te installeren uit onbekende bronnen. Nieuwe releases/plugins/themes in WordPress.org Directory word namelijk netjes gecontroleerd door vrijwilligers van review team.
Je mist mijn punt. Dit is absoluut geen onoverkomelijk probleem; het is een kwestie van de interfaces die je aan ontwikkelaars vrijgeeft, zo bouwen dat onveilig gebruik moeilijk is en veilig gebruik makkelijk. Dit is een strategie die al met succes toegepast wordt door o.a. React (met dangerouslySetInnerHTML) en Rust (met unsafe blocks).

Ja, veel ontwikkelaars zullen niet competent genoeg zijn om uit zichzelf veilige software te bouwen. Maar die ontwikkelaars kun je wel degelijk ontmoedigen om dat te doen; door de onveilige weg bewust moeilijk te maken, waarvoor ik hierboven al een methode suggereerde om het terugkerende probleem van ontbrekende toegangscontrole in WP plugins te voorkomen (namelijk, dit op applicatieniveau standaard afdwingen).

Er zit een groot verschil tussen "sommige problemen hou je altijd" en "de huidige situatie is 100% niet te voorkomen noch te verbeteren". Er is, zeker bij WordPress (wat echt heel slecht ontworpen is), sprake van het eerste en niet het tweede geval.

Edit: En voor nog een concreet voorbeeld, dat een hoop omgevingsfactoren wegneemt: in de standard library in Node.js heb je twee verschillende manieren om een proces te starten (exec, dat onveilig is, en execFile, dat veilig is). Door de naamgeving kiezen veel mensen voor de onveilige versie, en dat zie je terug in het idiote aantal command injection vulnerabilities in veel libraries.

Aan de andere kant heeft de standard library tegenwoordig ook twee manieren om een Buffer (een byte array) van een bepaalde lengte te initialiseren; alloc is veilig, allocUnsafe is ietsje sneller maar onveilig. Door de naamgeving wordt allocUnsafe nauwelijks gebruikt, alleen als het echt nodig is om performance-redenen. Daardoor zijn memory disclosure vulnerabilities in Node.js vrijwel verdwenen.

Ik durf wel te stellen dat het API-ontwerp van een systeem een van de belangrijkste factoren (zo niet de belangrijkste factor) is voor de uiteindelijke veiligheid van het ecosysteem eromheen.

[Reactie gewijzigd door svenslootweg op 18 februari 2020 13:00]

Wordpress draait op PHP. Het is binnen PHP op dit moment niet mogelijk om andere PHP code in een sandboxed manier te draaien. Een plugin zou dus altijd bij het filesystem, en hierdoor dus ook de database komen.
Als je denkt dat Wordpress hier wel iets aan kan verbeteren, ben je van harte welkom in de Wordpress community.
Dat is een vervelende beperking van de runtime, maar ook niet onoplosbaar; het betekent alleen dat je je eigen veiligere API aan moet bieden, en moet concurreren op gebruiksgemak, zodat mensen je eigen API verkiezen boven generieke PHP-code. Er valt ook behoorlijk wat terrein te winnen door het bijvoorbeeld moeilijk te maken om direct bij de database client te komen, door naamgeving die iedere release verandert o.i.d.

Het gaat hier uiteindelijk niet om sandboxing ter voorkoming van kwaadaardige ontwikkelaars, maar om het voorkomen van fouten van welwillende ontwikkelaars. Daarvoor hoef je alleen maar de onveilige methode te ontmoedigen, je hoeft hem niet helemaal weg te halen.
Heel goed punt. Door expliciet de onveilige route te benoemen (bijv. allocUnsafe zoals je aangaf) wordt code ook makkelijk doorzoekbaar op dit soort keuzes van ontwikkelaars, bijvoorbeeld bij security audits. De welwillende ontwikkelaars nemen dan vrijwel automatisch de veilige route, en plugins/thema's/etc. die de onveilige methode gebruiken, kunnen zo heel makkelijk worden gevonden. Als er documentatie bij staat waarom ervoor is gekozen (en als het geen beveiligingsproblemen oplevert), dan prima, anders is het een goed haakje om de ontwikkelaar erover te contacteren.
PHP vertrouwt op de rechten van de user waaronder het process draait. Als een plugin bij het hele filesystem kan, zit er sowieso al wat fout in de veiligheid.

Je kunt voordat je project plugins gaat includen het volgende aanroepen.
ini_set("open_basedir", "/mag/alleen/hier/bij/komen:/of/tot/hier/");
En de zwakste schakel omdat gemak de mens dient (API).
Goed wanneer WordPress het zou aangeven, maar het lijkt me een vrij logisch iets dat de site-beheerder verantwoordelijk is en niet WordPress. Apple bijvoorbeeld krijgt alleen maar commentaar dat ze zo gesloten zijn. Dus wat is de middenweg? Dat iedereen zijn/haar eigen verantwoordelijkheid hierin neemt, dat is het mooie aan OSS. Niks staat mij in de weg om 'rm -rf /*' te doen op een BSD systeem, heerlijk...

https://www.brainyquote.com/topics/stupidity-quotes
Ik ben het niet met je stelling eens.

Wordpress heeft hier niet zoveel mee van doen, het thema zelf heeft er voor gekozen om dit niet achter de wordpress admin authenticatie te zetten.
Zie mijn comment hier: svenslootweg in 'nieuws: Meer dan 70.000 WordPress-sites zijn onveilig door l...

Het gaat er dus om dat dat thema die keuze uberhaupt niet hoort te hoeven maken. En dat is absoluut een Wordpress-probleem.
Hoe kom je daar bij?
Een Thema doet 90% van de zaken op de frontend, dus vrij logisch dat een thema ook unauthenticated mogelijkheden heeft.
Unauthenticated mogelijkheden zijn prima. Maar er is geen reden om een thema daar standaard toegang toe te geven terwijl de gebruiker niet als administrator ingelogd is. Dat is waar het fout gaat. Vrijwel alles wat een UI doet zou moeten gebeuren onder de rechten van de huidige ingelogde gebruiker.

[Reactie gewijzigd door svenslootweg op 18 februari 2020 13:08]

Wet je wel hoe Wordpress werkt?
Bij een thema is het noodzakelijk om aanpassingen te maken, ook als een gebruiker niet ingelogt is. Denk aan variaties van pagina's welke een redacteur wijzigt.
Een redacteur kan alleen pagina's wijzigen wanneer hij of zij ingelogd is, en op dat moment zou een thema dus ook gewoon toegang hebben tot de administratieve functies die daarvoor nodig zijn. Ik begrijp niet welk probleem je probeert te schetsen.
Thema voegt veel meer toe dan een stylesheet, header en footer.
Vaak ook pagebuilder, sidebars, functionaliteiten tot sidebars, aanvullende functionaliteiten voor het laden van data, shortcodes, etcetcetc.
Prima, maar wederom: ik zie niet in waarom dat toegang tot administratieve functies zou moeten hebben op het moment dat iemand niet in een administratieve rol ingelogd is.
Maar dat lijkt mij vanzelfsprekend en dat is het hele punt dat er nu dus een vuln is ontstaan...
Nee, dat is dus niet het geval. Het is hier fout gegaan omdat de plugin in kwestie altijd toegang heeft tot administratieve functies, ook als de gebruiker helemaal niet ingelogd is. De plugin zelf doet geen authenticatie, en daarom kan iedereen dit lek uitbuiten.

Dit had dus van hogerhand, in core, voorkomen moeten worden door de plugin geen administratieve functies aan te laten roepen wanneer de gebruiker niet ingelogd is in een administratieve rol. Dat is niet gebeurd, en is een gebrek in core.
Neem een contactformulier.

Dat moet ingezonden worden door een gebruiker. Vervolgens moet de inzending opgeslagen worden in de database.

Dat is nog maar 1 voorbeeld waarbij de gebruiker "zonder adminstratieve rechten" schrijfrechten voor de database nodig heeft.

[Reactie gewijzigd door jrswgtr op 18 februari 2020 21:56]

Ik weet niet of deze fout perse bij WP ligt. Als ik een pakket toevoegd aan bijvoorbeeld een Laravel project, dan kan daar ook een fout inzitten waardoor er op rechtengebied alles misgaat. Soms moet je als pakketbeheerder ook extra checks doen, dan lijkt hier niet gebeurd te zijn?

Overigens heb ik geen goede ervaringen met WP, mede doordat er veel gebruikers zijn zonder goede programmeer kennis, niet zeggende dat ik die wel heb. Ik heb ontzettend veel brakke legacy code & plugins gezien en ook betaalde die je geen gratis upgrades geven bij WP updates als je hun pakket koopt. Nog erger is dat klanten perse WP verwachten omdat iedereen dat draait en er vervolgens zelf allemaal plugins en thema's aan gaan toevoegen.

WP heeft de markt opengezet voor programmeurs met weinig kennis of ervaring en heeft de webdeveloper markt wel stuk gemaakt. Gebruikers moeten niet altijd alle tools in handen hebben, dat heb ik ook niet met mijn auto.
Als mini ondernemer vind ik Wordpress juist geweldig. Zeker nu hostingpakketten gelijk de installatie voor je doen. Als je ook maar een beetje affiniteit hebt met computers dan kan je je eigen website maken. Zelfs Google vind het prima want mijn ranking is uitstekend.

Het is wel zo dat het niet zonder risico is. Gemiddeld 1x per jaar een kleine issue. Dat is te overzien. Het is ideaal voor mensen die met een eenvoudige site met een minimaal aantal plugins tevreden zijn. Voor klanten is het vaak ook 'less is more'. Het moet netjes zijn en dan is het prima. Wordpress is ideaal want zoveel sites lijken op elkaar. Dus met weinig moeite kan je een representatieve site maken.

Dat het de webdeveloper markt 'stuk' heeft gemaakt vind ik niet. Ja, de tijd van makkelijk verdienen aan onwetenden is voorbij. Nu zal er echt iets moeten worden neergezet wil het een flinke prijs rechtvaardigen. Net zoals ondernemers ook echt iets moeten bieden om klanten zo ver te krijgen om de knip te trekken.
Achja, WP Core gebruikt vooralsnog shims om PHP compatibiliteit te garanderen, ik denk dat exploits het laatste is waar het WP development team aan denkt
Het verbaast me zeer dat dit de frontpage haalt. Er zijn dagelijks ladingen aan kwetsbaarheden in WP plugins, Joomla plugins en andere CMS systemen, waar niet over geschreven wordt.

Zelfs de omvang is klein, volgens themegrill.com draaien ze op slechts "300,000+ sites".

[Reactie gewijzigd door mmjjb op 18 februari 2020 12:07]

Inderdaad. Klopt. Check https://wpvulndb.com/ maar eens ...
Dat het 28.000 keer gedownload is wil niet zeggen dat dit allemaal is vanwege de bugfix. Hierin zitten ook nieuwe wordpress installaties tussen.
En waarschijnlijk beveiligingsexperts die benieuwd zijn naar de bug en de bijbehorende fix.
Ja. Statistisch gezien enkele tientallen van die 28.000. Niet echt relevant dus.
vrije plug-ins met diepe rechten door derden zullen altijd dit risico dragen. Zij het voor WP, Chrome of andere apps die flink wat data "bevatten". Veel mensen, zelfs in de IT, beseffen niet hoeveel aanvalsvectoren er per moment actief zijn om zelfs het kleinste beetje voet tussen eenderwelke deur te krijgen. Allemaal geautomatiseerd.

Data is het nieuwe goud.

[Reactie gewijzigd door Division op 18 februari 2020 12:00]

Inderdaad - ik heb een beveiligingsplug draaien en je wilt echt niet weten wat voor truken er worden geprobeerd om je site onderuit te halen. Sommige slaan nergens op - veel van deze hackpoging gaan direct in op lekke plugins - updaten dus.. en backups maken zodat je terug kan in geval dat het toch gelukt is.
Totdat er een lek in die plugin zit...

Blogs en simpele content sites moeten gewoon met static site generators gemaakt worden.
Waarom moet dat?
Het is steeds gebruikeliker om dynamische content te genereren voor een user specifiek.
Als je al een user met admin of root aanmaakt dan ben je sowieso dom bezig. En zo zie je maar weer. Zo'n lek was te voorkomen als je geen admin account hebt.

Eigenlijk zou Wordpress een verbod moeten instellen op admin en root account namen tijdens installatie.
Als er geen admin user bestaat, hoe moet je dan je website updaten, plugin installeren, etc?
Simpel: Een andere user met admin rechten.

Die kun je bij installatie aanmaken. Maar de meeste kiezen dan blijkbaar voor de standaard “admin” user.
Dan heb je toch nog steeds een user met admin? Volgens luchtbakker ben je dan dom..

Of gaat het om de username, dat maakt ik niet op uit zijn opmerking.
Ik wel (al schrijft hij het wat ongelukkig), lees de laatste zin van zijn post nog maar een keer.
Ah ja, daar kan ik me wel in vinden. Ook omdat het gewoon ongelukkig er uit ziet om een blogpost op je website te hebben door auteur 'admin'.
je kan een username admin hebben met Displayname Pietje Puk. Handiger is om de hele username admin niet te gebruiken.
Inderdaad is het al vaker gebleken dat de standaard ‘admin’ en zelfs de ‘hello world’ post een aanknopingspunt kunnen zijn voor hackers.

Tip van Flip is om die meteen te verwijderen bij elke verse installatie.

Ook het hernoemen van de (administrator) login pagina maakt het aanvallers lastiger. Nee, het garandeert niks maar het is lastiger morrelen aan het slot als je de deur niet kunt vinden.
Valt nog wel mee als je bekijkt hoeveel wordpress er niet is en gebruikt wordt. Natuurlijk iets dat veel gebruikt wordt is een goed target. En laat er dan net zoveel plugins zijn, tsja recipe for disaster.
Hierom override ik altijd de standaard admin username.
Dat had je in dit geval niet geholpen, uit het bron-artikel:
In versions 1.3.4 and above and versions 1.6.1 and below, there is a vulnerability that allows any unauthenticated user to wipe the entire database to its default state after which they are automatically logged in as an administrator.
Als je dan doorleest na de advertentie die daaronder staat:
The prerequisite is that there must be a theme installed and activated that was published by ThemeGrill. In order to be automatically logged in as an administrator, there must be a user called “admin” in the database.
De fix van Henk verhelpt niet de hele vulnerability; de site zou alsnog worden gereset, maar de aanvaller zou vervolgens niet zijn ingelogd als admin.

Ingelogd zijn als admin op een verse WordPress-installatie is natuurlijk problematisch: diegene zou de site (ongeveer) kunnen herstellen als vóór de hack, en latere nietsvermoedende bezoekers gegevens laten invullen waar de aanvaller iets kwaadwillends mee zou kunnen.

[Reactie gewijzigd door CodeCaster op 18 februari 2020 13:14]

Je hebt gelijk. Dank voor de verheldering!
Artikel en andere comments uberhaupt gelezen?
Ik prefereer eigen code sowieso al over deze open-source projecten. Het is niet altijd fijn om de (normaal verborgen) code van je website beschikbaar te hebben voor iedereen, dat maakt je kwetsbaar. Nu gaat het om oude versies van een plugin, maar er hoeft maar een update uit te komen in een van de huidige versies van Wordpress met zo'n lek dat ontdekt wordt en iedereen loopt gevaar. Gooi er dan nog wat onbetrouwbare plugins bij zoals die uit het artikel en voor je het weet krijg je dit soort taferelen, redirects etc.

Wat mij betreft is het vooral leuk voor webdesigners die verder weinig verstand hebben van het bouwen van een achterliggend systeem, de buurvrouw die zelf de teksten op haar website met gedownloade template wil aanpassen enzovoort. Maar ik blijf me erover verbazen dat mensen die het zelf kunnen steeds vaker tóch voor Wordpress kiezen - ik zie het in ieder geval in de professionele wereld vaker gebeuren.

[Reactie gewijzigd door crazyboy01 op 18 februari 2020 13:42]

Dat dacht ik ook, tot ik de wereld van open source ontdekte.
Een developer die denkt het beter te weten dan 10000en andere is vaak een slechte developer.

Dat software closed source is maakt het net zo goed kwetsbaar, jij hebt geen code controle van een aanvullende developer.
De wereld van open source projecten is zeker mooi, begrijp me niet verkeerd. Het klopt ook wel wat je zegt, het grootgebruik en tests is als kleine developer niet te evenaren. Ik ben als beginnende ontwikkelaar ook zeker niet altijd zeker van mijn zaak, en loop daardoor waarschijnlijk meer risico. Ondanks dat blijft het een raar gevoel wanneer ik een uitgebreide code als die van Wordpress opneem in projecten onder mijn verantwoordelijkheid. Het is niet "bewezen veilig". En ondanks dat je bij eigen closed source dus net zo goed kwetsbaar bent, of misschien soms veel kwetsbaarder, kunnen mensen niet onder de motorkap kijken. Het lek moet dan dus wel van buitenaf worden gevonden, en dat geeft weer een ander soort "zekerheid". Als je daar in het bedrijfsleven dan wel met een team aan werkt en een aantal goede penetratietests laat uitvoeren, dan ben je in mijn ogen aardig safe voor de basisaanvallen. Het geeft mij in ieder geval meer vertrouwen.

Neemt niet weg dat kwetsbaarheden altijd een ding zullen blijven. Tenzij je echt enkel statische pagina's nodig hebt, iets dat ik dus ook liever gebruik als er gewoon niet meer nodig is...
Geloof me dat de code nauwelijks verschil maakt.
Je eigen brouwsel kan gewoon geautomatiseerd aangevallen worden met de standaard aanvallen en tenzij jij je daar in verdiept hebt ga je voor gaas.
Maar in de genoemde penetratietests die je laat uitvoeren kun je dat soort geautomatiseerde scripts toch ook opnemen? En verdiepen in de kwetsbaarheden die je wil voorkomen in je eigen applicaties is altijd aan te raden. Ik snap niet waarom we ons door angst zouden moeten laten ontmoedigen zélf een veilige applicatie te leren bouwen en we in plaats daarvan proberen een Wordpress expert te worden.

Het is natuurlijk anders als vanuit een hobby werkt. Wanneer je dus echt alleen bent en niets of weinig te investeren hebt. Maar vanuit dat oogpunt is mijn reactie niet geschreven. Ik ben er ook niet op uit om Wordpress volledig af te kraken, ik zie gewoon niet enkel voordelen wanneer je als professional de tools hebt om zelf iets goeds neer te zetten.
Ik heb het zelf ook niet op Wordpress hoor ;)
Maar alles compleet zelf bouwen is een slecht idee. Je kan beter op een goed framework a la Symfony leunen zodat de moeilijke basis correct is.

Ik spreek uit ervaring dat dingen als permissie-management, database lagen ed moeilijk zijn om correct en veilig te maken.

[Reactie gewijzigd door hackerhater op 18 februari 2020 16:52]

Het moet ook beetje economisch en efficient zijn. Werk al sinds 2005 met Joomla, geen spijt van. Ook met WP omdat ik voor sommige klanten wel moet. Kan met beide uit de voeten maar is wel belangrijk welke theme's (voor Joomla bouw ik ze zelf, voor WP bijna nooit) en plugin's je gebruikt om het een beetje veilig te houden. En dan natuurlijk je omgeving en de updates. Tot nu toe altijd goed gegaan, knock on wood. Maar vraagt wel discipline.
Krijg wel regelmatig een opdrachtje om een kaduke of gehackte Wordpress -en soms ook Joomla- site in orde te brengen. Wat ik dan allemaal tegenkom is tenenkrommend. Maar ja, die klanten wordt door diverse mensen met een hoop kul verhalen verleid. Mag ik het weer oplossen. Doe het graag.
Wederom een reden waarom ik weg blijf van WP. Geef mij maar Joomla. Niet dat ik zeker ben dat het extreem veel veiliger is, maar naar mijn bescheiding mening wel. Veel minder meldingen, en past perfect bij mjin noden. Wat ik op WP zou kunnen doen doen, kan ik op J! ook. Het omgekeerde is niet altijd waar, of even makkelijke doenbaar.

Maar das puur gebaseerd op eigen testen / draaiende sites.
Ik beveilig met regelmaat wordpress, en mijn leer is is dat je plugins, thema's, die je niet langer nodig meer hebt of gebruikt, standaard uit moet schakelen en het liefst gewoon volledig verwijderen doet. Ook het debiele aan wordpress is is dat het steeds een reinstall van een nieuwe thema twenty-nogwat plaatst en uit het verleden gebleken is is dat ook deze thema's gewoon gatenkaas waren wat betreft veiligheid.

Ik heb aardig wat live sites staan in opdracht voor klanten en ook deze zetten we automatische updates in iedere vorm dan ook uit. Als we de boel gaan updaten standaard een backup, alles bijwerken en testen op werking. Dat is tijdrovend, maar daar wordt ik ook gewoon voor betaald. Het is tevaak voorgekomen dat een update roet in het eten gooit qua werking website en alles gewoon stuk gaat. De changelog lezen is ook raadzaam.

Onbegrijpelijk dat het wel 40% van het internet dekt inmiddels. Ik krijg echt gigantisch veel bruteforcepogingen op websites her en der.

[Reactie gewijzigd door Jism op 18 februari 2020 22:14]

Kies score Let op: Beoordeel reacties objectief. De kwaliteit van de argumentatie is leidend voor de beoordeling van een reactie, niet of een mening overeenkomt met die van jou.

Een uitgebreider overzicht van de werking van het moderatiesysteem vind je in de Moderatie FAQ

Rapporteer misbruik van moderaties in Frontpagemoderatie.



Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone SE (2022) LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S22 Garmin fēnix 7 Nintendo Switch Lite

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

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee