ugrás a tartalomhoz

A weboldalak veszedelmei

hakos15 · 2013. Ápr. 24. (Sze), 19.57
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.
 
1

Mysql esetén:

Greg · 2013. Ápr. 24. (Sze), 20.32
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.

A htmlspecialchars es a strip_tags nem sokat ved a mysql_inject ellen. Azok inkabb az XSS elleni vedelemben hasznosak.
Ha nem GET, hanem POST metódust alkalmazunk weboldalunkon, akkor egy egyszerű sorral lehet limitálni a header-ben a lekérést. if(strlen($_SERVER[’QUERY_STRING’]) > 15) { die(’Érvénytelen művelet’); } E sor megvizsgálja a beérkező kérés hosszát és ha 15 karakternél nagyobb a lekérés, akkor megáll a rendszer és hibát jelez.

Ez eleg vicces megoldas :). Az osszetett keresod akkor itt meg is all es ervenytelen lesz a muvelet.
2

Ha már MySQL-t használunk,

Poetro · 2013. Ápr. 24. (Sze), 20.37
Ha már MySQL-t használunk, akkor ne használjuk a 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 lehetnek olyan nem kívánatos tényezők, melyek tönkretehetik az adatbázist.

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.

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

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.
4

Melyik CloudFlare termék

Greg · 2013. Ápr. 24. (Sze), 22.45
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.

http://www.cloudflare.com/ddos
3

Biztonság

Hidvégi Gábor · 2013. Ápr. 24. (Sze), 21.15
Rendkívül fontos témával kezdtél el foglalkozni, a fórumokban is csak érinteni szoktuk a kérdéskört, a cikkek között is csak kettőt találtam (Munkamenet kezelés biztonsági kérdései és PHP, valamennyire biztonságosabban). Sokmindenre kell figyelni, egy kezdőnek ez elsőre sokkoló lehet.

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.
5

Köszönöm!

nevemrock · 2013. Ápr. 25. (Cs), 07.34
Köszönöm a bejegyzést!
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.
6

Elnézést, nem akadékoskodni

RedPoppy · 2013. Ápr. 25. (Cs), 14.47
Elnézést, nem akadékoskodni akarok, de nem lehetne ezt tagolni? Ijesztően néz ki így egy blokkban...
7

Update

hakos15 · 2013. Ápr. 25. (Cs), 15.34
Először is köszönöm az előző hozzászólásokat. Az első három hozzászóló válaszának kicsit utána kérdezgettem bent a cégnél és egy kettő érdekes megjegyzést kaptam rá. A tagolást amennyire lehetett szétszedtem. Nos pont ezért hoztam létre ezt a kis összefoglalót, hogy össze legyen egy helyen foglalva ez a kényes téma. Akinek tetszett annak köszönöm a véleményét. A regexp dolgot egyenlőre jövőhéten tudom megírni, ha lesz időm rá :)
8

Az első három hozzászóló

Greg · 2013. Ápr. 25. (Cs), 17.13
Az első három hozzászóló válaszának kicsit utána kérdezgettem bent a cégnél és egy kettő érdekes megjegyzést kaptam rá.


Megtudhatjuk? :)
9

Re

hakos15 · 2013. Ápr. 25. (Cs), 17.20
Nos volt egy két érdekes dolog amit én is vétettem, de korrigálva lett.
10

Tehat nem mi vagyunk a hulyek

Greg · 2013. Ápr. 25. (Cs), 17.44
Tehat nem mi vagyunk a hulyek amiert ramutattunk nehany dologra ami tevesen volt irva?
11

Kritika

bamegakapa · 2013. Ápr. 25. (Cs), 19.09
Szerintem ez az írás csak a felületet kapargatja, bele-bele kap számtalan témakörbe, de igazából egyikről sem közöl annyit, hogy az ismeretet nyújtson azoknak, akik nem vágják a témát, tapasztaltabbak számára meg épp felületessége miatt nem szolgál érdekes olvasnivalóval. Sokat markol, végül szinte semmit nem fog.

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.
12

+1

Pepita · 2013. Ápr. 25. (Cs), 21.23
Szinte teljesen a számból vetted ki a szót. Jobban utána kéne járni(a), és több cikkben megírni(a). Én is jószándékkal írtam.
13

Fontos téma, de sajnos az

tgr · 2013. Ápr. 26. (P), 18.48
Fontos téma, de sajnos az írás leginkább az elterjedt rossz gyakorlatok gyűjteménye lett:
  • statikus szerverre nem kell védelem (a hozzáférés biztonságossá tétele statikus szervernél ugyanolyan fontos - kismillió féreg van, ami FTP jelszavakat gyűjt és HTML weblapokat tör fel teljesen automatizáltan)
  • template-ek a webrootban, feldolgozó fájlok a webrooton kívül (használj MVC-t)
  • mysql_* (használj helyette PDO-t, vagy ha muszáj, a mysqli_* függvényeket)
  • SQL escaping (használj paraméteres queryket, ahol lehet)
  • HTML stripping/escaping SQL queryk előtt (bemeneten validálunk, kimeneten escapelünk)
  • az XSS rész szimplán zavaros, mi köze a rákattintáshoz? Talán a clickjackinggal keveri a szerző.
  • referer ellenőrzés és limitált idejű sütik CSRF ellen (az input token az egyetlen komolyan vehető megoldás)
  • CAPTCHA (UX szempontból nem jó megoldás, néha nincs jobb, de általában lehet fájdalommentesebben is védekezni a robotok ellen)
  • DDOS ellen védekezés memcache-sel (legalább a webszerver, de még inkább reverse proxy vagy load balancer szinten kell megfogni)