Als een WordPress-site wordt gehackt, staat de kwaadaardige code opvallend vaak op één plek: in de map met uw geüploade bestanden. Wie PHP blokkeren uploads map als maatregel doorvoert, haalt daarmee een van de meest gebruikte routes weg waarlangs een klein lek uitgroeit tot een blijvende inbraak.

Het is een van die maatregelen met een uitstekende verhouding tussen moeite en effect: een paar regels, geen zichtbare gevolgen voor bezoekers, en een deur die dicht blijft. Hieronder leest u waarom die map zo aantrekkelijk is en hoe u het regelt.

Waarom uitgerekend die map

In wp-content/uploads komt alles terecht wat via de mediabibliotheek binnenkomt: afbeeldingen, pdf’s, documenten. De map heeft drie eigenschappen die hem aantrekkelijk maken voor misbruik.

  • Er mag geschreven worden. Dat moet ook, anders kunt u niets uploaden. De rechten staan er dus ruimer dan elders.
  • Hij is publiek bereikbaar. Elk bestand erin is direct op te vragen via een webadres.
  • Hij is onoverzichtelijk. Na een paar jaar staan er duizenden bestanden verspreid over tientallen jaar- en maandmappen. Eén extra bestand valt niemand op.

Lukt het een aanvaller om via een lek in een plugin een bestand met de extensie .php in die map te zetten, dan kan hij dat bestand daarna gewoon in zijn browser openen. En op dat moment draait zijn code op uw server, met alle rechten van uw website. Dat is precies hoe een achterdeur ontstaat die blijft werken nadat u de plugin heeft bijgewerkt, zoals beschreven in het artikel over achterdeuren die een schone site opnieuw besmetten.

Wat de maatregel doet

U vertelt de webserver dat bestanden in die map nooit als programmacode mogen worden uitgevoerd, maar altijd als gewoon bestand moeten worden geserveerd of geweigerd. Afbeeldingen, pdf’s en documenten blijven precies zo werken als voorheen. Alleen code doet niets meer.

Belangrijk om te begrijpen: dit voorkomt niet dat er een bestand in de map belandt. Het voorkomt dat het bestand iets kán. Dat is een verschil dat ertoe doet, want het betekent dat u het onderliggende lek nog steeds moet dichten met updates.

Wat het wel doet, is de aanval waardeloos maken. Een aanvaller die zijn bestand keurig heeft geüpload en het daarna opvraagt, krijgt niets bruikbaars terug. Voor geautomatiseerde aanvallen, en dat is het gros, betekent dat simpelweg het einde van de poging.

Zo regelt u het

Op een Apache-server

Maak in wp-content/uploads een bestand met de naam .htaccess en zet daarin een regel die het uitvoeren van bestanden met de extensie php, php5, phtml en phar weigert. In vrijwel elke handleiding staat een blok met een deny-regel voor die bestandstypen; neem er ook de varianten in mee, want alleen .php afsluiten laat de rest open.

Controleer daarna twee dingen: of uw afbeeldingen nog zichtbaar zijn en of u nog kunt uploaden. Gaat er iets mis, dan verwijdert u het bestand en is alles direct terug bij het oude.

Op een Nginx-server

Daar werkt .htaccess niet. De regel moet in de serverconfiguratie staan, en dat kunt u meestal niet zelf. Vraag het uw hostingpartij; het is een standaardverzoek en veel partijen hebben het al ingericht.

Via een beveiligingsplugin

Wordfence, Solid Security en vergelijkbare plugins hebben hier een instelling voor, vaak onder een naam als het beschermen van de uploadmap. Snel geregeld, met dezelfde kanttekening als altijd: schakelt u de plugin uit, dan verdwijnt de bescherming mee.

Waar het misgaat

Er zijn twee situaties waarin deze maatregel iets breekt, en het is beter om ze vooraf te kennen.

Een plugin die code in de uploadmap zet. Dat hoort niet, maar het gebeurt. Sommige cachingplugins, formulierplugins en paginabouwers schrijven daar bestanden weg die wél uitgevoerd moeten worden. Merkt u na de wijziging dat een onderdeel niet meer werkt, dan is dat vrijwel altijd de oorzaak. De nette oplossing is een uitzondering voor dat ene bestand, niet het weer openzetten van de hele map.

Een aparte map met eigen scripts. Heeft iemand ooit een klein hulpprogramma in uploads geparkeerd, dan stopt dat. Meestal is dat juist het moment om het naar een fatsoenlijke plek te verhuizen.

Test daarom na de aanpassing altijd het uploaden van een afbeelding, het versturen van een formulier met bijlage, en bij een webshop het downloaden van een digitaal product.

Wat er nog meer bij hoort

Deze maatregel staat zelden alleen. Drie aanvullingen die er logisch bij passen:

  1. Beperk welke bestandstypen er geüpload mogen worden. WordPress laat standaard al veel niet toe, maar plugins verruimen dat soms. Sta alleen toe wat u werkelijk gebruikt.
  2. Zet mapindexering uit, zodat de inhoud van de map niet te doorzoeken is. Hoe dat werkt, staat in de uitleg over het uitzetten van directory listing.
  3. Ruim de map op. Oude exports, back-upbestanden en testbestanden horen er niet in. Wat er niet staat, kan ook niet lekken.

Laat u bezoekers zelf bestanden uploaden via een formulier, bijvoorbeeld voor sollicitaties of offerteaanvragen, dan is deze maatregel geen luxe maar noodzaak. Zonder blokkade is zo’n formulier een open uitnodiging om code op uw server te zetten.

Bij WebMaintor staat deze regel op elke site die wij in beheer nemen, samen met de rest van het dichtzetten van veelgebruikte inbraakroutes. Het kost eenmalig een kwartier en het is een van de weinige maatregelen waarvan we bij een besmetting achteraf konden vaststellen dat hij daadwerkelijk erger heeft voorkomen.

Concrete volgende stap: vraag uw hostingpartij of het uitvoeren van PHP in de uploadmap bij u al geblokkeerd is. Is het antwoord nee, dan weet u wat er deze week nog geregeld kan worden.