Sokan vannak abban a tudatban, hogy elég egy weboldalt php-ban kódolni és csak egy rendes dizájnt kell alá rakni, de akkor hol maradnak az egyes védelmek? Természetesen php-ben is számos védelmet használhatunk, amelyek megvédenek egyes próbálkozásoktól, viszont miért szórakoznánk php-vel, miközben van szerveroldali (.htaccess) lehetőség is, mellyel akár több órára kitilthatjuk a nemkívánatos robotokat, behatolókat.

Első körben tisztáznunk kell a http hibakódokat, melyek olyankor jönnek létre, ha egy adott felhasználó rossz helyen keresgél vagy mi hibáztunk el valamit a php kódban vagy szerveren.

Ezek lehetnek:

• 1xx: A szerver átmeneti választ küld a kliens kérésére.
• 2xx: A szerver elfogadja és teljesíteni tudja a kliens kérését.
• 3xx: A kérés megválaszolásához további műveletre van szükség a kliens kérésének teljesítéséhez.
• 4xx (Kliensoldali hiba): A kérés szintaktikailag hibás vagy nem teljesíthető.
• 5xx: (Szerveroldali hiba) A szerver belső hiba miatt nem tudta teljesíteni az egyébként helyes kérést.

Most már jöhetnek a .htaccess kódok. Itt is több részre bontjuk a feladatot, hisz számos dolgot itt is el tudunk végezni.

Először is fontos az átirányítás bekapcsolása, melyet a „RewriteEngine On” sorral tudunk megvalósítani, majd fontos, hogy a következőben a könyvtárszintet is megadjuk, mely nekünk a „public_html” mappába fog mutatni. A kódja pedig a következő: „RewriteBase /”.

Ajánlott a szerverinformációk kikapcsolása a szerveren, hisz, ha egy hacker hozzájut a szervered részletes információjához, akkor elég komoly veszélyben lehet az adott szervergép, tárhely, vps, akár szolgáltatónak a szerverterme is. „ServerSignature Off” sorral tudjuk semlegesíteni.

Előfordulhat, hogy szerverünk nem Magyarországon van, így a szerveridő is eltér, emiatt a php is rossz adatokat kap vissza (szerintünk). Nem szükséges php-ban a régióval variálni, hisz „SetEnv TZ Europe/Budapest” sorral máris átállt a szerverünk Magyar időzónára. Ezzel újabb sorokat és memóriát spórolva.

Fontos, hogy karakterkódolást is beállítsuk a magyar betűknek megfelelően. Természetesen nem minden szerver, tárhely igényli ezt, de a következőképpen lehet UTF-8 karakterkódolásra beállítani: „AddDefaultCharset UTF-8”.

Ami mindenkinek nagyon fontos, hogy a könyvtárak (mappák) listás elérését letiltsuk, mivel így a támadók hozzáférnek a php fájlokhoz és teljes mappaszerkezethez. „IndexIgnore *”.

Hogyan állunk eddig:

RewriteEngine On
RewriteBase /
ServerSignature Off
SetEnv TZ Europe/Budapest
AddDefaultCharset UTF-8
IndexIgnore *

Ezekkel már alapszinten védve vagyunk, de ha komolyabb tartalmat tárolunk vagy egy komoly szolgáltatást üzemelünk, akkor érdemes tovább olvasni a cikket.

Hibakezelő lapok

A következő hibalapokat érdemes lekezelni: 400, 401, 403, 404, 410, 500. A következőképpen kell beillesztenünk. Természetesen a fájloknak élniük kell, ezeket dizájnolhatjuk kedvünkre.

• ErrorDocument 404 /404.shtml
• ErrorDocument 403 /403.shtml
• stb…

Átirányítás www nélküli címre

Még sokan használják a www előtagok weboldalak megnyitásánál, pedig mostanság a böngészőkben felesleges beleírni, mivel ezeket automatikusan a szerver és kliens lekezeli. Viszont a keresőszolgáltatók nem szeretik, ha egy adott tartalom két linken érhető el, tehát például: into.hu/hirek/100 és/vagy www.into.hu/hirek/100 ,mivel ezek külön tartalomnak, URL-nek számítanak. Természetesen php-ben ez is megoldható, de minek, ha mi szerveroldalról (apache) is megoldhatjuk.

