A WFSZ biztonsági ajánlásai webfejlesztők számára .: DomainFlotta Tudásbázis

A WFSZ biztonsági ajánlásai webfejlesztők számára

Írta és szerkeszti: Turcsányi Tamás
A visszajelzéseket a kapcsolódó weblabor bejegyzés hozzászólásai között várjuk.
Verzió: 1.4, utoljára módosítva: 2005-10-14

A dokumentum célja, hogy a webes környezetben ismert biztonsági problémákat és azok lehetséges megoldásait összefoglalva segítse a fejlesztőket biztonságos webalkalmazások készítésében. Bár a dokumentum a téma kapcsán erősen koncentrál a PHP nyelvre, ez nem jelenti azt, hogy más, webes környezetben alkalmazott nyelvek használói ne találhatnának hasznos információkat az ajánlások között.

Az itt leírt ajánlások, tanácsok megfogadása, alkalmazása nem jelenti azt, hogy alkalmazásunk garantáltan törhetetlen lesz - azonban ezen technikák, módszerek alkalmazása nélkül valószínűleg nem lesz az, hiszen ez a dokumentum a legismertebb, legalapvetőbb problémákra kíván rávilágítani. A web alapú alkalmazások biztonságosságára a felhasználók széles köre, a legtöbbször titkosítás nélkül közlekedő adatok, az elosztott (szerver-kliens) rendszerű működés miatt folyamatosan figyelnünk kell, ráadásul mivel a rendszernek sok összetevője van, ezért alaposan meg kell ismernünk az egyes komponensek biztonsági beállításait, problémáit is. Remélhetőleg jelen ajánlás a magyar webfejlesztők számára hasznos és a visszajelzések alapján is folyamatosan bővülő dokumentummá válik.

Tartalom

Adatok ellenőrzésével kapcsolatos javaslatok
Hibakezeléssel kapcsolatos javaslatok
E-mailek küldésével kapcsolatos javaslatok
Egyéb, fejlesztéssel kapcsolatos javaslatok
Szerverbeállítással kapcsolatos javaslatok
Egyéb javaslatok a szerverre vonatkozóan
Linkek
Felhasznált anyagok

1. Adatok ellenőrzésével kapcsolatos javaslatok

az oldal tetejére

A site látogatói felől érkező minden adat teljességgel megbízhatatlan, és csak ellenőrzést követően használhatjuk fel. Igaz ez mind a GET, mind a POST, a COOKIE adatokra (PHP-ben a $_GET, $_POST, $_COOKIE, $_REQUEST tömbök tartalmára), vagyis ne bízzunk meg abban sem, hogy az általunk generált URL-t nem próbálják meg átírni. A szerver oldali alkalmazásunk mindenképp ellenőrizze a felhasználó felől érkező adatokat, emellett a kliensoldali JavaScript alkalmazása is hasznos lehet (például űrlapok ellenőrzéséhez), ám a kliensoldali ellenőrzés kizárólagos használata kifejezetten ellenjavallt. Egy csak JavaScript-ellenőrzést tartalmazó űrlapkitöltő alkalmazás űrlapját tartalmazó HTML file-jának másolatának segítségével - amelyből a rosszindulatú felhasználó kitörölte a JavaScript ellenőrzéseket - el lehet juttatni ellenőrizetlen adatokat a szervernek.

Ellenőrzési lehetőségek többek között:

