A weboldalak veszedelmei
A modern, mai világban nélkülözhetetlen egy weboldal megléte akár magánszemélyeknek, akár más intézményeknek, esetleg cégeknek. A honlapoknak, mint azt már tudjuk, két típusa létezik. A dinamikus és a statikus. Statikus oldal esetén nem szükséges komolyabb védelem az oldalnak, esetleg a szervernek túlterhelési kockázatok miatt.
Dinamikus oldalak esetén ez már teljesen más. Alapvetően a hackerek és crackerek nem egyből a szerver próbálják meg valamilyen úton módon befolyásolni, feltörni, hanem apró trükkökkel próbálkoznak először. Ebben a rövid leírásban megpróbálom belesűríteni mindazon módszereket, melyek ebbe az apró trükkök kategóriába tartoznak.
Ha megtervezünk egy weboldalt, akkor ajánlott három részre osztani. Statikus szerver, root-on belül és root-on kívüli fileok. Egy rossz web kliens beállítás esetén az egész oldal tartalma letölthetővé válik. Ennek elkerülése érdekében a feldolgozó fájlokat érdemes a root könyvtáron kívül elhelyezni. Ennek hátránya, hogy a fájlok elején egy – két sorban meg kell hívni a feldolgozó fájlokat, ha dolgozni szeretnénk velük.
Következő nagy probléma az adatbázisok inject-elése (befecskendezése). Ezzel a módszerrel a hacker lekérheti az egész adatbázis tartalmát mindössze egy sorral, melyek a header vagy input adatokba injektálnak be. Ez ellen három beépített függvénnyel védekezhetünk. Mysql esetén: mysql_real_escape_string , htmlspecialchars , valamint strip_tags . Mysqli esetén mysqli_real_escape_string , valamint az előző függvények. Ezek biztosítanak egy alap védelmet inject ellen, de ennél komolyabb funkciók kellenek. Ezek a függvényeket érdemes kombinálni, egymást kiegészíteni, valamint szűrni a mysql, mysqli parancsokat. (union, update…).
Nagyobb gondot szoktak jelenteni az XSS behatolások. Itt általában egy scriptet injektálnak az oldalba, mely lehet pl. egy hirdetés… Amire ha a felhasználó rákattint, akkor egyszerűen ellophatja annak sütijeit, azonosítóit. Ezt ismét csak szűréssel, escapeeléssel védhetjük ki.
A weboldalak nagy része nem tartalmaz CSRF védelmet. Ennek a rövid definiálása annyit tesz, hogy oldalon-keresztüli kéréshamisítás. Ennek kivédésére több módszer létezik: http_REFERER és a http_ORIGIN ellenőrzése, Sütik idejének limitálása, a formban elrejtett hidden input egy tokennel egybekötve. Persze léteznek más megoldások, de ezek a leggyakoribbak.
Ha már a formoknál tartunk, akkor meg kell említeni a robotokat. A robotok lehetnek olyan nem kívánatos tényezők, melyek tönkretehetik az adatbázist. Ezt általában egy egyszerű CAPTCHA-val oldhatjuk meg. Még is a legáltalánosabb és leghatékonyabb egy oldal tönkretételére a DDOS támadás. A ddos egy túlterhelésen alapuló támadási forma. Erre létezik egy alternatív megoldás, a memcache. A jól megírt memcache ip alapon történő hitelesítés és oldal megnyitási limit megoldhatja a probléma 60-70 %-át. Léteznek még tűzfalak és anti-ping rendszerek, de ezek költségesek.
A következőkben, ha lehetőségünk van htaccess használatára, akkor itt van pár tipp:
Saját hibaüzenetek: ErrorDocument 404 /error.php
Alap nyitófile: DirectoryIndex index.php
Könyvtárlistázás tiltása: Options – Indexes
Hozzáférés tiltása mappákhoz: allow illetve deny használata
Szerver aláírás tiltása: ServerSignature Off
Nagyjából ezek azok a főbb támadási formák, melyeket egy hacker, cracker használ. Érdemes még megtanulni a reguláris kifejezéseket (regexp), mert hasznos. Ha lesz rá érdeklődés és lehetőségem, akkor nyitok erről egy magyarázatot.
■ Dinamikus oldalak esetén ez már teljesen más. Alapvetően a hackerek és crackerek nem egyből a szerver próbálják meg valamilyen úton módon befolyásolni, feltörni, hanem apró trükkökkel próbálkoznak először. Ebben a rövid leírásban megpróbálom belesűríteni mindazon módszereket, melyek ebbe az apró trükkök kategóriába tartoznak.
Ha megtervezünk egy weboldalt, akkor ajánlott három részre osztani. Statikus szerver, root-on belül és root-on kívüli fileok. Egy rossz web kliens beállítás esetén az egész oldal tartalma letölthetővé válik. Ennek elkerülése érdekében a feldolgozó fájlokat érdemes a root könyvtáron kívül elhelyezni. Ennek hátránya, hogy a fájlok elején egy – két sorban meg kell hívni a feldolgozó fájlokat, ha dolgozni szeretnénk velük.
Következő nagy probléma az adatbázisok inject-elése (befecskendezése). Ezzel a módszerrel a hacker lekérheti az egész adatbázis tartalmát mindössze egy sorral, melyek a header vagy input adatokba injektálnak be. Ez ellen három beépített függvénnyel védekezhetünk. Mysql esetén: mysql_real_escape_string , htmlspecialchars , valamint strip_tags . Mysqli esetén mysqli_real_escape_string , valamint az előző függvények. Ezek biztosítanak egy alap védelmet inject ellen, de ennél komolyabb funkciók kellenek. Ezek a függvényeket érdemes kombinálni, egymást kiegészíteni, valamint szűrni a mysql, mysqli parancsokat. (union, update…).
Nagyobb gondot szoktak jelenteni az XSS behatolások. Itt általában egy scriptet injektálnak az oldalba, mely lehet pl. egy hirdetés… Amire ha a felhasználó rákattint, akkor egyszerűen ellophatja annak sütijeit, azonosítóit. Ezt ismét csak szűréssel, escapeeléssel védhetjük ki.
A weboldalak nagy része nem tartalmaz CSRF védelmet. Ennek a rövid definiálása annyit tesz, hogy oldalon-keresztüli kéréshamisítás. Ennek kivédésére több módszer létezik: http_REFERER és a http_ORIGIN ellenőrzése, Sütik idejének limitálása, a formban elrejtett hidden input egy tokennel egybekötve. Persze léteznek más megoldások, de ezek a leggyakoribbak.
Ha már a formoknál tartunk, akkor meg kell említeni a robotokat. A robotok lehetnek olyan nem kívánatos tényezők, melyek tönkretehetik az adatbázist. Ezt általában egy egyszerű CAPTCHA-val oldhatjuk meg. Még is a legáltalánosabb és leghatékonyabb egy oldal tönkretételére a DDOS támadás. A ddos egy túlterhelésen alapuló támadási forma. Erre létezik egy alternatív megoldás, a memcache. A jól megírt memcache ip alapon történő hitelesítés és oldal megnyitási limit megoldhatja a probléma 60-70 %-át. Léteznek még tűzfalak és anti-ping rendszerek, de ezek költségesek.
A következőkben, ha lehetőségünk van htaccess használatára, akkor itt van pár tipp:
Saját hibaüzenetek: ErrorDocument 404 /error.php
Alap nyitófile: DirectoryIndex index.php
Könyvtárlistázás tiltása: Options – Indexes
Hozzáférés tiltása mappákhoz: allow illetve deny használata
Szerver aláírás tiltása: ServerSignature Off
Nagyjából ezek azok a főbb támadási formák, melyeket egy hacker, cracker használ. Érdemes még megtanulni a reguláris kifejezéseket (regexp), mert hasznos. Ha lesz rá érdeklődés és lehetőségem, akkor nyitok erről egy magyarázatot.
Mysql esetén:
A htmlspecialchars es a strip_tags nem sokat ved a mysql_inject ellen. Azok inkabb az XSS elleni vedelemben hasznosak.
Ez eleg vicces megoldas :). Az osszetett keresod akkor itt meg is all es ervenytelen lesz a muvelet.
Ha már MySQL-t használunk,
mysql_*
függvényeket, helyette MySQLi, PDO használata javallott. Ezzel el is tudjuk kerülni az SQL injection-t is, mivel használhatunk prepared statement-eket.if(strlen($_SERVER[’QUERY_STRING’]) > 15) { die(’Érvénytelen művelet’); }
Elárulnád, miért hasznos a fenti, és miért nem idézőjeleket használsz benne? Mintha a fentit valami WordPress blogban vagy Wordben írtad volna. A hossz korlátozásának elég ritkán van haszna.
A robotok miért pont az adatbázist akarnák tönkretenni? Inkább adatokat akarnak ellopni, illetve a szervered vagy alkalmazásod szolgáltatásait (például email küldés) kihasználni.
Ezt hogy is? Mivel maga a PHP-t futtató alkalmazásszerver fog elfogyni, nem is tud újabb PHP-t futtatni, ahol eljutna a kérés a memcache-ig. Inkább Varnish vagy más proxy lehet hasznos.
Melyik CloudFlare termék nyújt szerinted védelmet DDOS támadás ellen? Mert én nem találtam ilyet, de lehet nem jól néztem.
Melyik CloudFlare termék
http://www.cloudflare.com/ddos
Biztonság
Az általad leírtakon sokat lehet még csiszolni, de szerintem bekerülhet majd a Weblabor Tudástárba, ha van kedved folytatni, én szívesen segítek benne, amikor ráérek.
Köszönöm!
Az egyik legfontosabb dolog az alkalmazás védelme. Sajnos kevés az ilyen cikk és főleg az olyan, ami mélyebben vizsgálja a témakört.
A mai napig lehet látni, hogy komolynak látszó cégek, semmit nem foglalkoznak ezzel a problémakörrel.
Jó volna látni a jövőben is hasonló cikkeket.
Elnézést, nem akadékoskodni
Update
Az első három hozzászóló
Megtudhatjuk? :)
Re
Tehat nem mi vagyunk a hulyek
Kritika
Számomra összeszedetlen, hiányoznak a részletek, példakódok. Rejtélyessége miatt igazából "belekötni" is sokkal nehezebb, hiszen nem ad példát vagy magyarázatot, hogy mondjuk a strip_tags hogyan is védene az SQL injection ellen.
Mindegyik bekezdésről egy külön cikket lehetne, illetve kellene írni, ennek én így nem sok értelmét látom. Mindez nem sértő, hanem segítő szándékkal íródott.
+1
Fontos téma, de sajnos az
mysql_*
(használj helyette PDO-t, vagy ha muszáj, amysqli_*
függvényeket)