A következő két sor megnyitott url-ből egyszerűen kiveszi a www-t és átirányít oda, amit eredetileg megnyitott a felhasználó, csak www nélkül.

RewriteCond %{HTTP_HOST} ^www\.(.+) [NC]
RewriteRule ^(.*) http://%1/$1 [R=301,NE,L]

Fájlkiterjesztések elrejtése, rövid keresőbarát URL-ek használata

Bár ez nem nyújt nagy védelmet mégis érdemes megemlíteni, mert egy még kisebb hackertől megvédhet minket, főleg SQL injection próbálkozásánál. A teljes php-t ezzel nem tudják elérni, ráadásul, ha ID-t használunk, mint tartalom azonosító, akkor nyert ügyünk van.

Példakódok

Csak lecsípi a „.php” kiterjesztést

RewriteRule ^([\w]+)/?$ $1.php

Rövid keresőbarát URL egy messzi php-hoz

RewriteRule ^kapcsolat$ index.php?tartalom=kapcsolat

Tartalom behívása, védett azonosítóval (Csak ID-k esetén)

RewriteRule ^rovidurl/([0-9]+)$ tartalom.php?id=$1

Képek külső szerveren való linkelése

Nagyon gyakoriak azok az esetek, amikor külső szerverek próbálják meg lenyúlni a képeket, persze olyan módon, hogy a link marad a saját tárhelyen, csak linkelik és ezzel óriási adatforgalmat növelve neked. Természetesen ez is orvosolható néhány lépéssel. Adjunk nekik egy másik képet, mely maximum 1-2 kilobájtos legyen.

RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?weboldalam.hu /.* [NC]
RewriteCond %{HTTP_REFERER} !.*(google|q=cache|msn|bing).* [NC]
RewriteCond %{REQUEST_URI} !.*elvittedakepet.jpg$
RewriteRule \.(png|gif|jpe?g)$ http://weboldalam.hu/images/elvittedakepet.jpg [NC,R,L]

Most pedig jöhetnek a komolyabb biztonsági intézkedések weboldalunkon a .htaccess fájlban.

Lényeges dolog, hogy ha valami olyan műveletet követ el valaki, amit nem lenne szabad, annak mindenképp 403-s hibaoldalt kell visszaadni és ezáltal a harmadik vagy ötödik próbálkozás után a szerver kidobja egy megadott időre (1-4 óra).

Hamis böngészők, azaz veszélyes botok tiltása

Vannak olyan botok, melyek nem keresőszolgáltatásoktól jönnek, és ezek böngészőknek álcázzák magukat. Ezek komoly károkat okozva nekünk, hisz felmérik a weboldal állapotát, tartalmakat, fájlrendszert és egyéb sebezhetőséget kereshetnek.

Először a kulcsszavak, amelyeket a böngészők küldenek azonosítás céljából

RewriteCond %{HTTP_USER_AGENT} ^.*(msie|firefox|opera|chrome|safari).* [NC]

Az indexelő keresőszolgáltatókat kivételek közé kell tenni, pl Google, bing. További keresőszolgáltatóktól érdemes tartózkodni.

RewriteCond %{HTTP_REFERER} !.*(google|q=cache|msn|bing).* [NC]

A nyelvi beállításra vonatkozó HEADER nincs elküldve.

RewriteCond %{HTTP:Accept-Language} ^$

Mindezeket válasz nélkül utasítsa vissza.

RewriteRule ^(.*)$ - [F]

Így néz majd ki nekünk:

RewriteCond %{HTTP_USER_AGENT} ^.*(msie|firefox|opera|chrome|safari).* [NC]
RewriteCond %{HTTP_REFERER} !.*(google|q=cache|msn|bing).* [NC]
RewriteCond %{HTTP:Accept-Language} ^$
RewriteRule ^(.*)$ - [F]

Ha a fentebb írtak nem minden esetben jönnek be, ezért ajánlott az ártalmas robotok tiltása is, mivel ezek is feltérképezik az egész weboldalt (fájlrendszer, sebezhetőség és minden egyebet, amit csak elképzelni tudunk).

