Binnen applicaties als Joomla! is het mogelijk om vanuit de applicatie zelf bestanden aan te maken of te wijzigen. Zo wordt de Globale Configuratie van Joomla!
bijvoorbeeld opgeslagen in het bestand "configuration.php". Hiervoor heeft Joomla! natuurlijk schrijfrechten nodig op dat bestand. En aangezien Joomla! een
webapplicatie is geschreven in de taal PHP, die weer wordt geïnterpreteerd door de webserver (bijvoorbeeld Apache), is het nodig dat uiteindelijk de
webserver schrijfrechten heeft op dat bestand.
Er zijn veel manieren om de webserver schrijfrechten te geven op een bestand, maar de meest bekende methode is door het bestand de permissies 777 mee te
geven. Deze methode wordt door beveiligingsexperts gezien als uiterst gevaarlijk. In dit artikel leggen we eerst uit wat deze permissies betekenen, om
vervolgens te onderzoeken of deze beveiligingsexperts het wel bij het rechte eind hebben.
Een woord over UNIX permissies
Binnen UNIX systemen zoals Linux of BSD heeft een bestand of directory altijd een eigenaar en een groep. Iedere eigenaar komt overeen met een gebruiker binnen
het UNIX systeem, en iedere gebruiker is altijd onderdeel van minstens één groep. Als een bestand eigendom van een gebruiker "barin" is, dan mag de
gebruiker "vultan" dit bestand niet weggooien, maar als dit bestand van "barin" in een directory staat met als eigenaar "vultan" dan mag dat wel.
Binnen UNIX wordt naast een eigenaar ook een groep gedefinieerd. De gebruiker "barin" is misschien onderdeel van de groep "barin" maar ook van de groep
"users". Daarnaast wordt er naast de eigenaar ("user") en de groep ("group") nog een derde toegangsniveau gedefinieerd: De rest van de wereld ("other").
Per toegangsniveau ("user", "group" en "other") kunnen permissies worden gezet. De permissies zijn ook in drievoud: Lezen ("read"), schrijven ("write") en
uitvoeren ("execute"). Lezen en schrijven zijn permissies die voor zichzelf spreken, maar met "execute" is wat extra uitleg handig:
Als een bestand een script of programma is, dan moet dit programma uitgevoerd kunnen worden: Hiervoor is dus de permissie "execute" nodig. Dat betekent dus
allereerst dat als een bestand
geen script of programma is, de "execute" permissie dus ook overbodig is.
Binnen UNIX worden de 3 permissies voor de 3 toegangsniveaus als volgt weer gegeven:
rwxr-xr--
Een bestand met deze permissies is voor de eigenaar leesbaar ("r"), schrijfbaar ("w") en uitvoerbaar ("x"). De groep heeft alleen leesrechten en uitvoerrechten,
maar geen schrijfrechten ("-"). De rest van de wereld (iedereen die dus niet de eigenaar is of tot de groep behoort) heeft alleen leesrechten.
Een directory wordt binnen UNIX gezien als een bestand met speciale eigenschappen. Om binnen een directory te navigeren, wordt deze directory "uitgevoerd".
Voor een directory zijn dus "execute" rechten nodig.
Er is ook een numerieke notatie voor de permissies mogelijk. Hierbij wordt aan "read" het getal 4 gekoppeld, aan "write" wordt het getal 2 gekoppeld en aan
"execute" het getal 1. Als een gebruiker alleen lees- en schrijfrechten nodig heeft, dan kan dit genoteerd worden met het getal 6.
rw------- = 600
rwxr-xr-x = 755
rw-r--r-- = 644
Deze notatie kan gebruikt worden in het UNIX commando "chmod" waarmee de permissies van een bestand of directory aangepast kunnen worden:
chmod 644 FILE
Foute permissies
Binnen een webapplicatie zoals geschreven in PHP worden alle bestanden ingelezen door de webserver. Als de webserver ziet dat een bestand een PHP script is,
dan zal de webserver dit PHP script interpreteren door middel van een ingebouwde PHP interpreter. Vaak spreekt men dan over het "uitvoeren van een PHP script",
maar het is belangrijk om te weten dat het script
niet wordt uitgevoerd op UNIX niveau. De permissie "execute" is dus niet nodig. Een directory moet wel
bereikbaar zijn voor de webserver dus op een directory zijn wel "execute" rechten nodig.
Dit geeft al direct aan dat een permissie 777 (met "execute" rechten) dus onnodig is voor bestanden binnen een webapplicatie. Let wel dat CGI scripts
(bijvoorbeeld met Perl) hier een uitzondering op zijn.
De volgende vraag is echter: Wie is de eigenaar van het bestand? Als de eigenaar van het bestand bijvoorbeeld "apache" is, dan heeft de webserver dus bij een
modus 600 al voldoende rechten om een PHP script uit te lezen en uit te voeren. Maar als "apache" niet de eigenaar is en wel de groep zit, dan moeten de
permissies dus 660 worden.
En als "apache" noch eigenaar is noch in de groep zit, dan is modus 666 dus nodig. Deze permissie komt toevallig overeen met het Bijbels getal van de duivel,
en dit kan geen toeval genoemd worden: Niet alleen "apache" maar iedere willekeurige gebruiker heeft op dit moment schrijfrechten op dit bestand. Als
beveiligingsexperts roepen dat modus 777 of modus 666
evil zijn dan is dit de voornaamste reden:
World-writable rechten zijn niet
verstandig op een server met meerdere UNIX gebruikers.
Verschillende permissies met het zelfde effect
Er zijn verschillende UNIX oplossingen om de webserver schrijfrechten te geven op een bepaald bestand. Een standaard Apache configuratie draait binnen UNIX
onder de gebruiker "apache". Als de gebruiker "apache" onder deel is van de groep "apache" dan hebben de volgende permissies het zelfde effect:
rw------- apache:apache
rw-rw---- apache:apache
rw-rw-rw- root:root
Er zijn een aantal uitbreidingen van Apache om een webapplicatie te draaien onder een andere gebruiker dan "apache": Bij oplossingen als SuPHP, mod_suid of
mod_ruid wordt een webpagina gedraaid met de rechten van de eigenaar van de bestanden. Als een PHP script als eigenaar "barin" heeft, dan wordt het
bijbehorende Apache proces opgestart met de rechten van "barin".
rw------- barin:users
Dit heeft niet alleen het voordeel dat "barin" via FTP ongestoord zijn eigen bestanden kan aanpassen (de hoofdzakelijke reden dat hosting providers voor een
dergelijke oplossing kiezen), maar andere gebruikers kunnen hiermee ook direct uitgesloten worden door de permissies weg te halen.
Het gevaar dat van
world-writable rechten meebrengen kan hiermee worden omzeild, maar er blijft één belangrijke vraag over: Is het
gevaarlijk dat Apache schrijfrechten heeft op de bestanden van een webapplicatie?
Zijn schrijfrechten überhaupt nodig?
Een applicatie als Joomla! biedt het voordeel dat vanuit de applicatie configuraties aangepast kunnen worden of bijvoorbeeld derde partij extensies
geïnstalleerd kunnen worden. Een bijkomend gevaar hierbij is dat een derde partij extensie een exploit kan bevatten, die door een hacker gebruikt kan
worden om schrijftoegang te krijgen tot de bestanden van de webapplicatie. De hacker kan dan bijvoorbeeld een zogenaamde PHP Shell naar de website uploaden,
van waaruit verdere hackpogingen kunnen worden ondernomen.
Om dit gevaar tegen te gaan, is de beste oplossing de webserver
geen schrijfrechten meer te geven. Dit betekent dat de functionaliteit van een
applicatie als Joomla! meteen drastisch afneemt. En simpelweg de schrijfrechten weghalen terwijl "apache" de eigenaar is van dat bestand, is ook geen echte
oplossing: Via een script kan "apache" net zo hard weer de schrijfrechten terugplaatsen. Het motto "Minder functionaliteit is veiliger" is van toepassing.
Als de vraag "Zijn schrijfrechten nodig?" wordt gesteld, is het handig een tegenvraag te stellen: Als een website wordt gehackt, komt dat dan door die
schrijfrechten of juist door een fout in de webapplicatie zelf? Bij het merendeel van alle hacks is het antwoord dat de veiligheid van de website staat of valt
bij de veiligheid van de applicatie. Daarnaast zijn de meeste exploits die momenteel op het Internet worden toegepast SQL Injection aanvallen, waarop het
verhaal van schrijfrechten helemaal niet van toepassing is.
In de praktijk is het veel effectiever de gebruikte webapplicatie up-to-date te houden, dan moeilijk te doen met permissies.
Conclusie
Als er in forums wordt geroepen dat 777 gevaarlijk is, dan wil het niet zeggen dan een modus 600 ongevaarlijk is. Zodra er gebruik wordt gemaakt van
oplossingen als SuPHP dan heeft dit vanuit het oogpunt van de webapplicatie dezelfde consequenties. Dat punt wordt nauwelijks aangekaart door deze
"veiligheidsexperts".
Daarnaast is het gevaar van lekken in de webapplicatie veel groter dan de issue van permissies. Het beste advies is dan ook: Wees je bewust van de gevolgen
van bepaalde permissies, maar besteedt meer aandacht aan het up-to-date houden van de gebruikte applicaties.
De puristen mogen natuurlijk best alle schrijfrechten weghalen, maar moeten wel rekening houden met een gebroken webapplicatie die slechts de helft van zijn
werk kan doen. Dit wordt natuurlijk alleen maar complexer als blijkt dat een bepaalde webapplicatie zichzelf up-to-date kan houden door zelf een upgrade uit te
voeren, maar daarvoor wel schrijfrechten nodig heeft.