egy siteon belül használjunk közös ellenőrzőfüggvényeket, osztályokat, ismerjük meg a PHP ellenőrzésre szolgáló függvényeit.
amennyiben nem szabad, hogy a felhasználó HTML kódokat is megadjon, szűrjük ki azokat, vagy a kiírásnál ügyeljünk arra, hogy a HTML kódok ne HTML-ként, hanem szövegként jelenjenek meg. Az ún. Cross Site Scripting (XSS) segítségével (HTML kód bejuttatása website tartalmába) pl. egy fórumban lehetőség van arra, hogy minden különösebb jelzés nélkül új ablakban megnyíljon egy a fórumlátogatókat sértő, saját site-unktól független website. Ennek elkerülésére azokon a helyeken, ahol ez problémákat okozhat, az érkező adatokat tisztítsuk meg ezektől a tagektől. Ne felejtsük el, hogy a PHP strip_tags() függvénye számára megadott "meghagyható" tagek paramétereiben is lehetnek olyan részletek, amelyekkel általunk nem kívánt működést érhet el egy felhasználó! (Pl. ha a linkelésre szolgáló <A> taget engedélyezzük, az
<A href="http://www.example.com' ONMOUSEOVER=' location.href="http://www.masiksite.hu"; '>ide kattints!</A>
szöveggel a látogató - szándéka ellenére is - kilép az oldalról, ha a JavaScript engedélyezve van böngészőjében).
(PHP-ben használható függvények: strip_tags(), htmlspecialchars())
kötelezően kitöltendő tartalom esetén ellenőrizzük a kapott érték vezető- és a befejezőszóközöket (leading-trailing whitespace) nem tartalmazó formájának hosszát (PHP-ben használható függvények: trim() függvény, strlen())
Adatbázisba írás esetén mindenképp ismerjük meg az ún. escape-elési mechanizmust, mivel egyes speciális karaktereket nem illeszthetünk be közvetlenül egy SQL utasításba. (Lásd a speciális karakterek escape-eléséről szóló dokumentációt MySQL illetve PostgreSQL esetén. Amennyiben Oracle-t használunk, a Sybase-jellegű escapelésre (kettős aposztróf) lehet szükségünk.)

A PHP alapbeállítás szerint - a magic_quotes=on konfigurációs paraméternek köszönhetően - automatikusan escape-eli a beérkező szövegekben a következő karaktereket:

Beérkező karakter Átalakítás után

' \'

" \"

\ \\

NUL (a nullás ASCII kódú karakter) \NUL