RewriteCond %{HTTP_HOST} ^http://(www\.)?images\.linuxidx\.com [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (^gvfs|libwww-perl|Python|Wget|^$|Zend_Http_Client|curl) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (Mail\.Ru|RoboFox|Top\Secret|Extractor|Ezooms|CCCP|MetaGeneratorCrawler|Typhoeus|EventMachine|TalkTalk) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (XR2\.exe|xpymep\.exe|TurnitinBot|oBot|CMS) [NC,OR]
RewriteCond %{HTTP_REFERER} ^-$ [OR]
RewriteCond %{HTTP_REFERER} ^$
RewriteRule ^(.*)$ - [F]

Az első sor internetes kereső letiltása, ami a képtalálatokat rettentő gyors linkeléssel oldja meg és kerül bele az adatbázisába.

A második sorban, programozható gépi adatgyűjtésre alkalmas böngészők kerültek bele.

A harmadik sorban keresőrobotok letiltására kerül sor.

A negyedik pedig programok, melyek keresőrobotoknak álcázzák magukat.

Ezután egy kötőjeles hivatkozást is ellenőrzünk, majd üres hivatkozásokat is.

Ezt követően utolsó lépésként válaszüzenet nélkül visszautasítja az apache a hozzáférést az oldalhoz.

Robots.txt fájl elrejtése

A robots.txt fájlnak régen volt értelme, viszont most is használják a keresőrobotok is, bár ezt alátámasztani jelen pillanatban én sem tudom, mivel nem kizárt, hogy már nem használják. A robots.txt arra szolgál, hogy a keresőrobotoknak megmondjuk, hogy melyik elérési utakat ne indexelje a keresőszolgáltató, tehát például admin és feldolgozó mappa helye, stb..

Viszont ehhez külsős emberek is hozzáférnek, tehát, ha weboldalam.hu/robots.txt –t megnyitják, akkor eléjük tárulnak weboldalunkon levő fontosabb, nem publikus elérési utak.

Következőképpen tudjuk letiltani:

<Files robots.txt>
   Order Deny,Allow
   Deny from All
   Allow from googlebot.com google.com google-analytics.com
</Files>

Külső http kérések tiltása

Számos oldalon engedélyezve van a GET és POST külső elérése, mely biztonsági okokból nem egy jó pont, így ajánlott, csak belső szerveren levő php-knak ezt a lehetőséget engedélyezni, így php műveletek csak belső szerveren érhetőek el.

RewriteCond %{THE_REQUEST} !^(GET|POST)\ /.*\ HTTP/1\.(0|1)$ [NC]
RewriteRule ^(.*) - [F]

SQL támadások elleni védelem

Legjobb védelem az, ha adott karaktereket tiltunk vagy átalakítunk bevitelkor, így az SQL feltörésének lehetősége nagyban lecsökken minimális szintre. Következőképpen védhetjük weboldalunk ez ellen:

RewriteCond %{QUERY_STRING} ^.*(;|<|>|’|”|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|cast|set|declare|drop|update|md5|benchmark).* [NC,OR]
RewriteCond %{QUERY_STRING} ^\.\./ [NC]
RewriteRule ^(.*)$ - [F]

PHP fájlok közvetlen elérésének tiltása

Ha van egy natúr feldolgozó php-nk vagy template-n, amelyeket include-dal vagy egyéb kóddal behívunk egy fő php-ba, akkor érdemes ezeknek a közvetlen elérését 403 hibaüzenettel viszonozni.

Ha egy adott mappában minden php-nek a közvetlen elérését tiltani szeretnénk:

<FilesMatch "\.php$">
   Order Allow,Deny
   Deny from all
</FilesMatch>

Ha csak adott php fájlok elérését szeretnénk tiltani:

<FilesMatch "phpegy.php|phpketto.php|phpharom.php ">
   Order Allow,Deny
   Deny from all
</FilesMatch>

Szerintem ennyi bőven elég egy szerveroldali védelemhez. Ezeket felhasználva biztonságossá fog válni weboldalunk a hackelések ellen, természetesen számos egyéb védelem is létezik. Ha kérdésed van nyugodtan tedd fel! :)