Így a kapott szöveg (még ha tartalmazta is ezen speciális karaktereket) további átalakítás nélkül közvetlenül beilleszthető egy SQL utasításba (ezt az escape-elést mindenképp el kellene végeznünk, ha nem lenne automatikus, hiszen akkor rosszindulatú felhasználók az ún. SQL Injection technika segítségével az adatbáziskezelőnkbe juttathatnának módosított query-ket). Problémát jelenthet, ha egy magic_quotes=on-t használó szerverről költözünk olyan szerverre, ahol azt kikapcsolták, ugyanis ezesetben az átalakításokat magunknak kell elvégeznünk, vagy be kell állíttatunk a szervert. Az átalakítás továbbá felesleges, ha pl. levélben küldjük tovább a kapott adatokat (pl. egy hírlevélküldő készítésekor), hiszen \ (backslash) karakterek kerülnek a szövegbe a speciális karakterek elé.
Mindig limitáljuk a HTML INPUT mezők hosszát a szokásos HTML paraméterekkel, szerveroldalon pedig ellenőrizzük, hogy a kapott adat nem hosszabb-e, mint amit le tudunk tárolni adatbáziskezelőben.
ha szám jellegű adatot kértünk be, vagy URL-ben pl. cikkazonosítót adunk át, ellenőrizzük, hogy végül számot kaptunk-e meg a szerveroldalon (PHP-ben: is_numeric(), is_int(), is_long()).
tanuljuk meg a reguláris kifejezések használatát, amelyekkel komplikáltabb formátumú értékek formai ellenőrzését is elvégezhetjük (pl. dátumok, weboldak címe). Nagy hasznát vehetjük a Regex Coach-nak, vagy a Visual Regexp-nek - mindkettőjükkel megírás közben tesztelhetjük a reguláris kifejezéseket. A Regex Coach a kiértékelési szerkezet fastruktúrájú ábrázolásában, a lépésenkénti végrehajtás bemutatásában tud többet, a Visual Regexp kifejezések mentését/töltését, fejlettebb kiemelési lehetőségeket, beépített reguláris kifejezéseket (URL, email, dátum, IP cím, stb), bekapcsolható segítséget kínál.
E-mail címek bekérésekor használjunk jóváhagyási mechanizmust, így elkerülve, hogy más e-mail címét, vagy nem létező e-mail címet adhasson meg a felhasználó. Egy lehetséges jóváhagyási mechanizmus vázlatosan a következő:
1. a megadott e-mail cím eltárolása, amely mellett egy véletlenszerű értéket is megőrzünk (pl. kovacsistvan@webmailer.hu, a véletlenszám pedig 35915798)
2. ezzel párhuzamosan a felhasználónak kiküldünk egy URL címet a megadott e-mail címre, amelyet meg kell nyitnia az érvényesítéshez
3. A kiküldött URL egy scriptre mutat, paramétereiben az e-mail cím és a letárolt érték is szerepel (pl.
  http://www.example.com/ellenorzes?email=kovacsistvan@webmailer.hu&value=35915798). A script ellenőrzi, hogy a megnyitott linkben szereplő azonosító és e-mail cím is egyezik-e a letárolttal. Ha igen, akkor ellenőrizettnek fogadhatjuk el az e-mail címet, ha nem, akkor akár törölhetjük is az e-mail címhez tartozó adatokat, így elkerülve a többszöri próbálkozást hibás értékekkel.
előre rögzített/ismert lehetséges értékek esetén az értékekből egy tömböt állíthatunk össze. Ellenőrzéskor elegendő azt figyelni, hogy a kapott érték szerepel-e a tömbben. (PHP-ben: in_array())
Ha már mindenképp filenevet kell átadnunk egy script számára, PHP-ben a basename() vagy a dirname() függvény segítségével ellenőrizhetjük, akart-e esetleg a felhasználó kézzel alkönyvtárnevet beszúrni a filenév elé, ilyen módon próbálva hozzájutni egyes rendszerfileokhoz Ha van rá mód, filenév helyett egy azonosítót adjunk át, amely egyértelműen beazonosítja a filet (adatbázisban vagy textfileban, kevés statikus adat esetén tömbben tárolva).
Az előző ponthoz kapcsolódóan, ám külön kiemelten: kerüljük el a
http://www.sitenev.hu/betolt.php?filenev=archivum.php
jellegű scriptek írását.
Néhány siteon a HTTP protokollon keresztül közlekedő REFERER értékének ellenőrzésére bízzák magukat (amely a jelen oldalra hivatkozó oldal URL-jét tartalmazza, lásd a HTTP/1.1 protokoll leírását, 14.36 bekezdés), így próbálván elkerülni, hogy lementett HTML oldalak segítségével adatokat juttassanak el a szerveroldalra (hiszen értelemszerűen ha a lokális gépünkön nyitnánk meg a lementett oldalt és a lementett változat segítségével küldenénk el adatokat egy sitera, akkor a REFERER értéke nem tartalmazná az eredeti site nevét). Ez az érték azonban - más HTTP headerekhez hasonlóan - szintén nem hamisíthatatlan, már egy egyszerű parancssori wget segítségével is tehetünk úgy, mintha valamilyen "site-on belüli" oldal felől érkeztünk volna (lásd a wget --header opciója), miközben a wget-et tetszőleges asztali számítógépről futtatjuk.

2. Hibakezeléssel kapcsolatos javaslatok

az oldal tetejére

Éles környezetben ne jelenjenek meg a websiteon rendszerünkkel kapcsolatos hibaüzenetek, mivel azok információkat szolgáltathatnak a szerveren használt fileokról, alkalmazott technológiákról, adatbázisokról, és általában a szerverkörnyezetről. Csak olyan hibaüzeneteket jelenítsünk meg, amelyeket a látogatóknak szánunk (pl. "az e-mail cím kitöltése kötelező"). PHP-ben a hibaüzenetek kijelzésének szintjét és általában a hibák kijelzését beállíthatjuk scriptből az error_reporting() függvény, illetve inicializációs fileból az error-reporting és a display-errors paraméterek segítségével.
Fejlesztői környezetben mindenképp használjuk az error_reporting(E_ALL); beállítást, és ismerjük meg az egyes hibaüzenetek jelentését, foglalkozzunk a figyelmeztetésekkel (warning), megjegyzésekkel (notice) is. Rövid gyakorlás után ezek könnyen elkerülhetőek, és rendkívül sok hibalehetőségre hívják fel a figyelmet, segítik az átgondolt fejlesztést.
Kezeljük le a lehetséges hibákat. A nyelvi szinten kezelhető adatbázishibákat, potenciális betörési kísérleteket (pl. paraméterek átírása, stb.) mindenképp kezeljük le. Helyesen járunk el, ha felállítunk egy saját hibanaplózó függvényt, ami rögzíti a hibaüzenet/jelenség mellett a teljes környezetet (időpont, alkalmazás (script, végzett tevékenység, függvény neve), GET, POST, COOKIE értékek, látogató adatai: IP cím, használt böngésző). Ennek segítségével sikeres betörés (vagy sikertelen betörési kísérlet) esetén is valamivel több adat segít az elkövető megtalálásában. Sokat segíthet, ha az egyes hibajelenségeknél e-mailben elküldetjük címünkre a hibaleírást. A rendszerközeli hibákról ne tájékoztassuk a felhasználót, a látogatók csak azokat a hibaüzeneteket lássák, amelyek nekik szólnak (pl. rosszul kitöltött űrlap esetén).
Naplózzuk az összes elérhető hibaüzenetet: az adatbáziskapcsolódás és egyéb adatbázisműveletek során keletkezett hibákat, az alkalmazáshibákat, a felhasználók által okozott hibákat, a webszerver által érzékelt hibákat. Amennyiben alkalmazásunkban biztonsági lyukat fedez fel egy rosszindulatú látogató, akár a teljes adatbázist is tönkreteheti szabványos, hibaüzenetet nem okozó utasításokkal - emiatt érdemes lehet megfontolni bizonyos esetekben az adatbázisok oldalán minden query naplózását.
1. A hibaüzenetek naplózását PHP-ben az inicializációs fileban (php.ini) tudjuk beállítani, a log-errors és az error-log paraméterek segítségével.
2. Apache webszerver esetén a hibák naplózását a httpd.conf konfigurációs file-ban állíthatjuk be az ErrorLog és a LogLevel paraméterek segítségével.
3. MySQL esetén alapértelmezés szerint a data/ alkönyvtárban keletkeznek a naplófileok. Amennyiben minden egyes query-t naplózunk, az így keletkezett naplófile alapján egy esetleges támadás előzményeit is vissza tudjuk keresni, ám ez mindenképp többletterhelést jelent a szervernek. A részleteknek a dokumentációban itt tudunk utánanézni.
4. PostgreSQL esetén a postgresql.conf segíthet a naplózás beállításában, de van lehetőség beállításokat végezni futási időben is.

3. E-mailek küldésével kapcsolatos javaslatok

az oldal tetejére

Védjük a siteon megjelenített e-mail címeket az e-mailcímgyűjtő szoftverektől valamilyen alkalmasan megválasztott kódolás alkalmazásával. Több technológia is ismert ennek kivitelezésére, a legalapvetőbb módszer az e-mailcímben szereplő @ karakter szöveges átírása (kovacsistvan kukac webmailer pont hu), a bonyolultabbak általában JavaScript-re támaszkodnak (egy könnyen felhasználható PHP script: Jodrell mailto-ja kétszintű elkódolást alkalmaz PHP és JavaScript kombinációjában).
Figyeljünk arra, hogy az e-mailben kiküldött URL-ek ne legyenek túlságosan hosszúak, mivel egyes levelezők önkényesen megtörik az általuk túl hosszúnak vélt sorokat, így lehetetlenné (de legalábbis körülményessé) téve a küldött URL-ek azonnali megnyitását. 60-70 karakternél hosszabb URL-ek kiküldése már potenciális problémaforrás.
Ne küldjünk ki felhasználói nevet és jelszót egyszerre, egy e-mailben. Ha egy felhasználó elfelejtette login nevét, kérdezzünk rá e-mail címére, amelyre elküldhetjük a login nevet. Ha a felhasználó a jelszavát felejtette el, kérdezzük meg login nevét, és a login név mellett tárolt e-mail címére elküldhetjük jelszavát. Az e-mailekben ne utaljunk arra, hogy mely login névhez tartozott a jelszó. Egyszerre elküldött login név/jelszó páros esetén egy hálózaton keresztül esetlegesen "lehallgatott" e-mailből egyből nyilvánvalóvá válik a felhasználó hozzáféréséhez szükséges login/jelszó páros.

4. Egyéb, fejlesztéssel kapcsolatos javaslatok

az oldal tetejére

Mindig lássuk el kezdőértékkel változóinkat, ne bízzunk abban, hogy azok automatikusan létrejönnek (error_reporting(E_ALL); esetén erről megjegyzést (notice) is kapunk). Különösen ügyeljünk erre akkor, ha a register_globals konfigurációs beállításunk be van kapcsolva, és nem használjuk a $_GET, $_POST és egyéb szuperglobális tömböket. Lehetőleg mielőbb térjünk át ezek használatára.
Ne tároljunk érzékeny adatokat cookie-kban (adatbázisrekordok azonosítóit, felhasználói azonosítót, jelszót), azoknál sokkal biztonságosabb a session-ök használata. Mivel a cookie-k is HTTP protokollon keresztül közlekednek, így könnyűszerrel hamisíthatóak, sosem szabad megbíznunk azok tartalmában.
Lehetőség szerint használjunk azonban cookie-kat a session-azonosítók tárolására, ahelyett, hogy a site-okon feltüntetett URL-eken keresztül propagáljuk azt alkalmazásunk számára. A felhasználó által pl. levélben vagy ICQ-n továbbküldött URL segítségével - ha abban a session azonosító is benne van - session-je ellophatóvá válhat anélkül, hogy a felhasználó ezzel tisztában lenne. A session azonosító hamisítása önmagában nem könnyen kivitelezhető feladat, emiatt ezt az azonosítót különösebb veszélyek nélkül tárolhatjuk cookie-ban. A session azonosítók cookie-ban történő tárolását PHP-ben az inicializációs fileban a use_cookies paraméter segítségével tudjuk beállítani.
Mindig olyan kiterjesztést válasszunk scriptjeink számára, amelyet nem lehet letölteni. Ne válasszunk függvénygyűjteményünk számára pl. functions.inc nevet, csak akkor, ha biztosak vagyunk benne, hogy a webszerverünk nem fogja a tartalmát böngésző számára megnyitni (beállítható a konfigurációs fileok segítségével). Ehelyett használjuk pl. a functions.inc.php vagy a functions.php elnevezéseket ilyen fileoknál.
Lehetőség szerint az include file-okat a DocumentRoot-on kívül helyezzünk el, ezzel rossz webszerver beállítás esetén sem juthatnak hozzá illetéktelenek a kódunkhoz. Kódjaink megfelelő szervezésével akár minél többet kihelyezhetünk így a programunkból a DocumentRoot alól, ezt addig lehet fokozni, hogy az index.php már csak egy include-ból áll.
Ha nem saját készítésű kódrészleteket, függvényeket, függvénykönyvtárakat, osztályokat is felhasználunk alkalmazásainkban, győződjünk meg arról, hogy azok kellően biztonságosak. Egyetlen kódrészlet elég lehet ahhoz, hogy alkalmazásunkban biztonsági rés keletkezzen. Nem árt, ha tisztes távolságból kezdjük megismerni a különböző forrásokból letöltött kódokat, majd akkor kezdjük el használni azokat, ha meggyőződtünk hiba- és biztonsági rés-mentességükről.
Amennyiben egy felhasználó egyes kritikus függvények (jellemzően fileműveletek, parancsfuttatás) paramétereinek értékében valamilyen módon változtatásokat tud eszközölni (pl. különleges, nem várt karaktersorozatokat juttat be valamilyen módon), megnyílhat számára szerverünk tartalma. A következő PHP függvények potenciális biztonsági rések lehetnek [1]:
- require(), include() (file beolvasása és tartalmuk PHP kódként értelmezése)
- eval() (PHP kód futtatása)
- preg_replace() (a /e módosító segítségével PHP kód futtatása)
- exec(), passthru(), `` (backtick operátor), system(), popen() (programok futtatása különböző módokon)
- fopen() (file megnyitása)
- readfile() (filetartalom kiírása)
- file() (teljes filetartalom beolvasása)

5. Szerverbeállítással kapcsolatos javaslatok

az oldal tetejére

Védjük a sitehoz tartozó adminisztrációs felületet legalább Apache htpasswd-jellegű jelszóval, vagy egyéb módon kivitelezett saját autentikációval. Amennyiben .htaccess alapú védelmet használunk, győződjünk meg róla, hogy sem ez a file, sem a jelszavakat tartalmazó file nem elérhető böngésző segítségével (erre szolgáló beállítás az alapértelmezett httpd.conf fileban is található). Korlátozzuk az adminisztrációs oldalak hozzáférését IP cím vagy bármely egyéb jellemző alapján is (mindez szintén megoldható már .htaccess alapon is). Ha lehet, akkor más domain, aldomain illetve az alapértelmezett 80-as porttól eltérő portszám alá, ha nem, akkor legalább nehezebben kitalálható URL-en keresztül elérhetővé tegyük az adminisztrációs oldalakat. Meglepően gyakori hiba a
http://www.sitenev.hu/admin címre jelszóvédelem nélkül telepített adminisztrációs oldal használata.
Amennyiben megoldható, védjük siteunkat SSL segítségével. Az SSL alkalmazásával a szerver és a böngésző között titkosított csatornán zajlik az adatforgalom, így akár üzleti szempontból kritikus alkalmazásaink is kellő biztonsággal működhetnek.
Ne felejtsük el frissen telepített adatbáziskezelőben tisztába tenni a felhasználói hozzáféréseket (különösen igaz ez a MySQL-re!). Ha nem szükséges, MySQL-ben tiltsuk le a távoli kapcsolódás lehetőségét (--skip-networking paraméter) Az adatbáziskezelőnkben minden sitehoz használjunk egyedi látogatói és adminisztrátori felhasználót, a látogatók számára használt adatbázisfelhasználónak pedig csak a minimálisan szükséges jogokat adjuk meg! (A hozzáférési jogok MySQL és Oracle alatt korlátozhatóak akár oszlopszinten is)
Tegyük biztonságossá rendszerünk minden részét, ismerjük meg a kézikönyvek biztonsággal foglalkozó fejezeteit. PHP-ben fontoljuk meg a következő konfigurációs beállítások használatát (előzetesen természetesen olvassuk el a témával kapcsolatos irodalmat):
1. register_globals=off (elhárított veszély: a felhasználó nem tud változót létrehozni a scriptben)
2. safe_mode=on (elhárított veszély: a futtatható programok, használható függvények körének korlátozása, hozzáférés ellenőrzése file tulajdonosa alapján, file feltöltés letiltása)
3. open_basedir=alkönyvtárnév (elhárított veszély: a szerveren levő PHP fileok nem nyithatnak meg a megadott alkönyvtáron kívül eső fileokat)
4. allow_url_fopen=off (elhárított veszély: nem nyithatóak meg távoli fileok)
Lehetőség szerint minél kevesebb információt adjunk ki a szerverről a szerver által elküldött HTTP fejléceken keresztül (Server fejléc, lásd a HTTP/1.1 protokoll leírását, 14.38 bekezdés). Ezek a fejlécek információt adhatnak arról, hogy milyen platformot és milyen alkalmazásokat, illetve azok mely verzióit használjuk a szerveren - mindezek ismeretében rossz szándékú felhasználók a közismert biztonsági réseket kihasználva feltörhetik a szervert.
1. Apache esetén a ServerTokens paramétert Prod értékre állítva utasíthatjuk az Apache-ot arra, hogy csak a webszerver nevét közölje a Server headerben
2. PHP számára az inicializációs fileban az expose_php paramétert állíthatjuk Off-ra. Ennek segítségével a PHP nem fogja a Server fejléchez fűzni saját azonosítóadatait.
  Ha még tovább szeretnénk szűkíteni a kiadott információk körét, használhatunk tetszőleges kiterjesztést a .php helyett (értelemszerűen a webszerver konfigurálását követően, hogy az felismerje az új kiterjesztést mint PHP scriptet), vagy Apache esetén a Content-negotiation kihasználása esetén egyáltalán nincs szükség a kiterjesztések használatára az URL-ekben (vagyis míg a filenevek kiterjesztése .php is lehet, azt meghívhatjuk úgy is, hogy nem adjuk meg a kiterjesztést).

6. Egyéb javaslatok a szerverre vonatkozóan

az oldal tetejére

Egyeztessünk a rendszergazdával, készítsünk rendszeresen biztonsági másolatokat az alkalmazásról, az adatbázisról, a szerver főbb konfigurációs állományairól. A szerverre ne kerüljenek be ellenőrizetlen alkalmazások, kódok.
Igyekezzünk mindig a legújabb stabil változatokat használni mindenből, főként igaz ez a nagyobb verzióváltásokra. Ne hagyjuk magunkat legyőzni ezen a téren csak azért, mert a rendszergazdának kényelmesebb, ha nem kell semmit csinálnia. Komolyabb váltás esetén érdemes előzetesen egy tesztszerveren kipróbálni, hogy mindenünk működik-e úgy, ahogyan szeretnénk.
Soha ne adjunk a webszerveren több jogot a fileoknak, mint amennyire szükség van az alkalmazások működéséhez. Linux alatt ne adjunk everyone jogot fileokra, inkább átgondolás után hozzunk létre felhasználói csoportokat, és csoportjogokat adjunk ki.
Ha alkalmazást telepítünk fel éles szerverre (pl. nuke-ok, webes levelezők), mindig változtassuk meg az alapértelmezett jelszavakat, töröljük a telepítési leírásban jelzett fileokat.
Figyeljük rendszeresen a különböző biztonsággal foglalkozó levelezési listákat, legalább az általunk használt rendszerelemek (Apache, PHP, adatbáziskezelők, stb.) biztonsági hibákat/javításokat közlő levelezési listáira iratkozzunk fel.